【翻译】configuration changes与handler.post

public class MyActivity extends Activity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Log.d("Square", "onCreate()");
if (savedInstanceState == null) {
Log.d("Square", "Requesting orientation change");
setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE);
}
} protected void onResume() {
super.onResume();
Log.d("Square", "onResume()");
} protected void onPause() {
super.onPause();
Log.d("Square", "onPause()");
} protected void onDestroy() {
super.onDestroy();
Log.d("Square", "onDestroy()");
}
}

If you know the Android lifecycle, you probably predicted this:

如果你知道Android lifecycle这篇文章，你可能这么预测：

The Android Lifecycle goes on normally, the activity is created, resumed, and then the orientation change is taken into account and the activity is paused, destroyed, and a new activity is created and resumed. 正常来说应该是这样的，activity created, resumed，然后才考虑orientation change行为的触发，这时， activity 再执行 paused, destroyed，然后新的activity重新执行,created 和 resumed方法。

Orientation changes 和主线程

此处有一个重要的细节需要注意： orientation change行为会导致activity被重新创建。而这一行为仅通过

post一个消息给主线程的方式来实现。

下面我们可以通过反射来检测主循环队列 中的内容

public class MainLooperSpy {
private final Field messagesField;
private final Field nextField;
private final MessageQueue mainMessageQueue; public MainLooperSpy() {
try {
Field queueField = Looper.class.getDeclaredField("mQueue");
queueField.setAccessible(true);
messagesField = MessageQueue.class.getDeclaredField("mMessages");
messagesField.setAccessible(true);
nextField = Message.class.getDeclaredField("next");
nextField.setAccessible(true);
Looper mainLooper = Looper.getMainLooper();
mainMessageQueue = (MessageQueue) queueField.get(mainLooper);
} catch (Exception e) {
throw new RuntimeException(e);
}
} public void dumpQueue() {
try {
Message nextMessage = (Message) messagesField.get(mainMessageQueue);
Log.d("MainLooperSpy", "Begin dumping queue");
dumpMessages(nextMessage);
Log.d("MainLooperSpy", "End dumping queue");
} catch (IllegalAccessException e) {
throw new RuntimeException(e);
}
} public void dumpMessages(Message message) throws IllegalAccessException {
if (message != null) {
Log.d("MainLooperSpy", message.toString());
Message next = (Message) nextField.get(message);
dumpMessages(next);
}
}
}

如你所见，消息队列仅仅是个链表

下面是 orientation change 触发之后的 消息队列中的记录：

public class MyActivity extends Activity {
private final MainLooperSpy mainLooperSpy = new MainLooperSpy(); protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Log.d("Square", "onCreate()");
if (savedInstanceState == null) {
Log.d("Square", "Requesting orientation change");
setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE);
mainLooperSpy.dumpQueue();
}
}
}

Here is the output:

onCreate()
Requesting orientation change
Begin dumping queue
{ what=118 when=-94ms obj={1.0 208mcc15mnc en_US ldltr sw360dp w598dp h335dp 320dpi nrml land finger -keyb/v/h -nav/h s.44?spn} }
{ what=126 when=-32ms obj=ActivityRecord{41fd2b48 token=android.os.BinderProxy@41fcce50 no component name} }
End dumping queue

通过查看ActivityThread的实现，我们可以知道消息118,126代表的是什么：

当发起一个orientation change操作时，实际上就是把 CONFIGURATION_CHANGED 和 RELAUNCH_ACTIVITY消息添加到了主循环队列中。

下面我们来一步步的分析：

当activity第一次启动时，消息队列是空的。 当前正在执行的消息是LAUNCH_ACTIVITY。

LAUNCH_ACTIVITY消息的处理过程是这样的：首先创建一个

activity 实例，然后调用onCreate方法和onResume方法。然后LAUNCH_ACTIVITY消息就算完成了，主循环继续去运行下一条消息。

When a device orientation change is detected, a RELAUNCH_ACTIVITY is posted to the queue.

当orientation change事件被监测到的时候，RELAUNCH_ACTIVITY消息被添加到队列中来。

消息处理过程是这样的：

• 依次调用旧activity的 onSaveInstanceState(), onPause(), onDestroy() 方法
• 创建一个新的activity实例,
• 依次调用新activity实例的onCreate() 和onResume()方法。

这一过程都包含在一个消息中处理。也就是说，在上述过程中，任何post调用都会在onResume() 方法之后被调用。

现在放到一起来看下

如果你在onCreate中post一个消息， 而此时恰好orientation change事件也被触发，会出现什么样的情况？

看下面两个例子，注意orientation change前后的log:

Here is the output:

总结一下：在onCreate方法执行到最后时，消息队列中含有4个消息。第一个消息时orientation change之前添加的post消息，紧接着的两个消息是与orientation change相关联的两个消息，然后是orientation change之后添加的post消息。可以在日志中看到他们是有序进行的。

也就是说，任何在orientation change之前添加的消息都会在onPause调用之前被调用，任何在orientation change之后添加的消息都会在
onResume调用之后被调用。

实际的意义在于，当你发生一个post消息时，你不能保证activity实例在消息执行时还存在(即便你是在 onCreate() or onResume()中调用的post).如果你的消息持有View或者activity的引用，则activty将不会被及时回收。
 

所以，我们应该怎么做呢?

彻底的解决办法

不要在主线程下啊调用handler.post(). 在大部分情况下，handler.post() 被用于快速修复一些与时序相关的问题。

推荐的做法是修改你的程序逻辑，而不是乱调handler.post()方法。

如果确实不得不调用post

请确定你在做后台操作时，不持有activity的引用~

好吧，如果你确实需要引用activity

那么请在activityonPause里面调用

handler.removeCallbacks()来确保消息队列清空。

当然，如果你想被开除的话，你可以这么做：

使用handler.postAtFrontOfQueue() 去确保消息总是在 onPause() 之前抵用. 然后你的代码就会变得很难懂。。。

顺便提一下runOnUiThread()

你有没注意到我们使用 handler.post()而不是直接调用Activity.runOnUiThread()?

看下面你就明白了:

Unlike handler.post(), runOnUiThread() does not post the runnable if the current thread is already the main thread. Instead, it calls run() synchronously.

和handler.post()不一样, runOnUiThread()下，如果当前线程就是主线程的时候，它是直接同步调用runnable方法的。

关于服务

这有一个常见的误解需要澄清一下: service 并不运行在后台线程中

所有的，service 生命周期相关方法如onCreate(), onStartCommand()，都是在主线程中运行的

不管是在service还是在activity中，长时间的任务都应该交给后台线程。后台线程的存活期可以和应用本身一样长。

但是，有时候 系统可能会杀掉app进程。

使用service 有助于我们尽可能的延长引用的存活期。

边注: 当IBinder接收到另一个进程的调用时，方法将会在后台线程中调用。

Take the time to read the Service documentation – it’s pretty good.

结论

大部分Android 生命周期相关的方法都在主线程中调用。

必须再啰嗦一句：不要阻塞主线程！！！

不过，你有没想过阻塞主线程是啥效果？请看下章

Have you ever wondered what blocking the main thread actually means? That’s the subject of the next part!