題目有點大，其實kernel的啟動效能調整和android基本沒什麼關係，我想應該適用所有使用linux的嵌入式裝置
時間測量
說到效能調整，第一件該幹的的事就是看下時間到底消耗在**。俗話說的好：知己知彼，百戰百勝；過度優化，萬惡之首
因此手頭上要有稱心如意的時間測試工具，方法。其實我是不太喜歡工具的，工具這東西可遇不可求，而且不如寫**順手。
1. printk_time
在核心編譯選項中開啟config_printk_time，重新編譯核心後，系統啟動後就可以看到每一條printk前都有乙個時間戳了，這樣就有個大概的輪廓，哪
個驅動消耗了更多的時間，當然這個資訊對我們效能調整來說粒度太粗了
2. initcall_debug巨集
上面的printk_time只是在printk附加上當時的系統時間，對於那些沒有printk資訊輸出的驅動來說是無法提供啟動時間資訊的，initcall_debug派上了用場，開啟這個巨集後，每個驅動的初始化起始時間和結束時間都列印出來了。有了這個時間，基本就可以確定哪些部分需要優化了。我的做法是只關注耗時10000us以上的驅動。
3. ktime_t
呼叫ktime_get 獲取時間，我最喜歡的時間測量方法，對於可疑的耗時函式，可如下測試
ktime_t start, end;
start = ktime_get()
candidate_func(arg...)
end = ktime_get()
printk(kern_alert "%s: start time=%d.%d, end time=%d.%d\n", __func__, start.tv.sec, start.tv.nsec, end.tv.sec, end.tv.nsec);
可以很準確的計算candidate_func的時間，當然如果candidate_func中引發了排程，時間就沒那麼準確了。
4 printk
盡量去掉printk對時間測量的影響，可以調整kernel/printk.c中的default_console_loglevel巨集，把級別較低的資訊去掉
效能優化方法
1. hard code lpj，在uboot啟動引數增加 lpj=3997696. 其中的3997696替換為你的機器啟動資訊獲取的值，這個一般能節省200ms
2. 裁剪核心，這塊比較大，要單獨開一篇來介紹，裁剪的好處有兩點：第一減少kernel的尺寸，這也就相應的減少了載入kernel image的時間，第二也減少了不必要的初始化
3.**調整：
根據時間測試，找到耗時瓶頸，看看是否能進行優化。
4. 優化裝置io驅動，提高資料的讀寫速度，kernel啟動完成到android launcher完成，幾乎無處不涉及到檔案的讀寫，io速度對啟動時間的影響重大，**是人寫的，所以平台特定的io**絕對有優化的空間
效能優化結果
最終優化後的結果是kernel從啟動到init.rc大概需要0.5秒左右，當然具體優化到什麼程度，和kernel需要載入的驅動是密切相關的。
Android 效能優化 啟動優化
1.3啟動優化工具 1.3.1 traceview 1.3.2 systrace 2.啟動優化 啟動優化的第一步就是要獲取啟動的時間，整個啟動邏輯的所需要的精確時長。根據各個方法的時長去定位哪些邏輯需要優化。首先我們如何獲取 的執行時間。如下 檢視啟動時間。適合線下模式 注意 使用命令前，adb需要...
android效能優化之啟動優化
解決方案 null null true drawable bg splash必要且耗時 mutidex 必要不耗時 首頁繪製 非必要耗時 資料上報，外掛程式初始化 非必要不耗時 直接去掉，需要時再載入。其他第三方元件的初始化 檢視日誌 將手機連線到android studio上，開啟logcat，不...
Android效能優化1 啟動優化
1 手機的啟動 開啟電源 通過bootloader將linux系統拉起 配置網路 檔案等等引導頁面 linux啟動 init程序 zygote程序建立jvm 開啟systemserver，開啟binder執行緒池和systemservicemanager 由這些服務開啟activitymanager...