onStop 在 onDestroy 之后被調用？

Question

我在Activity生命周期中遇到了一個相當奇怪的問題。

短前傳：

我發現的第一個症狀是，當我在onStart中注冊接收器后嘗試在onStop中取消注冊接收器時，它與IllegalArgumentException一起崩潰。

在轉儲活動接收器的完整列表（一些反射魔法）之后，我發現我的接收器不在列表中。 它要么被錯誤地移除到其他地方，要么在onDestroy調用Activity期間被移除（在onDestroy ActivityThread調用ContextImpl#performFinalCleanup ，然后調用Context LoadedApk#removeContextRegistrations ）。

怎么了？

在向崩潰添加更多分析信息后，我發現當崩潰發生在onStop時， Activity處於一個非常奇怪的 state - isDestroyed()調用返回true ， isFinishing()返回false ，它是getLifecycle().getCurrentState()返回DESTROYED ...

檢查正常的onStop() （沒有崩潰）調用表明Activity位於此 state 中：

isDestroyed()為false ， CREATED getLifecycle().getCurrentState()在onStop中創建。

所以我得出的結論是onStop在onDestroy之后被調用，我認為這是不可能的，但它似乎發生了。

並且onStop絕對不會被應用程序中的其他東西手動調用，因為這是調用onStop的位置的堆棧跟蹤。

com.myapp.TheActivity.onStop (TheActivity.java:217)
android.app.Instrumentation.callActivityOnStop (Instrumentation.java:1474)
android.app.Activity.performStop (Activity.java:8189)
android.app.ActivityThread.callActivityOnStop (ActivityThread.java:4994)
android.app.ActivityThread.performStopActivityInner (ActivityThread.java:4967)
android.app.ActivityThread.handleStopActivity (ActivityThread.java:5047)
android.app.servertransaction.TransactionExecutor.performLifecycleSequence (TransactionExecutor.java:233)
android.app.servertransaction.TransactionExecutor.cycleToPath (TransactionExecutor.java:201)
android.app.servertransaction.TransactionExecutor.executeLifecycleState (TransactionExecutor.java:173)
android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:97)
android.app.ActivityThread$H.handleMessage (ActivityThread.java:2220)
android.os.Handler.dispatchMessage (Handler.java:107)
android.os.Looper.loop (Looper.java:237)
android.app.ActivityThread.main (ActivityThread.java:8016)
java.lang.reflect.Method.invoke (Method.java)
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:493)
com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1076)

Answer 1

原因尚不清楚，但最近越來越受到關注。 它發生在 onResume/onPause 和 onStart/onStop 對中調用注冊/取消注冊。 關於這些生命周期檢查，請確保您擁有帶有 hashCode() 或其他東西的活動實例。 無論如何，要解決此問題，最佳做法是將注冊/取消注冊調用包裝在 try/catch 塊中：

private void registerBroadcastReceiver() {
    try {
        appUpdateReceiver = new AppUpdateReceiver();
        registerReceiver(appUpdateReceiver, appUpdateIntentFilter);
    } catch (IllegalArgumentException e) {
        // already registered
    }

}

private void unregisterBroadcastReceiver() {
    try {
        unregisterReceiver(appUpdateReceiver);
    } catch (IllegalArgumentException e) {
        // already unregistered
    }
}

Answer 2

我不完全確定為什么會首先發生這種情況，但是我在其中一個小米設備上遇到了類似的事情，這些事情在任何模擬器（或我的設備）上都沒有發生，但發生在別人的手機上。 在應用程序移至后台 5 秒后調用onStop() ，但立即調用onPause() 。 更奇怪的問題，如果在這 5 秒之間，我從任務管理器打開應用程序，就會onStart() 。 （注意 2 個onStart()調用，但不是單個onStop()調用。）我認為如果活動被銷毀， onDestroy()將在onStop()之前調用。 作為替代方案，您可以嘗試將接收者注冊調用移動到onResume()和onPause()而不是onStart()和onStop() 。

第二：在檢查恢復或暫停 state 時，我不完全使用活動的生命周期，但我建議覆蓋所有這些方法（onPause、onResume 等），將 state 存儲在 Z824E2EAC64F38A2DA78 變量上state 同時檢查實際呼叫。 也許這會導致不同的 state 因為這是一個非常不尋常的檢查。

如果它沒有發生在其他活動上，那么在該活動中，可能有一些東西正在向主消息循環器發布如此多的回調，從而阻止onStop()由於溢出而首先被調用，從而導致發生此異常。 當然，這些只是假設，但如果它們在某種程度上有所幫助，我將不勝感激。