android熱啟動

① android啟動優化概述

Android啟動應用, 按 官方說法 分為冷啟動, 溫啟動和熱啟動.
具體的定義可以看官方文檔, 簡單地說

一般我們只需要關注冷啟動即可.

要想啟動快, 硬體性能必然有影響, 在硬體一定的前提下, 我們要盡量 降低啟動應用時CPU的負載 , 讓CPU有更多的算力投入到啟動流程中:

在做好一些基本原則後, 接著看具體的流程優化點

在應用進程創建後, 首先必然是載入類, 此時一些靜態變數就會初始化了, 因此我們應該

類載入完畢後就是創建 Application 實例了, 因此我們應該

之後會先創建 ContentProvider 和執行 ContentProvider.onCreate() , 因此我們應該

跟接著就會執行 Application.onCreate() 等方法, 因此我們應該

接著就進入 Activity 環節.
同樣第一步會是創建實例, 因此我們應該

在 Activity 進程生命周期後, 第一步就是渲染(inflate)布局, 我們應該

在應用啟動的瞬間, 系統服納虧務會先展示一個空白窗口哪茄殲, 等待應用第一幀繪制完畢後, 再從該窗口切換到應用, 如果啟動耗時較長, 就會明顯看到白屏, 對於這一點, 常見的操作有

可以使用IdleHandler, 在主線程空閑時再執行某些不重要的操作

實際上非同步初始化只是不阻塞主線程, 但是子線程一樣會佔用CPU資源, 讓主線程的執行時間變少, 所以不應該盲目地將所有工作放到子線程.

優化做到最後, 就是在系統流程上做文章了

原理是將啟動時載入的類放到主dex，提升了這些類的內聚，讓更多的類滿足pre-verify的條件，在安裝時就做了校驗和優化，以減少首次載入的耗時，從而優化冷啟動耗時。
Redex 初探與 Interdex：Andorid 冷啟動優化

應用啟動過程中會從apk壓縮包中讀取文件, 該優化的原理是利用Linux中的Pagecache機制, 讓啟動過程會用到的文件盡可能進入緩存中, 減少磁碟IO次數
支付寶 App 構建優化解析：通過安裝包重排布優化 Android 端啟動性能

在Dalvik VM(Android5.0以前)載入類的時候會有一個類校驗過程, 它需要校驗方李沖法的每一個指令, 是一個比較耗時的過程, 可以通過Hook去掉類載入過程中的類驗證過程. 不過對於ART(Android5.0之後)來說, 這個過程在安裝時已經做了, 所以用處不大.

不進入冷啟動, 就不用優化了~

這個Android Studio自帶的工具, 可以看到啟動過程中詳細的方法執行流程, 但是採集數據本身會影響方法執行, 所以不能准確判斷每個方法的耗時, 但是仍可以判斷哪個方法相對來說耗時.

這個工具的好處是可以自定義事件, 可以指定需要採集的數據集, 可以看到線程間的狀態等.

啟動優化的一個關鍵點在於定義啟動結束的點, 以及如何測量啟動時間.

在Android4.4以上, 系統進程會提供一個類似 ActivityManager: Displayed ***: +3s534ms 的日誌, 表示從啟動進程到首次繪制完畢所用的時間.

應用可以在任何時候調用該方法, 觸發系統列印類似 system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms 的日誌

應用可以通過 ViewTreeObserver 來監聽繪制前回調來判斷第一幀的繪制時機, 或者直接在控制項樹的末尾加一個簡單的View, 它 onDraw 調用時即表示頁面(差不多)繪制完畢.

應用啟動過程可以參考 Android Vitals Series' Articles 系列文章

② Android 性能優化 05---App啟動優化

其實啟動框架就是一個任務調度系統，是手淘啟動的「大管家」。
管家要做的事情就是把它們的關系梳理得明明白白，有條不紊，合理安排位置、調度時間，襲嘩同時提升硬體資源的利用率。

總結下來無非就是兩點：

有向無環圖[拓撲排序]

可用方案
APT，位元組碼插樁，利用ContentProvider
面試題LeakCanary 為什麼不需要在Application中手動初始化？

①點擊桌面App圖標，Launcher進程採用Binder IPC向system_server進程發起 startActivity請求；
②system_server進程接收到請求後，向zygote進程發送創建進程的請求；
③Zygote進程fork出新的子進程，即App進程；
④App進程，通過Binder IPC向sytem_server進程發起attachApplication請求；
⑤system_server進程在收到請求後，進皮禪頃行一系列准備工作後，再通過binder IPC 向App進程發送scheleLaunchActivity請求；
⑥App進程的binder線程（ApplicationThread）在收到請求後，通過handler向主 線程發送LAUNCH_ACTIVITY消息；
⑦主線程在收到Message後，通過反射機制創建目標Activity，並回調 Activity.onCreate()等方法。
⑧到此，App便正式啟動，開始進入Activity生命周期，執行完 onCreate/onStart/onResume方法，UI渲染結束後便可以看到App的主界面。

應用有三種啟動狀態，每種狀態都會影響應用向用戶顯示所需的時間：冷啟動、溫啟動與熱啟動。

adb命令啟動應用，一般會輸入三個值：ThisTime、TotalTime與WaitTime。
1.WaitTime：包括前一個應用Activitypause的時間和新應用啟動的時間；
2.ThisTime：表示一連串啟動Activity的最後一個Activity的啟動耗時；
3.TotalTime：表示新應用啟動的耗時，包括新進程的啟動和Activity的啟動，但不包括前一個應用Activitypause
的耗時。

StrictMode是一個開發人員工具，它可以檢測出我們可能無意中做的事情，並將它們提請我們注意，以便我 們能夠修復它們。 StrictMode最常用於捕獲應用程序主線程上的意外磁碟或網路訪問。幫助我們讓磁碟和網路操作遠離主線程， 可以使應用程序更加平滑、響應更快

當系統載入並啟動 App 時，需要耗費相應的時間，這樣會造成用戶會感覺到當點擊 App 圖標時會有 「延遲」 現象，
為了解決這一問題，Google 的做法是燃陸在 App 創建的過程中，先展示一個空白頁面，讓用戶體會到點擊圖標之後立
馬就有響應。
如果你的application或activity啟動的過程太慢，導致系統的BackgroundWindow沒有及時被替換，就會出現啟動
時白屏或黑屏的情況（取決於Theme主題是Dark還是Light）。

消除啟動時的黑/白屏問題，大部分App都採用自己在Theme中設置背景圖的方式來解決。

然後在Activity的onCreate方法，把Activity設置回原來的主題。

這么做，只是提高啟動的用戶體驗。並不能做到真正的加快啟動速度。

③ Android性能優化第（八）篇---App啟動速度優化之耗時檢測處理

應用的啟動速度緩慢這是很多開發者都遇到的一個問題，比如啟動緩慢導致的黑屏，白屏問題，大部分的答案都是做一個透明的主題，或者是做一個Splash界面，但是這並沒有從根本上解決這個問題。那麼如何從根本上解決這個問題或者做到一定程度的緩解？

1、冷啟動：當啟動應用時，後台沒有該應用的進程，這時系統會首先會創建一個新的進程分配給該應用，這種啟動方式就是冷啟動。

2、熱啟動：當啟動應用時，後台已有該應用的進程，比如按下home鍵，這種在已有進程的情況下，這種啟動會從已有的進程中來啟動應用，這種啟動方式叫熱啟動。

3、溫啟動 ：當啟動應用時，後台已有該應用的進程，但是啟動的入口Activity被幹掉了，比如按了back鍵，應用雖然退出了，但是該應用的進程是依然會保留在後台，這種啟動方式叫溫啟動。

adb shell am start -W [PackageName]/[PackageName.MainActivity]

執行成功後將返回三個測量到的時間：

這裡面涉及到三個時間，ThisTime、TotalTime 和 WaitTime。WaitTime 是 startActivityAndWait 這個方法的調用耗時，ThisTime 是指調用過程中最後一個 Activity 啟動時間到這個 Activity 的 startActivityAndWait 調用結束。TotalTime 是指調用過程中第一個 Activity 的啟動時間到最後一個 Activity 的 startActivityAndWait 結束。如果過程中只有一個 Activity ，則 TotalTime 等於 ThisTime。

總結:如果只關心某個應用自身啟動耗時，參考TotalTime；如果關心系統啟動應用耗時，參考WaitTime；如果關心應用有界面Activity啟動耗時，參考ThisTime。

從我們Application開始到首頁顯示出來，這個過程，我們應該注意一些什麼，將這個過程細分一下，會有下面的時間點需要注意。

Application的構造器方法——>attachBaseContext()——>onCreate()——>Activity的構造方法——>onCreate()——>配置主題中背景等屬性——>onStart()——>onResume()——>測量、布局、繪制顯示在界面上。

因為上面這些階段全部都是在主線程中執行的，任何不經意的操作都可能拖慢應用的啟動速度。所以我們不應在Application以及Activity的生命周期回調中做任何費時操作，具體指標大概是你在onCreate，onResume，onStart等回調中所花費的總時間最好不要超過400ms，否則用戶在桌面點擊你的應用圖標後，將感覺到明顯的卡頓。但是有些 不得以的任務 又必須在UI顯示之前執行。所以我們要將 任務 劃分優先順序。

對於首頁渲染完成後，開始載入，或者延遲載入，延遲載入的目的就是界面先顯示出來，然後載入，但是你覺得要延遲多久呢？在 Android 的高端機型上,應用的啟動是非常快的 , 這時候只需要 Delay 很短的時間就可以了, 但是在低端機型上,應用的啟動就沒有那麼快了,而且現在應用為了兼容舊的機型,往往需要 Delay 較長的時間,這樣帶來體驗上的差異是很明顯的。延遲載入有一種方式。

極力推薦用第二種，在窗口完成以後進行載入，這裡面的run方法是在onResume之後運行的。關於這種懶載入機制，參考 Android應用啟動優化:一種DelayLoad的實現和原理(上篇) ，給出了詳細的解釋。

通過上面我們知道一種懶載入機制，所以我們可以將Application中和首頁的onCreate中的有些耗時任務，放到首頁渲染完畢後載入。如何找出這些耗時任務，TraceView就派上用場了，TraceView的用法，移步我的前面的博客 Android性能優化第（六）篇---TraceView 分析圖怎麼看？

比如在首頁的onCreate中我們進行了用戶啟動上報，這個進行懶載入是不是分分鍾減少139毫秒呢？

在比如在Application裡面用到了GSON，將String轉化成json,我將這個移動到懶載入裡面，是不是又減少了100毫秒呢？

在比如，有些Application中做了支付SDK的初始化，用戶又不會一打開App就要支付，放在Application中載入幹嘛？

此處我們這里舉得例子是優化了139毫秒和100毫秒的，其實真正耗時的任務有的有1秒多，都被我優化完了，所以trace圖中看不到了，就舉個了這兩個例子，還有SharedPreferences也是耗時大戶，經過檢測保存一個boolean變數耗時120+毫秒以上。

利用TraceView可以清楚我們每一個方法的耗時時間，極大的幫助了我們做優化工作。

五、優化思路總結
1、UI渲染優化，去除重復繪制，減少UI重復繪制時間，打開設置中的GPU過度繪制開關，各界面過度繪制不應超過2.5x；也就是打開此調試開關後，界面整體呈現淺色，特別復雜的界面，紅色區域也不應該超過全屏幕的四分之一；
2、根據優先順序的劃分，KoMobileApplication的一些初始化工作能否將任務優先順序劃分成3,在首頁渲染完成後進行載入，比如：PaySDKManager。
3、主線程中的所有SharedPreference能否在非UI線程中進行，SharedPreferences的apply函數需要注意，因為Commit函數會阻塞IO，這個函數雖然執行很快，但是系統會有另外一個線程來負責寫操作，當apply頻率高的時候，該線程就會比較佔用CPU資源。類似的還有統計埋點等，在主線程埋點但非同步線程提交，頻率高的情況也會出現這樣的問題。
4、檢查BaseActivity,不恰當的操作會影響所有子Activity的啟動。
5、對於首次啟動的黑屏問題，對於「黑屏」是否可以設計一個.9圖片替換掉，間接減少用戶等待時間。
6、對於網路錯誤界面，友好提示界面，使用ViewStub的方式，減少UI一次性繪制的壓力。
7、任務優先順序為2，3的，通過下面這種方式進行懶載入的方式

8、Multidex的使用，也是拖慢啟動速度的元兇，必須要做優化。後面有空專門寫一篇Multidex。

相關鏈接：

Android應用啟動優化:一種DelayLoad的實現和原理(上篇)http://androidperformance.com/2015/11/18/Android-app-lunch-optimize-delay-load.html

Android性能優化之加快應用啟動速度http://www.open-open.com/lib/view/open1452821612355.html

手機淘寶性能優化全記錄http://www.open-open.com/lib/view/open1452488209370.html

Android客戶端性能優化（魅族資深工程師毫無保留奉獻）http://blog.tingyun.com/web/article/detail/155#rd

Please accept mybest wishes for your happiness and success !

④ 如何優化 android 系統應用的啟動速度

一、應用的啟動

啟動方式

通常來說，在安卓中應用的啟動方式分為兩種：冷啟動和熱啟動。

• 1、冷啟動：當啟動應用時，後台沒有該應用的進程，這時系統會重新創建一個新的進程分配給該應用，這個啟動方式就是冷啟動。

• 2、熱啟動：當啟動應用時，後台已有該應用的進程（例：按back鍵、home鍵，應用雖然會退出，但是該應用的進程是依然會保留在後台，可進入任務列表查看），所以在已有進程的情況下，這種啟動會從已有的進程中來啟動應用，這個方式叫熱啟動。

特點

1、冷啟動：冷啟動因為系統會重新創建一個新的進程分配給它，所以會先創建和初始化Application類，再創建和初始化MainActivity類（包括一系列的測量、布局、繪制），最後顯示在界面上。

2、熱啟動：熱啟動因為會從已有的進程中來啟動，所以熱啟動就不會走Application這步了，而是直接走MainActivity（包括一系列的測量、布局、繪制），所以熱啟動的過程只需要創建和初始化一個MainActivity就行了，而不必創建和初始化Application，因為一個應用從新進程的創建到進程的銷毀，Application只會初始化一次。

上面說的啟動是點擊app的啟動圖標來啟動的，而另外一種方式是進入最近使用的列表界面來啟動應用，這種不應該叫啟動，應該叫恢復。

二、應用啟動的流程

在安卓系統上，應用在沒有進程的情況下，應用的啟動都是這樣一個流程：當點擊app的啟動圖標時，安卓系統會從Zygote進程中fork創建出一個新的進程分配給該應用，之後會依次創建和初始化Application類、創建MainActivity類、載入主題樣式Theme中的windowBackground等屬性設置給MainActivity以及配置Activity層級上的一些屬性、再inflate布局、當onCreate/onStart/onResume方法都走完了後最後才進行contentView的measure/layout/draw顯示在界面上，所以直到這里，應用的第一次啟動才算完成，這時候我們看到的界面也就是所說的第一幀。

所以，總結一下，應用的啟動流程如下：

Application的構造器方法——>attachBaseContext()——>onCreate()——>Activity的構造方法——>onCreate()——>配置主題中背景等屬性——>onStart()——>onResume()——>測量布局繪制顯示在界面上。

三、測量應用啟動的時間

在上面這個啟動流程中，任何一個地方有耗時操作都會拖慢我們應用的啟動速度，而應用啟動時間是用毫秒度量的，對於毫秒級別的快慢度量我們還是需要去精確的測量到到底應用啟動花了多少時間，而根據這個時間來做衡量。

什麼才是應用的啟動時間

從點擊應用的啟動圖標開始創建出一個新的進程直到我們看到了界面的第一幀，這段時間就是應用的啟動時間。

我們要測量的也就是這段時間，測量這段時間可以通過adb shell命令的方式進行測量，這種方法測量的最為精確，命令為：

• adb shell am start -W [packageName]/[packageName.MainActivity]



執行成功後將返回三個測量到的時間：
1、ThisTime:一般和TotalTime時間一樣，除非在應用啟動時開了一個透明的Activity預先處理一些事再顯示出主Activity，這樣將比TotalTime小。
2、TotalTime:應用的啟動時間，包括創建進程+Application初始化+Activity初始化到界面顯示。
3、WaitTime:一般比TotalTime大點，包括系統影響的耗時。

下面是測量一個應用冷啟動和熱啟動的時間：
冷啟動：


熱啟動：




以上就是本文的全部內容，希望對大家學習Android軟體編程有所幫助。

⑤ Activity的啟動流程

開發中我們會調用startActivity來啟動一個Activity，最終會調到 startActivityForResult ：

Instrumentation 是Android系統裡面的一套控制方法或者「鉤子」。這些鉤子可以在正常的生命周期（正常是由操作系統控制的）之外控制Android控制項的運行。

Application和Activity的所有生命周期中，都會先調用Instrumentation提供的相應方法（如callActivityOnCreate，callApplicationOnCreate，newActivity，callActivityOnNewIntent）

Instrumentation.execStartActivity

ActivityTaskManager.getService()返回了一個IActivityTaskManager，拿到的是ATMS的代理對象，跨進程調用了ATMS的startActivity方法。

ActivityStarter.startActivityMayWait

ActivityStarter中做了一系列的調用（收集Intent信息，處理startActivityForResult，做一些校驗判斷等），最終進入startActivityUnchecked。

startActivityUnchecked

startActivityUnchecked中處理了關於Activity啟動模式的處理，接著真正的resume我們的Activity

這里會先判斷應用進程是否創建，創建了就進入 realStartActivityLocked ，沒創建就會調用 ActivityManagerInternal.startProcess

①熱啟動realStartActivityLocked

接著看ActivityThread中接收並處理消息的handleMessage

前面realStartActivityLocked方法中通過addCallback，傳入參數LaunchActivityItem。executeCallbacks方法中取出callbacks集合中的LaunchActivityItem，並調用其execute方法

handleLaunchActivity

②冷啟動創建應用進程ActivityManagerInternal.startProcess

ActivityManagerInternal的實現類是AMS中的LocalService，AMS通過Socket與Zygote通信，fork出App進程，app進程創建後，會執行ActivityThread的main方法（Android進程入口方法）

調用ActivityThread的attach

[4]thread.bindApplication 這是一個binder通信的過程

ActivityThread內部的Handler接收到BIND_APPLICATION消息

回到上面attachApplicationLocked的mAtmInternal.attachApplication，調用ATMS的attachApplication

看到了似曾相識的realStartActivityLocked，後面流程和之前一樣。Activity啟動流程分析完畢。

總結

1）與Activity管理有關的類：

ActivityRecord ：歷史棧中的一個條目，代表一個Activity

TaskRecord ：內部維護了一個ArrayList<ActivityRecord> ，來保存ActivityRecord

ActivityStack ：內部維護了一個ArrayList<TaskRecord>，用來管理TaskRecord

ActivityStackSupervisor ：用來管理ActivityStack的

2）Activity啟動流程

⑥ 使用adb查看別人家APP的數據

1.說明
2.使用adb命令獲取指定應用的包名和Activity名稱
3.使用adb命令啟動/關閉APP
4.使用adb命令把手機中的apk導到電腦上
5.查看apk中的AndroidManifest.xml文件
6.使用adb命令進行數據備份
7.查看數據
8.結語

查看其它APP數據的前提是該APP默認開啟數據備份，也就是allowBackup屬性。
想問一下大家在平時的開發中對應用的安全性有很在意么？有可能大家會想到加密、混淆、apk加固，但還有一些其他細節的東西需要大家去了解。今天就介紹一下android:allowBackup屬性。這個屬性在開發的過程中通常是默認開啟的，Google起初是為了防止數據丟失，留下了這個功能，但是這個屬性也容易造成一些隱私數據的泄露。如果你想關閉可以把它設置為false。那麼這個屬性在哪裡設置呢，就在AndroidManifest.xml文件中的application標簽中。

要備份APP的數據，首先我們要知道這個APP的包名才可以進行備份。

在手機或模擬器上面運行APP，然後輸入命令： adb shell mpsys activity top #
這時會輸出很多東西，你可以用查找功能Ctrl+F，找到TASK，下圖紅框中就是要找的包名

命令： adb logcat| findstr START
然後在手機或模擬器上點擊你想要獲取的應用，這時就會在cmd中出現相應的包名和類名了。

啟動APP的命令： adb shell am start -W -n package/activity

命令窗口通過adb shell 進入android 的Linux命令界面，輸入am help看到如下信息：

它會展示出在不同場景下（比如start-activity、start-service等）不同參數代表的意義一些參數的意義，情況太多了這里就不細說了。

回到正題，後面的package和activity就是上面獲取包名第二種方法中提到的cmp，比如我們要啟動谷歌地圖： adb shell am start -W -n com.google.android.apps.maps/com.google.android.maps.MapsActivity

在這里我們再做一個延伸， 用命令做APP的冷啟動和熱啟動操作，然後記錄啟動的時間
我們看到上圖中有三個數字ThisTime、TotalTime和WaitTime，這三個數字就是本次啟動APP所花費的時間。
熱啟動時退出退出APP的命令： adb shell input keyevent 3 ，這就相當於按了手機的home鍵，然後我們再執行啟動APP的命令，這樣就完成了熱啟動。

我們看到熱啟動花費的時間比冷啟動少了很多，一套冷、熱啟動的流程我們就走完了。接下來就看我們怎麼去優化了，讓它們變的更少。所以我們在平時做啟動優化的時候可以把自己的APP和一些優秀的APP做一下對比看看還差多少。

上面已經說過了一種退出APP的方法了，接下來這個命令是相當於殺掉當前的APP進程。
命令： adb shell am force-stop package
這時候再使用啟動命令，就相當於冷啟動了。

有的時候我們在手機上查看和操作apk不是特別方便，而且通過文件管理找apk也很難找。接下來就介紹怎麼用adb命令把手機中的apk導到電腦上。

通過包名獲取apk在手機中的存儲路徑，命令 adb shell pm path package

導出apk文件，到當前目錄下
命令： adb pull 路徑

這一步就要看一下apk中有哪些東西了，主要還是看一下AndroidManifest.xml文件當中的allowBackup設置。
我平常用的方法就是吧apk文件的後綴該成zip，然後就可以看到裡面的東西了。下面的是谷歌地圖的apk的構成。

下面來看一下AndroidManifest.xml文件，會看到都是亂碼，但是關鍵的信息還是可以獲取的，我們目前想要的就是下圖紅框中的allowBackup屬性，像谷歌的APP肯定是把它設置成false的，所以我們沒辦法備份它的信息的。

那麼我們怎麼看一個應用的allowBackup屬性設置成true還是false呢，我的觀察和實踐出來的方法是看allowBackup後面有沒有小方框，有就代表設置了true。如果有哪位大神知道好的可靠的方法還請留言告知。

下面是其他apk中的AndroidManifest.xml文件，後面帶了個小方框。

在了解到APP可以備份之後，我們就可以開始做壞事了，哈哈。
備份的命令： adb backup -nosystem -all -noapk -noshared -f data.ab package

[-system | -nosystem] 是否備份系統
[-apk | -noapk] 是否備份apk安裝文件
[-shared | -noshared] 是否備份手機存儲空間
-f *.ab 存檔格式一定要是.ab
package：包名

在運行命令之後，手機或模擬器會出現一個頁面要求你輸入備份密碼，這個密碼你可以隨便輸入，但你要記住，在後面查看ab文件的時候會用到。

輸入密碼，點擊【備份我的數據】之後就開始備份了，備份完成之後會有提示，這時就是生產一個ab文件了。

ab文件大家很少接觸，這里使用abe工具（鏈接： https://pan..com/s/1NPbhtF1fyJcHOm1CXwi9Dg

寫這篇文章還是提醒大家在平時的開發中要注重APP數據的安全問題，畢竟數據還是相當重要的。
如果有哪裡寫的不對的地方，請指出，我會及時改正。

⑦ 如何加快Android應用啟動速度

• 應用的啟動

  通常來說，在安卓中應用的啟動方式分為兩種：冷啟動和熱啟動。

1. 當啟動應用時，後台沒有該應用的進程，這時系統會重新創建一個新的進程分配給該應用，這個啟動方式就是冷啟動。

2. 當啟動應用時，後台已有該應用的進程（例：按back鍵、home鍵，應用雖然會退出，但是該應用的進程是依然會保留在後台，可進入任務列表查看），所以在已有進程的情況下，這種啟動會從已有的進程中來啟動應用，這個方式叫熱啟動。

• 應用啟動的流程

  Application的構造器方法——>attachBaseContext()——>onCreate()——>Activity的構造方法——>onCreate()——>配置主題中背景等屬性——>onStart()——>onResume()——>測量布局繪制顯示在界面上。

• 減少應用啟動時的耗時

1. 在Application的構造器方法、attachBaseContext()、onCreate()方法中不要進行耗時操作的初始化，一些數據預取放在非同步線程中，可以採取Callable實現。

2. 對於sp的初始化，因為sp的特性在初始化時候會對數據全部讀出來存在內存中，所以這個初始化放在主線程中不合適，反而會延遲應用的啟動速度，對於這個還是需要放在非同步線程中處理。

3. 對於MainActivity，由於在獲取到第一幀前，需要對contentView進行測量布局繪制操作，盡量減少布局的層次，考慮StubView的延遲載入策略，當然在onCreate、onStart、onResume方法中避免做耗時操作。