如果需要优化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情况概况如下：

查看某一个细节的启动时间，如hisi_thermal_driver_init：

工具代码分析

analyze_boot.py：https://github.com/arnoldlu/suspendresume/blob/master/analyze_boot.py

基于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

Using bootchart on Android：http://elinux.org/Using_Bootchart_on_Android

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 user@1000.service
          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分析优化相关推荐

Android/Linux Thermal框架分析及其Governor对比
https://www.cnblogs.com/arnoldlu/p/6388151.html 图表 1 Thermal框架随着SoC性能的快速提升,功耗也极大提高,带来的负面影响是SoC的温度提高 ...
Android 应用性能优化（4）---Android App性能评测分析-启动时间篇
Android App性能评测分析-启动时间篇 1.前言随着项目版本的迭代,App的性能问题会逐渐暴露出来,而好的用户体验与性能表现紧密相关,性能问题从应用的启动优化开始,下面会根据实际app性能测 ...
android布局时长分析,Android性能优化：布局优化详细解析（含、、讲解）
前言在 Android开发中,性能优化策略十分重要本文主要讲解性能优化中的布局优化,希望你们会喜欢. 目录 1. 影响的性能布局性能的好坏主要影响 :Android应用中的页面显示速度 2. ...
“linux性能”工具集助力分析优化Linux
序这段时间的工作全都扔在了Linux性能分析优化上. 看"一点"的优化,测试程序能轻松完成数据统计,并且自定义程度高:但"全局"的优化,或是在"侦查 ...
Magisk root 原理分析之二：Android Verified Boot (AVB)
1. Android Verified Boot (AVB) 或称 Verified Boot 2.0 简介官方解释:验证用户设备上运行的软件完整性.它通常从设备固件的只读部分开始,该部分加载代码并 ...
Android Linux内核编译调试
对于在Windows上写代码写习惯的人,调试是必不可少的手段,但是转到Android以后,发现调试手段异常简陋,跟Windows简直不是一个级别,特别是Android的内核调试,网上资料也相对较少,不 ...
linux启动时间极限优化,Linux启动时间的极限优化
在上次完成嵌入式应用的Linux裁减后,Linux的启动时间仍需要7s左右,虽然勉强可以接受,但仍然没有达到我个人所追求的目标--2s以内.况且,在实际的商用环境中,设备可靠性的要求可是"5 ...
Android O 7.0 启动优化的一些思路
启动优化其实是一个比较大的命题,在一些特地的场景下,快速启动有比较强烈的需求,这篇博客主要简单的介绍一些在android O平台上的进行启动优化的思路与想法. 而优化启动的一个很重要的东西就是如何来准 ...
Android 进阶第二篇——性能优化
Android 进阶第二篇--性能优化一些Android书籍喜欢把性能优化放在最后的章节,简单提一提作为内容全面的点缀.在这里我将工具使用和性能优化的一些个人经验放在进阶系列博客的开始,因为我认为防 ...

Android/Linux boot time分析优化