之前在看 IntentService 源码的时候看到在 ServiceHandler 处理完消息之后会调用 stopSelf(startId) 结束当前的Service，那么如果我们快速的调用两次 startService 结果是如何呢，我们在关键的地方加入日志
@Override
public void onCreate() {
super.onCreate();
Log.i(TAG, "onCreate");
}
@Override
public void onStart(Intent intent, int startId) {
super.onStart(intent, startId);
Log.i(TAG, "onStart startId:" + startId);
}
@Override
public void onDestroy() {
super.onDestroy();
Log.i(TAG, "onDestroy");
}
@Override
protected void onHandleIntent(Intent intent) {
Log.i(TAG, "onHandleIntent");
}
运行，看一下log输出结果
intent_service1.png
非常好，一切都在我们的预料之中，然而现实的工作不会那么简单，onHandlerIntent 中通常会执行很多工作，我们在 onHandlerIntent 中加入一些延时来模拟正常工作
@Override
protected void onHandleIntent(Intent intent) {
try {
Thread.currentThread().sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Log.i(TAG, "thread name:" + Thread.currentThread().getName());
Log.i(TAG, "onHandleIntent");
}
运行，看一下log输出结果
intent_service2.png
似乎有些问题，onDestroy() 并没有执行两次，一定是哪里出了问题。我们回想一下为什么会调用 onDestroy() ，是因为 ServiceHandler 在调用完 onHandleIntent之后又调用了 stopSelf(startId) ，注意这里有个参数 startId ，难道这里有什么猫腻？
我们看一下源码的文档
/**
* Stop the service if the most recent time it was started was
* <var>startId</var>. This is the same as calling {@link
* android.content.Context#stopService} for this particular service but allows you to
* safely avoid stopping if there is a start request from a client that you
* haven't yet seen in {@link #onStart}.
*
* <p><em>Be careful about ordering of your calls to this function.</em>.
* If you call this function with the most-recently received ID before
* you have called it for previously received IDs, the service will be
* immediately stopped anyway. If you may end up processing IDs out
* of order (such as by dispatching them on separate threads), then you
* are responsible for stopping them in the same order you received them.</p>
*
* @param startId The most recent start identifier received in {@link
* #onStart}.
* @return Returns true if the startId matches the last start request
* and the service will be stopped, else false.
*
* @see #stopSelf()
*/
上面的文档摘自 stopSelfResult(int startId) 两个方法的区别在于有无返回值，文档的大概意思就是通过最近生成的startId来结束Service，如果startId不是最近的生成的，结束操作将会失败，翻译的比较搓，大概意思理解就行。这里就比较清楚了，因为第一次结束Service的时候使用的startId不是最新的（后面又生成了一次，因此第二次产生的startId才是最新的），因此结束操作失败了。这么简单的问题当然难不住机制的我们，需要最新的startId，那我们直接传递最新的startId不就好了？我们将startId保存起来，结束的时候使用最新的startId，代码如下
private int mStartId;
@Override
public void onStart(Intent intent, int startId) {
super.onStart(intent, startId);
Log.i(TAG, "onStart startId:" + startId );
mStartId = startId;
}
@Override
protected void onHandleIntent(Intent intent) {
try {
Thread.currentThread().sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Log.i(TAG, "thread name:" + Thread.currentThread().getName());
Log.i(TAG, "onHandleIntent");
stopSelf(mStartId);
}
运行，大部分情况下我们会看到如下的log输出
intent_service3.png
也许你注意到了我说的是大部分情况，我第一次运行的时候出现了如下的log
intent_service4.png
PS：上图内容为第一次抓到的原始log和上面的代码有一些细微不同
我们回过头来看一下 IntentService 的 onDestroy() 代码
@Override
public void onDestroy() {
mServiceLooper.quit();
}
注意到这里调用的是 Looper 的 quit() 方法，按照方法文档的说法是，quit方法会将所有的没有分发的消息清空，而且MessageQueue的源码也证实了这一点( quit最终会调用MessageQueue的removeAllMessagesLocked方法 )
private void removeAllMessagesLocked() {
Message p = mMessages;
while (p != null) {
Message n = p.next;
p.recycleUnchecked();
p = n;
}
mMessages = null;
}
一般情况下如果出现了执行结果多次不一致的现象，我们可以考虑是多线程引起的异步问题，那么为何会出现多线程异步问题呢？我们知道 onHandleIntent 是在IntentService中创建的子线程中执行，而我们知道Service的生命周期方法，例如 onDestroy() 是在主线程中执行的，这里就会出现执行结果不一致的情况。我们在 onDestroy() 方法中加一些延时
@Override
public void onDestroy() {
try {
Thread.currentThread().sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
super.onDestroy();
Log.i(TAG, "onDestroy " + Thread.currentThread().getName());
}
这时候我们发现log输出基本如下，基本符合我们的预期
intent_service5.png
网友评论