2. 程式人生 > >Android O 啟動優化的一些思路

Android O 啟動優化的一些思路

阿新 • • 發佈：2019-01-26

啟動優化其實是一個比較大的命題，在一些特地的場景下，快速啟動有比較強烈的需求，這篇部落格主要簡單的介紹一些在android O平臺上的進行啟動優化的思路與想法。

而優化啟動的一個很重要的東西就是如何來準確度量啟動時間，也就是說是否有比較好的辦法來度量整個系統的啟動耗時。畢竟只有能夠畢竟準確的度量了相應的時間，才能更好的瞭解分析每個啟動階段的情況。所以我打算按照如下的方式來組織：

  • Android 相關計時工具的介紹
  • 一些重點程式碼端的分析
  • 優化思路

Android 相關計時工具的介紹

1) bootchart工具 
在Android O當中，bootchart已經預設整合在Init當中。所以收集資料可以用以下步驟：

  • 只需要你通過開關開啟即可生效：“adb shell ‘touch /data/bootchart/enabled’”
  • 重啟裝置
  • $ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh抓取資料生成一張png圖片，即可進行分析。
  1. ant編譯

  2. java -jar bootchart.jar ../bootchart/bootchart.tgz 生成分析結果圖片：

    這裡寫圖片描述

從這張啟動圖片裡，我們能夠看到： 
1. 總共的啟動時間是30s,這裡指的是從kernel開始啟動的時間開始計時，一直到Android 啟動結束. 
2. Init 程序一直到13s左右才是啟動其他程序，如ueventd。 
3. Zygote64/Zygote程序大約在22s左右啟動。 
4. 這樣計算下來Android fw的啟動時間大致為8s左右。

這樣看起來就比較清晰了，Init程序13秒才開始工作的原因是什麼？這個時間如果能縮短的話啟動時間會效果很顯著。 
通過dmesg資訊，可以看到： 
[32m[ 13.227842] [0m[33minit[0m: init second stage started! 
[32m[ 13.237508] [0m[33mselinux[0m: SELinux: Loaded file_contexts\x0a 
[32m[ 13.243342] [0m[33mselinux[0m: SELinux: Loaded property_contexts from /plat_property_contexts & /nonplat_property_contexts.\x0a 
[32m[ 13.254522] [0m[33minit[0m: Running restorecon… 
[32m[ 13.593214] [0m[33mselinux[0m[31m: SELinux: Could not stat /dev/block: No such file or directory.\x0a[0m 
[32m[ 13.601607] [0m[33minit[0m[31m: waitpid failed: No child processes[0m 
[32m[ 13.606477] [0m[33minit[0m: Couldn’t load properties from /system/etc/prop.default: No such file or directory 
[32m[ 13.615416] [0m[33minit[0m: Couldn’t load properties from /prop.default: No such file or directory 
[32m[ 13.623768] [0m[33minit[0m: Couldn’t load properties from /odm/default.prop: No such file or directory 
[32m[ 13.631946] [0m[33minit[0m: Couldn’t load properties from /vendor/default.prop: No such file or directory 
[32m[ 13.641126] [0m[33minit[0m: Created socket ‘/dev/socket/property_service’, mode 666, user 0, group 0 
[32m[ 13.648925] [0m[33minit[0m: Parsing file /init.rc… 
[32m[ 13.653220] [0m[33minit[0m: Added ‘/init.environ.rc’ to import list 
[32m[ 13.658291] [0m[33minit[0m: Added ‘/init.usb.rc’ to import list 
[32m[ 13.663329] [0m[33minit[0m: Added ‘/init.angler.rc’ to import list 
[32m[ 13.668660] [0m[33minit[0m: Added ‘/vendor/etc/init/hw/init.angler.rc’ to import list 
[32m[ 13.675611] [0m[33minit[0m: Added ‘/init.usb.configfs.rc’ to import list 
[32m[ 13.681379] [0m[33minit[0m: Added ‘/init.zygote64_32.rc’ to import list 
[32m[ 13.688215] [0m[33minit[0m: Parsing file /init.environ.rc… 
[32m[ 13.692099] [0m[33minit[0m: Parsing file /init.usb.rc… 
[32m[ 13.696775] [0m[33minit[0m: Parsing file /init.angler.rc… 
[32m[ 13.701323] [0m[33minit[0m: Added ‘init.angler.usb.rc’ to import list 
[32m[ 13.706678] [0m[33minit[0m: Added ‘init.angler.diag.rc’ to import list 
[32m[ 13.712305] [0m[33minit[0m: Added ‘init.angler.sensorhub.rc’ to import list 
[32m[ 13.719668] [0m[33minit[0m: Parsing file init.angler.usb.rc… 
[32m[ 13.724264] [0m[33minit[0m: Parsing file init.angler.diag.rc…

確實是13s左右init程序才開始工作。所以第一步我們來想辦法把這個時間看看能不能縮短。

通過這個工具，我們能夠大致清楚了從系統啟動到Android啟動完成後的主要時間，同時也能夠簡單的分析出kernel啟動時間，zygote啟動時間，sysetmserver啟動時間，但是這個工具還是不能把Android 啟動階段畢竟清晰的展現出來，這個時候就需要使用到第二個工具了。

2) boot mesg

我們很高興的可以看到在Android中已經加入了一系列的mesg，我們可以通過這一系列的mesg可以抓出android fw啟動的相關時間。

這裡寫圖片描述

到此為止，我們大致能夠得出android 啟動的每個階段所耗費的時間了，後續我們來仔細分析每個階段的程式碼，看看都幹了啥。

第一步，關閉kernel log輸出:

  65 int console_printk[4] = {
  66         0,//DEFAULT_CONSOLE_LOGLEVEL,   /* console_loglevel */
  67         0,//DEFAULT_MESSAGE_LOGLEVEL,   /* default_message_loglevel */
  68         0,//MINIMUM_CONSOLE_LOGLEVEL,   /* minimum_console_loglevel */
  69         0,//DEFAULT_CONSOLE_LOGLEVEL,   /* default_console_loglevel */
  70 };
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

簡單粗暴，全部關閉掉，重新編譯boot.img測試下，快了將近10s.。。。 
這裡寫圖片描述

通過檢視dmesg:

[32m[    5.276684][0m[33minit[0m: Parsing file /init.rc...
[32m[    5.276945][0m[33minit[0m: Added '/init.environ.rc' to import list
[32m[    5.276959][0m[33minit[0m: Added '/init.usb.rc' to import list
[32m[    5.276978][0m[33minit[0m: Added '/init.angler.rc' to import list
[32m[    5.276997][0m[33minit[0m: Added '/vendor/etc/init/hw/init.angler.rc' to import list
[32m[    5.277010][0m[33minit[0m: Added '/init.usb.configfs.rc' to import list
[32m[    5.277026][0m[33minit[0m: Added '/init.zygote64_32.rc' to import list
[32m[    5.278233][0m[33minit[0m: Parsing file /init.environ.rc...
[32m[    5.278331][0m[33minit[0m: Parsing file /init.usb.rc...
[32m[    5.278675][0m[33minit[0m: Parsing file /init.angler.rc...
[32m[    5.278851][0m[33minit[0m: Added 'init.angler.usb.rc' to import list
[32m[    5.278865][0m[33minit[0m: Added 'init.angler.diag.rc' to import list
[32m[    5.278878][0m[33minit[0m: Added 'init.angler.sensorhub.rc' to import list
[32m[    5.280094][0m[33minit[0m: Parsing file init.angler.usb.rc...
[32m[    5.280726][0m[33minit[0m: Parsing file init.angler.diag.rc...
[32m[    5.280817][0m[33minit[0m: Parsing file init.angler.sensorhub.rc...
[32m[    5.280908][0m[33minit[0m: Parsing file /vendor/etc/init/hw/init.angler.rc...
[32m[    5.280934][0m[33minit[0m[31m: could not import file '/vendor/etc/init/hw/init.angler.rc' from '/init.rc': No such file or directory[0m
[32m[    5.280951][0m[33minit[0m: Parsing file /init.usb.configfs.rc...
[32m[    5.281447][0m[33minit[0m: Parsing file /init.zygote64_32.rc...
[32m[    5.281581][0m[33minit[0m: Parsing file /system/etc/init...
[32m[    5.281607][0m[33minit[0m: Parsing file /vendor/etc/init...
[32m[    5.281632][0m[33minit[0m: Parsing file /odm/etc/init...
[32m[    5.281702][0m[33minit[0m: processing action (early-init)
[32m[    5.282227][0m[33minit[0m: starting service 'ueventd'...
[32m[    5.282722][0m[33minit[0m[31m: failed to open /acct/uid_0/pid_330/cgroup.procs: No such file or directory[0m
[32m[    5.282756][0m[33minit[0m[31m: createProcessGroup(0, 330) failed for service 'ueventd': No such file or directory[0m
[32m[    5.282980][0m[33minit[0m: processing action (wait_for_coldboot_done)
[32m[    5.283890][0m[31mmsm_rng:Data not available![0m
[32m[    5.284876][0m[33mueventd[0m: ueventd started!
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30

發現Init程序確實提前到kernel啟動5s左右。。

相關推薦

Android O 啟動優化的一些思路

啟動優化其實是一個比較大的命題，在一些特地的場景下，快速啟動有比較強烈的需求，這篇部落格主要簡單的介紹一些在android O平臺上的進行啟動優化的思路與想法。 而優化啟動的一個很重要的東西就是如何來準確度量啟動時間，也就是說是否有比較好的辦法來度量整個系統的啟動耗時。

Android O 啟動優化--

Android O 啟動優化的一些思路 啟動優化其實是一個比較大的命題，在一些特地的場景下，快速啟動有比較強烈的需求，這篇部落格主要簡單的介紹一些在android O平臺上的進行啟動優化的思路與想法。 而優化啟動的一個很重要的東

Android應用啟動優化:一種DelayLoad的實現和原理(下篇)（轉載）

我們使用第三種方法來實現延遲載入。不過上一篇寫的比較簡單，只是講解了如何去實現，這一篇就來講一下為何要這麼做，以及這麼做後面的原理。 其中會涉及到一些 Android 中的比較重要的類，以及 Activity 生命週期中比較重要的幾個函式。 其實這個其中的原理比較簡單，不過要弄清楚其實現的過程，還是一件蠻好

Android應用啟動優化:一種DelayLoad的實現和原理(上篇)

轉自： http://www.androidperformance.com/2015/11/18/Android-app-lunch-optimize-delay-load.html 0. 應用啟動優化概述 在 Android 開發中,應用啟動速度是一個非常重要的點,

Android O 安卓啟動時間優化分析

文件轉載自AOSP官網 本文件提供了有關改進特定 Android 裝置的啟動時間的合作伙伴指南。啟動時間是系統性能的重要組成部分，因為使用者必須等待啟動完成後才能使用裝置。對於較常進行冷啟動的汽車等裝置而言，較短的啟動時間至關重要（沒有人喜歡在等待幾十秒後才能輸

android 性能優化 -- 啟動過程 冷啟動 熱啟動

sdc 視覺 準備 and 接下來 元素 uri word androidm 一、應用的啟動方式 　　通常來說，啟動方式分為兩種：冷啟動和熱啟動。 　　1、冷啟動：當啟動應用時，後臺沒有該應用的進程，這時系統會重新創建一個新的進程分配給該應用，這個啟動方式就是冷啟動。 　　

Android應用優化之冷啟動優化

前言 事件發生在發包上線的前兩天，在某某雲進行移動測試時，提示冷啟動速度低於平均值的問題，之前自己也曾嘗試過優化，但是發現效果並不是很明顯，作為一個有追求的開發者，趁著有點空閒時間，要好好研究一下冷啟動優化問題。 App的啟動流程 我們可以瞭解一下官方文件《App startup time》對App啟動

支付寶 App 構建優化解析：通過安裝包重排布優化 Android 端啟動效能

1. 前言 本章節我們將圍繞《支付寶 App 構建優化解析》另啟新系列，細分拆解客戶端在“程式碼管理”、“證書管理”、“版本管理”、“構建打包”等維度的具體實現方案展開討論，帶領大家進一步瞭解支付寶在 App 構建模組下的持續優化。 本節將主要記錄通過對支付寶 Android Apk 檔案的重新佈局，來改

Android(O) 8.0 怎樣在後臺啟動service

在Android8.0之後, google對後臺啟動service進行了更加嚴格的限制, 具體可以參考官網文件, 上不了外網的朋友看這個網址:android中文官網, 這裡摘出和後臺service相關的內容: 後臺服務限制 在後臺中執行的服務會消耗裝置資源，這可能降低使用者體驗。 為

通過安裝包重排布優化 Android 端啟動效能

1. 前言 本章節我們將圍繞《支付寶 App 構建優化解析》另啟新系列，細分拆解客戶端在“程式碼管理”、“證書管理”、“版本管理”、“構建打包”等維度的具體實現方案展開討論，帶領大家進一步瞭解支付寶在 App 構建模組下的持續優化。 本節將主要記錄通過對支付寶 Android Apk 檔案的

Android 啟動白屏，跳轉黑屏以及冷啟動優化

一，白屏 現象：啟動app,白屏一段時間後才出現歡迎頁 解決： 1，新增style <style name="AppTheme.Launcher"> <item name="android:windowDisablePreview">true<

淺談Android啟動優化

一、前言 隨著我們的應用版本迭代，需要整合和增加的資源越來越多，尤其是在Application中，應用的效能也將出現很多需要優化的點。因此下面我們將從一個apk的啟動原理去分析和解決啟動時常常遇到的白屏、卡頓或者時間過長而帶來的體驗問題。 二、應用啟動方式 1、

Android UI優化— App啟動優化

黑白屏產生的原因和解決辦法 黑白屏產生的原因 1、還沒載入到佈局檔案，就已經顯示了window視窗背景 2、黑屏白屏就是window視窗背景 容易產生黑白屏的地方 1、Activity的onCreate()中 @Override pro

Android效能優化筆記（一）——啟動優化

參考文章：  https://time.geekbang.org/column/article/73651 https://mp.weixin.qq.com/s/eaArt5Udc4WZ3NoH5RlEkQ https://juejin.im/post/5874bff0128fe1006b4

Android app啟動白屏優化

可以看到啟動的時候會有一個白屏, 如果手機較慢的話, 這個白屏就會持續一段時間, 不太友好. 那麼還有沒有什麼辦法優化呢? 給我們的應用視窗弄一個PlaceHolder Android最新的Material Design有這麼個建議的. 建議我們使用一

android專案效能優化之啟動時間

一般來說，判定一個android專案效能優劣，我們有以下幾個指標： 啟動時間 apk大小 UI渲染 穩定性 記憶體佔用 電量消耗 接下來，讓我們就這幾個指標展開來詳述各自究竟應該怎樣去優化。 啟動時間 一般來說，應用啟動時間分為三種 首次啟動

android Bitmap 常用的一些方法及其優化程式碼段

常用轉化成bitmap的方法 Bitmap decodeFile(...) Bitmap decodeResource(...) Bitmap decodeByteArray(...) Bitmap decodeStream(...) Bitmap dec

愛奇藝Android客戶端啟動優化與分析

1 簡介 網際網路領域裡有個八秒定律，如果網頁開啟時間超過8秒，便會有超過70%的使用者放棄等待，對Android APP而言，要求更加嚴格，如果系統無響應時間超過5秒，便會出現ANR，APP可能會被強制關閉，因此，啟動時間作為一個重要的效能指標，關係著使用者的第一體驗。 愛奇藝安卓APP非

Android 啟動優化之啟動頁白屏的真正原理

網上有許多解釋 大牛A說：應用啟動的時候有一個空白的Window，View繪製到另一個Window上，在繪製完畢之後，後一個Window去替換掉前一個Window。 B說：setContentView耗時太久，所以白屏 大牛A之所以會這樣認為，是因為他看過原始碼或者

Android 應用啟動時優化白屏問題

一般情況下 我們在啟動APP的時候，螢幕會出現一段時間的白屏或者黑屏，不同的裝置可能白屏黑屏顯示的時間長短不同，裝置硬體較差的時間都會比較長，這顯然影響使用者體驗。現在我們來分析這個問題產生的原因。 當我們在啟動一個應用時，系統會去檢查是否已經這樣存在一個程序