Android开机启动耗时较多的部分有3个，分别是preloadclasses和scan packages。//preload-resources

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的优化要慎之又慎。