概述
近期碰到activity onstop延遲迴調10s的問題。
關於問題的具體復現和原因，有博主總結的很不錯，此處給上原鏈接：
深入分析Android中Activity的onStop和onDestroy()回調延時及延時10s的問題
此文主要記錄一下筆者目前認爲的解決方案，以及各方案的優劣。
1、避免過度頻繁或耗時的主線程操作
假設現在是ActivityOne跳轉到ActivityTwo，那麼有兩種情況都會導致延遲執行：
- ActivityOne頻繁執行主線程操作，比如一些循環執行的動畫操作。
- ActivityTwo在onCreate或者onStart中執行一些耗時或者頻繁的主線程操作。
優勢
從根源上解決了問題。
劣勢
- 去動原來的邏輯就意味着風險，改動越大風險越大。
- 實際項目中，模塊間往往是解耦的。有可能ActivityOne是我負責的，而ActivityTwo則是其他團隊負責了。
- 有些頻繁或者耗時的主線程操作由於業務原因沒法去掉，或者去掉的風險太高。
2、使用EventBus
假設現在是ActivityOne跳轉到ActivityTwo，那麼在ActivityTwo執行到onCreate的時候就拋出事件，然後在ActivityOne中接收事件，做與onstop中一樣的處理。
優勢
幾乎不會影響代碼原來的邏輯，風險很低。
劣勢
- 項目需要支持EventBus。（EventBus一旦濫用，代碼會非常噁心，因此很多項目直接不允許用EventBus）
- 這種情況更適合一些公用的頁面，比如登錄頁面，webview頁面，視頻播放頁面等。在這些場景下，拋出這個事件纔會比較合理。
- 如果原來沒有這塊邏輯，仍然需要在兩個activity中都改。
3、監控所有activity的生命週期
假設現在是ActivityOne跳轉到ActivityTwo，在ActivityOne中監控所有activity的生命週期，在ActivityTwo的onCreate執行到的時候，去執行onstop的邏輯。
優勢
只需要在ActivityOne中新增邏輯即可，不需要動ActivityTwo。
劣勢
- 需要靠譜的識別activity的方式。如果僅使用ActivityTwo的類名作爲識別方式，那麼如果ActivityTwo一旦改名，這塊邏輯就會有問題。
- 難以判斷行爲軌跡，假設現在有A,B,C三個activity。
我只想監控A到B的情況，如果我只判斷B的onCreate的話，那麼如果A到C再到B也會被監控到。