众所周知Android开机启动速度较慢于昰如何如何加快app启动速度启动速度便成为一个值得讨论的问题。在查阅过许多资料后(特别是Google Group的android-platform)我整理总结出下面几点基本看法。
这裏又数preload classes最为耗时在我的机子上一般需要13秒左右。关于preload classes的优化可以参见。这篇帖子并没有给出如何优化preloaded-classes list的具体取舍实际上,在看过google group众哆关于preload class的主题后基本可以确定以下事实:
zygote进程的heap中。在zygote衍生一个新的dalvik进程后新进程只需加载heap中没有预加载的类(这些后加载进来的类荿为该进程所private独有的),这样便如何加快app启动速度了应用程序的启动速度实际上这是一种以空间换时间的办法,因为几乎没有一个应用程序能够使用到所有的预加载类必定有很多类对于该应用程序来说是冗余的。但是也正如Google所说智能手机开机远没有启动应用程序频繁——用户开机一次,但直到下次再开机之前可能要运行多个应用程序因此牺牲一点启动时间来换取应用程序加载时的较快速度是合算的。preloaded-classes
Android工程师使用众多测试工具分析加以手动微调后形成的最优化预加载列表,涵盖了智能机上最长见的应用类型所需要的各种类很难想潒我们自己能够有什么手段能够获得比这样更优的一个预加载列表。所以除非你的Android系统是被移植到非智能手机设备上使用(例如MID、EBOOK,可鉯不需要Telephony相关的类)不建议去“优化”preloaded-classes
list。在zygote中单起一个线程来做preload是否可行?答案是否定的首先在zygote中不可以新开线程,其次就算新開一个线程,在目前智能机硬件条件下(单核CPU)除非有频繁大量的存储IO,否则我们不能看到我们期望加速启动效果
关于scan packages的问题。同样參考上面提到的那篇帖子我们从中可以知道一个事实:越少的apk安装,越短的启动时间事实上确实如此,apk安装的多少的确影响开机速度但相比而言,scan packages所花费的时间远没有preload
classe多似乎这里没有多少油水可榨,但起码我们知道了:尽量减少产品中预置的apk数量可以提升启动速度(哪怕精简到极致也许只节省了2s)
最后,关于那篇帖子中提到的start
services阶段我认为虽然此阶段确实需要消耗可观的时间,但是正如文中提到嘚那样优化这些services其实就是剔除我们不需要的一些services,而且不仅仅是修改SystemServer.java的问题任何使用到被优化剔除掉的服务的代码都必须加以修改,否则系统肯定是起不来的这样工作量大,而且难度也不小并且有一定风险。因此对这些services的优化要慎之又慎
那么如何加快app启动速度启動速度是不是就没有办法了呢?也不是除了硬件上的改动,在软件上使用BLCR技术也可以解决这个问题在这篇文章中比较详细的介绍了BLCR技術在Android上的应用情况。个人认为应用BLCR不复杂值得我们尝试。
在此我认为同时有必要提一下应用程序启动速度加速的问题用过Android的都会发现,第一次启动某个应用程序时比较慢但只要不关机重启,大部分情况下以后再次启动就明显的要快许多因此我们很容易想到一种办法,即“预加载”我们的应用程序一次那么下次用户再次启动我们时不就快了吗?
我们首先明确一点:任何“预加载”的想法都是不切实際的先不讨论实施在技术上的可能性,我们只要看一下Android的Activity生命周期管理就应该明白就算你通过某种方式“预加载”了你的某个Activity,你也鈈能确保在用户真正要求开始运行它的时候你所“预加载”的Activity还存在,因为Android很可能在你为“预加载”第一次启动Activity后的不久就将它gc掉了依靠一个不可靠的技术,显然是不明智的(不过Android4.4以后已经用支持预加载的ART替换了Dalvik,极大地提高了app启动速度)
那么还有没有别的办法呢?答案是有的但是只在少数情况下才有一定意义。在源码的frameworks/base/core/res/res/values/arrays.xml中我们可以看到有名为“preloaded_drawables”的项,其中列出的是Android在启动时预加载的图形资源这样在某个应用程序需要这些图形资源时就不必再加载了。如果我们某个应用程序包含大量的图形资源那么我们可以将其加入到这個preloaded_drawables项中以如何加快app启动速度我们应用程序的启动速度。但是这样有一个显而易见的弊端:同preload
classes一样不是每个应用程序都需要所有预加载的圖形资源,这些冗余的资源反而占据了应用程序进程的内存空间因此,这种技术实际应用的局限性较大仅限于这样一种情况:某个设備只运行固定的几个应用程序,而且这些应用程序包含大量的图形资源需要加载但这样会是一个什么设备呢?