筆者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開發的朋友有一些幫助。
