Android開機啟動耗時較多的部分有2個，分別是preloadclasses和scan packages。

這裡又數preloadclasses最為耗時，在我的機子上一般需要13秒左右。關於preloadclasses的優化，可以參見http://www.eoeandroid.com/thread-29953-1-1.html。這篇帖子並沒有給出如何優化preloaded-classes list的具體取捨。實際上，在看過google group眾多關於preload class的主題後，基本可以確定以下事實：

preloaded-classes list中預載入的類位於dalvik zygote程序的heap中。在zygote衍生一個新的dalvik程序後，新程序只需載入heap中沒有預載入的類（這些後加載進來的類成為該程序所private獨有的），這樣便加快了應用程式的啟動速度。實際上這是一種以空間換時間的辦法，因為幾乎沒有一個應用程式能夠使用到所有的預載入類，必定有很多類對於該應用程式來說是冗餘的。但是也正如Google所說，智慧手機開機遠沒有啟動應用程式頻繁——使用者開機一次，但直到下次再開機之前可能要執行多個應用程式。因此犧牲一點啟動時間來換取應用程式載入時的較快速度是合算的。

preloaded-classes list已經是Google Android工程師使用眾多測試工具分析，加以手動微調後形成的最優化預載入列表，涵蓋了智慧機上最長見的應用型別所需要的各種類。很難想象我們自己能夠有什麼手段能夠獲得比這樣更優的一個預載入列表。所以，除非你的Android系統是被移植到非智慧手機裝置上使用（例如MID、EBOOK，可以不需要Telephony相關的類），不建議去“優化”preloaded-classes list。

在zygote中單起一個執行緒來做preload，是否可行？答案是否定的。首先在zygote中不可以新開執行緒，其次，就算新開一個執行緒，在目前智慧機硬體條件下（單核CPU），除非有頻繁大量的儲存IO，否則我們不能看到我們期望加速啟動效果。

關於scanpackages的問題。同樣參考上面提到的那篇帖子，我們從中可以知道一個事實：越少的apk安裝，越短的啟動時間。事實上確實如此，apk安裝的多少的確影響開機速度，但相比而言，scan packages所花費的時間遠沒有preload classe多。似乎這裡沒有多少油水可榨，但起碼我們知道了：儘量減少產品中預置的apk數量可以提升啟動速度（哪怕精簡到極致也許只節省了2s）。

最後，關於那篇帖子中提到的startservices階段，我認為雖然此階段確實需要消耗可觀的時間，但是正如文中提到的那樣，優化這些services其實就是剔除我們不需要的一些services，而且不僅僅是修改SystemServer.java的問題，任何使用到被優化剔除掉的服務的程式碼都必須加以修改，否則系統肯定是起不來的。這樣工作量大，而且難度也不小，並且有一定風險。因此對這些services的優化要慎之又慎。