Android4.0开机启动速度优化过程经验总结
笔者EDE101使用的平台是：A10+android4.0.4+16GB NAND+1G DDR+(1280 X RGB X 800)。项目进入收尾阶段，需要着重解决一下开机速度的问题，客户反映还是太慢了一点，当然我们得列入高优先级重点攻关解决了。优化开机速度前，平均android启动速度大概在39秒样子，A10跑1G。以下测试开关机都是按电源键正常操作。系统突然掉电的情况下，重新开机文件系统需要做recovery，在EDE101
16G NAND版本上需要多花4-5秒启动时间，文件系统使用的是EXT4，这种情况类似电脑掉电关机，重启需要扫描检测硬盘一样。
/*****************************************************************************************************/
声明：本博内容均由http://blog.csdn.net/sundesheng125原创，转载请注明出处，谢谢！
/*****************************************************************************************************/
优化前测试数据：
EDE101 2012-11-21发布的软件+16G Nand
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
|
39 |
42 |
36 |
38 |
41 |
41 |
40 |
37 |
40 |
39 |
平均：39.3
关闭打印信息，就是控制打印的级别，具体就是loglevel从默认的8修改为1，几乎没什么打印信息出来，修改后测试数据如下：
EDE101 2012-11-21软件去掉串口打印输出+16G Nand
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
|
35 |
34.6 |
37 |
36.2 |
33 |
36 |
36 |
32 |
33 |
36 |
|
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
|
36.3 |
34 |
38 |
35 |
39 |
36 |
35 |
36.7 |
37 |
35 |
平均: 35.5
还是降低了蛮多的，有3.8秒多，确实打印信息对启动速度的影响还是蛮大的。那么除了这个还可以查找哪些呢？笔者怀疑NAND，因此把原来两片8GB NAND，去掉一片后，测试数据如下：
EDE101 2012-11-21软件去掉串口打印输出 + 8G Nand Flash
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
|
31 |
31.1 |
32.8 |
31.1 |
32.1 |
32.8 |
34.4 |
33.9 |
30.4 |
30.3 |
|
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
|
30.5 |
32.4 |
33.7 |
31.5 |
31 |
31.5 |
32.8 |
31.6 |
31.8 |
31.6 |
平均：31.9
又是有比较大的变化，因此说明启动过程中nand的检测、校验、建表等还是很影响速度的。优化一下相应的部分应该可以提高几秒的速度。
笔者另外还有一个项目EDE103，平台：A10+android4.0.4+8GB NAND+512M DDR+(800 X RGB X 480),使用的电阻屏。去掉打印后，启动速度数据如下：
EDE103 2012-11-21软件去掉串口打印输出
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
|
25.6 |
27 |
25 |
25.7 |
24.7 |
24.1 |
23.6 |
27 |
25.4 |
26.6 |
|
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
|
26.3 |
24.8 |
23.7 |
26.1 |
25.8 |
27.3 |
23.7 |
24.1 |
25.6 |
24.6 |
平均：25.38
为什么这个项目启动速度会快这么多呢？笔者开始百思不得其解。虽然知道从理论上，大分辨率的启动时候LCD处理的数据要大很多，有一定影响，但是也差得有点太多了，感觉不正常。
笔者分析了一下两者启动打印信息，
对E901-902 & EDE101打印信息分析比较：
1、rtp比ctp少开销300ms；
2、gc0308比GT2005少开销640ms；
3、fm radio需要大概110ms（最新已经省去检测步骤可以省掉100ms左右）；
4、驱动加载完，执行android程序，执行到acc_open的时候，E901-902领先大概5.7秒
5、全程领先大概7秒，E901-902用时约24.8秒，EDE101用时约32秒；
6、E901-902 preloaded 2297 classes in 3355ms，但是EDE101 Zygote ( 81): ...preloaded 2297
classes in 5829ms，多需要2.47秒，原因不明；
7、“preloaded 379 resources in 4013ms” VS“preloaded
379 resources in 2742ms”；
8、“PackageManager( 143): Time to scan packages: 3.081 seconds” VS
“PackageManager( 144): Time to scan packages: 3.589 seconds”
笔者首先把驱动层能优化的地方尽量优化了，能缩短的尽量缩短，有些可以放到系统进入桌面后加载的驱动就可以放到进入桌面后再加载，比如camera，这样也能通过这种手段来加快启动速度。
但是为什么加载同样数据的classes会差两秒多呢?CPU跑的速度都是一样的。笔者做了一个实验，把EDE101大分辨率的屏当着小分辨率的屏来使用，修改为800X480，测试数据如下：
EDE101 2012-11-26版本软件+8G NAND+分辨率修改为800 X 480+LCD DCLK 33MHz
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
|
30.5（插了USB烧写线） |
30.5（插了USB烧写线） |
25.5 |
27.4 |
27.2 |
28.4 |
27.7 |
27.4 |
28 |
26.8 |
|
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
|
28.5 |
27.4 |
26.3 |
28.4 |
26.1 |
27 |
27.3 |
26.1 |
26.9 |
27 |
平均：27.19
大幅度降低。
这样一修改，启动速度提高不少啊。那跟分辨率有直接关系的是什么呢？很明显，那就是LCD啊，LCD的数据啊！开机过程中，不就是开机动画占的时间最多嘛！因此笔者做了一个实验，数据如下：
EDE101 2012-11-27版本软件+8G NAND+去掉开机动画，跑默认android动画+1280X800
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
|
25.5 |
26.6 |
28 |
27.5 |
28.1 |
26.2 |
27 |
26.9 |
26.5 |
27.5 |
平均： 27.1，大幅度下降，直接验证了开机动画影响很大，瓶颈也就在开机动画。
那么笔者就重新检查了一下开机动画的配置，图片是1280X800的，跟屏的分辨率是一样大小的，每一秒播放15帧，动画效果是挺不错的。因此笔者做了相应的一个实验，减少动画图片，降低帧数，每秒播放6帧，同时把图片分辨率修改为刚好能框住有效动画部分就好了，笔者裁剪到了220X220，这样图片小了很多，测试数据如下：
EDE101 2012-11-27版本软件+16G NAND+6p+1280X800
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
|
30.2 |
28.8 |
32.6 |
30.1 |
29.2 |
28.6 |
26.6 |
26.7 |
30.7 |
27.8 |
平均：29.1
从测试数据上看，速度是提高了不少，从优化开始前到现在提高了10秒多。把8G跟16G nand启动速度的差异修正后，那速度就可以达到26-27秒左右。
Android开机速度的优化是一个相当重要的课题，也是非常耗精力的事情。有时投入很多时间，也不一定能得到想要的结果。如果时间充分，还可以从预加载类来做优化，还有启动的service，把不需要的都可以屏蔽掉，这样肯定也能加快启动速度，不过这个需要很多时间精力的投入。笔者最后总结了几条加快启动速度的方法，单独用，一起上，都有作用。具体如下：
1、 关闭掉项目生产发布软件的打印；
2、 开机动画图片尽量小一些，播放的帧率低一点；
3、 能放到系统进入桌面后加载的驱动可以放到进入桌面后加载，可以从收到boot completed消息后执行，或者在运行launcher的程序中来触发；
4、 减少不需要的预加载类；
5、 去掉不需要的service；
6、 减少预装的apk数量；
7、 驱动里delay可以用sleep替换的就替换一下；
8、 在init.rc里面以及其他平台init.platXX.rc里面把不需要的service，都屏蔽掉不加载；
9、 在内核中没使用到的驱动、配置不要编译进内核；
10、 在kernel前面boot里面，公版的功能可能全一些，针对自己产品不需要的，可以屏蔽一些，也能加快一点启动速度。
Android开机速度的优化是始终还是有进步的空间，多努力一些，还是可以再加快一点。笔者的一点点经验、拙见仅供参考，平台的CPU跑得快这些问题就相对没那么突出，但是方法还是有用的，希望对android开发的朋友有一些帮助。