In the previous part we took a dive into loopers and handlers and how they relate to the Android main thread.
Today, we will take a closer look at how the main thread interacts with the Android components lifecycle.
Activities love orientation changesLet's start with the activity lifecycle and the magic behind the handling of configuration changes.
Why it mattersThis article was inspired by a real crash that occurred in Square Register.
A simplified version of the code is:
As we will see, de>doSomething()de> can be called after the activity de>onDestroy()de> method has been called due to a configuration change. At that point, you should not use the activity instance anymore.
A refresher on orientation changesThe device orientation can change at any time. We will simulate an orientation change while the activity is being created using Activity#setRequestedOrientation(int).
Can you predict the log output when starting this activity in portrait?
de >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()"); }}de>If you know the Android lifecycle, you probably predicted this:
de >onCreate()Requesting orientation changeonResume()onPause()onDestroy()onCreate()onResume()de>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.
Orientation changes and the main threadHere is an important detail to remember: an orientation change leads to recreating the activity via a simple post of a message to the main thread looper queue.
Let's look at that by writing a spy that will read the content of the looper queue via reflection:
de >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.de>Tag:
Freenovo 发表于2014-03-03 17:56:00 | 编辑 | 分享 0
引用地址: