2. 程式人生 > >Android/Linux boot time分析優化

Android/Linux boot time分析優化

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

如果需要優化boot time，就需要一個量化的工具來分析每個階段的時間消耗。這種型別的優化特別適合使用基於timeline的圖表，有著明顯的時間順序。要求不但能給出整個流程消耗的時間，還要能對流程進行細化，獲得每個階段的時間。先從總體上檢視優化程度，然後逐個檢視異常的階段。

分析工具化之後，可以快速的迭代，獲得測試結果的平均值和均方差，已驗證修改的有效性和穩定性。

基於analyze_boot.py分析Android/Linux的kernel boot時間

1.修改HiKey的BoardConfig.mk檔案，使能initcall_debug，增加dmesg buffer大小。

diff --git a/hikey/BoardConfig.mk b/hikey/BoardConfig.mk
index 6d17130..64e8789 100644
--- a/hikey/BoardConfig.mk
+++ b/hikey/BoardConfig.mk
@@ -4,7 +4,7 @@ TARGET_BOARD_PLATFORM := hikey
ifeq ($(TARGET_KERNEL_USE_4_1), true)
BOARD_KERNEL_CMDLINE := console=ttyAMA3,115200 androidboot.console=ttyAMA3 androidboot.hardware=hikey firmware_class.path=/system/etc/firmware efi=noru
else
-BOARD_KERNEL_CMDLINE := console=ttyFIQ0 androidboot.console=ttyFIQ0 androidboot.hardware=hikey firmware_class.path=/system/etc/firmware efi=noruntime
+BOARD_KERNEL_CMDLINE := console=ttyFIQ0 androidboot.console=ttyFIQ0 androidboot.hardware=hikey firmware_class.path=/system/etc/firmware efi=noruntime initcall_debug log_buf_len=16M

endif
 
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 1610612736

2.adb shell dmesg儲存核心log到dmesg.txt中。

adb shell dmesg > dmesg.txt

3.使用analyze_boot.py分析dmesg.txt，生成從kernel啟動到啟動使用者空間init之間timeline圖表。

./analyze_boot.py -dmesg dmesg.txt
          Host: lenovo-Product
     Test time: 2017-01-09_19:16:25
     Boot time: 1970-01-01_08:00:03
Kernel Version: 4.4.0-31-generic
  Kernel start: 0.000
    init start: 5977.254

4.結果分析。

整個boot情況概況如下：

image

檢視某一個細節的啟動時間，如hisi_thermal_driver_init：

image

工具程式碼分析

基於bootchart分析Android boot time

bootchart是一個用於分析系統啟動過程的視覺化工具，包括資料收集和視覺化兩部分。

在Android中，資料收集功能整合到初始化命令init中了。bootchart的官方資訊在：http://www.bootchart.org/

bootchart大致流程是在待測裝置（Android等）收集資料（bootchart.tgz），然後使用bootchart工具分析，並生成SVG等視覺化圖表，可以使用Inkscape或者Web Browse開啟SVG進行分析。

1.安裝分析工具

sudo apt-get install bootchart

2.準備Android bootchart功能

3.觸發bootchart功能

4.收集測試資料

5.生成視覺化圖表

pybootchartgui

Ubuntu bootchart分析

Ubuntu從15.04切換到了systemd作為init啟動。

systemd-analyze作為systemd的相關命令，用於分析系統啟動效能。systemd-analyze還包含一些列子命令。

systemd-analyze time和systemd-analyze一樣用於顯示使用者空間啟動前核心啟動時間和使用者空間啟動時間。

Startup finished in 4.331s (kernel) + 42.551s (userspace) = 46.883s

systemd-analyze blame顯示以時間從長到短的啟動服務列表。

          8.977s NetworkManager-wait-online.service
          8.315s click-system-hooks.service
          7.867s apparmor.service
          7.848s expressvpn.service
          7.737s dev-sda2.device
          7.053s networking.service
          5.517s ModemManager.service
          5.415s grub-common.service
          5.025s irqbalance.service
          4.975s apport.service
          4.834s speech-dispatcher.service
          4.833s ondemand.service
          3.469s lightdm.service
          3.394s NetworkManager.service
          3.143s systemd-udevd.service
          2.624s accounts-daemon.service
          2.412s thermald.service
          2.401s systemd-logind.service
          2.365s rsyslog.service
          1.465s plymouth-start.service
          1.374s media-sda1.mount
          1.344s gpu-manager.service
          1.232s upower.service
          1.129s keyboard-setup.service
          1.125s systemd-tmpfiles-setup-dev.service
          1.118s [email protected]
          1.056s ssh.service
           970ms console-setup.service
           918ms dev-loop0.device
           898ms polkitd.service
           893ms glances.service
           882ms lm-sensors.service

...

systemd-analyze critical-chain顯示最耗時服務單元。

The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @42.534s
└─multi-user.target @42.534s
  └─expressvpn.service @34.685s +7.848s
    └─network-online.target @34.674s
      └─NetworkManager-wait-online.service @25.696s +8.977s
        └─NetworkManager.service @22.287s +3.394s
          └─dbus.service @19.994s
            └─basic.target @19.980s
              └─sockets.target @19.980s
                └─snapd.socket @19.928s +47ms
                  └─sysinit.target @19.912s
                    └─apparmor.service @12.017s +7.867s
                      └─local-fs.target @12.007s
                        └─run-user-1000-gvfs.mount @36.764s
                          └─run-user-1000.mount @29.632s
                            └─local-fs-pre.target @7.292s
                              └─systemd-remount-fs.service @7.136s +119ms
                                └─systemd-journald.socket @2.458s
                                  └─-.slice @2.448s

systemd-analyze plot > systemd.svg

systemd-analyze dot

systemd-analyze dump

systemd-analyze set-log-level

systemd-analyze set-log-target

systemd-analyze verify

/etc/systemd/bootchart.conf

/etc/default/grub

systemd-analyze

相關推薦

Android/Linux boot time分析優化

如果需要優化boot time，就需要一個量化的工具來分析每個階段的時間消耗。這種型別的優化特別適合使用基於timeline的圖表，有著明顯的時間順序。要求不但能給出整個流程消耗的時間，還要能對流程進行細化，獲得每個階段的時間。先從總體上檢視優化程度，然後逐個檢視異常的階段。 分析工具化之後，可以快速的迭代，

Android studio + MAT記憶體分析優化 一

        關於記憶體分析和優化，是我們app從開始到結束上線一直都要關注的問題。但是我發現我接觸過得專案和公司，都是在APP成型之後，或者快上線了，才會去關注app記憶體使用情況。派專人去分析每個頁面，每個動作是否會觸發記憶體洩漏，ui卡頓等問題。個人認為這是個非常不好

嵌入式Linux開發——(十一)u-boot原始碼分析

1、U-Boot的特性：     ①開放原始碼     ②支援多種嵌入式作業系統核心：Linux、NetBSD、VxWorks、QNx、RTEMS、ARTOS、 LynxOS     ③支援多種架構的CPU：Power

使用Android Profile做效能分析及優化

前言 做Android開發五年，開發工具從最初的eclipse+ADT外掛到AndroidStduio。Google更是在新版的AndroidStudio中集成了Android應用效能分析利器——Profile。 本文基於AndroidStudio 3.2.1 正式版進行分析並定位問題原因。附上下載地址：

Android/Linux Thermal Governor之IPA分析與使用

IPA（Intelligent Power Allocator）模型的核心是利用PID控制器，Thermal Zone的溫度作為輸入，可分配功耗值作為輸出，調節Allocator的頻率和電壓值。 由Power Management一般開發模型可知，包括模型建立，模型實現，驗證。 1 IPA模型 PID控制器在

android system.img,ramdisk.img,boot.img 分析

android 原始碼編譯後得到system.img,ramdisk.img,userdata.img映像檔案。其中， ramdisk.img是emulator的 檔案系統，system.img包括了主要的包、庫等檔案，userdata.img包括了一些使用者資料，emu

效能優化-Android之ANR問題分析解決 traces.txt檔案分析 CPU佔用過高

（由於公司專案特殊情況，需要使用一些小廠的三防功能手機，不能使用我們平時用的這些民用手機） 前期測試的時候是用民用手機測試的，有六七種機型（小米，華為，中興，oppo）,使用過程中均沒有出現ANR的情況，但是在公司採購的一款工程機上面用了一段時間後肯定就會出現ANR，出現了

Android App冷啟動分析與優化

app的啟動方式：  1.）冷啟動 當啟動應用時，後臺沒有該應用的程序，這時系統會重新建立一個新的程序分配給該應用，這個啟動方式就是冷啟動。冷啟動因為系統會重新建立一個新的程序分配給它，所以會先建立和初始化Application類，再建立和初始化MainActivit

Android應用記憶體洩露分析以及優化方案

文章轉載http://blog.csdn.net/Soiol/article/details/52486871        本篇部落格是介紹Android記憶體優化方面的知識，在讀本篇部落格之前需要你熟練掌握Java 基礎知識（例如，靜態變數的生命週期，匿名內部類的使用，匿名物件等），並且具有一定的Andr

How To Improving Android Boot Time

diff --git a/build/target/product/core.mk b/build/target/product/core.mk index 3b5a42c..4d9ed7e 100755 --- a/build/target/product/core.mk +++ b/build/targ

[日更-2019.5.10、11、12] Android 系統的安全性分析(三)--Linux層面上的安全措施

宣告 最近工作上涉及到對Android系統安全性的改造，在改造之前先分析整理下目前Android系統自身的安全性； 參考了一些文

Vertica DBD 分析優化設計

and tomat ron per vertica small resource resources start DBD = Database Designer，是Vertica數據庫優化中最主要的原生工具。 首先運行admintools工具,按下面步驟依次執行： 1.選擇

iostat命令具體解釋——linux性能分析

毫秒 名稱 inux linux性能 多個 nice 是我 技術 art 之前總結uptime和free命令，今天繼續來總結一下iostat。給自己留個筆記。同一時候也希望對大家實用。 版本號信息： sysstat version

linux 性能分析

linux count 平均值 信息 查看性能順序：[cpu] mpstat -P ALL 1 100 (sar -u,sar -p)[network] sar -n DEV[disk] sar -b,sar -d[mem] sar -W,sar -r,sar -BtopLinux CPU實

Linux內核分析 - 網絡[十四]：IP選項

ria copyto 還要 next 操作 目的 start 套接口 詳細講解 Linux內核分析 - 網絡[十四]：IP選項 標簽： linux內核網絡structsocketdst 2012-04-25 17:14 5639人閱讀 評論(1) 收藏 舉報

linux系統故障分析與排查

使用 權限 建立 shel 自動識別 了解 緊急 rhel5 1.4 在處理Linux系統出現的各種故障時，故障的癥狀是最先發現的，而導致這以故障的原因才是最終排除故障的關鍵。熟悉Linux系統的日誌管理，了解常見故障的分析與解決辦法，將有助於管理員快速定位故障點。“對癥下

Linux+Apache+Mysql+PHP優化技巧

建議 發生 /dev/ 意義 mac 恢復文件 客戶 效果 slave LAMP 平臺由四個組件組成，呈分層結構。每一層都提供了整個軟件棧的一個關鍵部分：Linux、Apache、MySQL、PHP。 LAMP這個詞的由來最早始於德國雜誌“c‘t Maga

X86架構下Linux啟動過程分析

重要 ack csdn 檢查 point article span 註意 eap 1、X86架構下的從開機到Start_kernel啟動的整體過程 這個過程簡要概述為： 開機——>BIOS——>GRUB/LILO——>Linux Kernel

Linux——信息分析（四）域名分析dig、host、

p地址 blog alt src org amt png 負責 一級域名 1、域名的命名格式為：WWW．<用戶名>．<二級域名>．<一級域名> dig www.baidu.com 解析過程說明

android init進程分析 init腳本解析和處理

還要 ret process ram ces ken option restart launch (懶人近期想起我還有csdn好久沒打理了。這個android init躺在我的草稿箱中快5年了。略微改改發出來吧) RC文件格式 rc文件是linu