夜雨聆风背景：
在很多同学做性能优化相关工作时候，都会避免不了有个开机时间优化的任务，但是如何优化整个开机时间，开机涉及的各个阶段太多了，具体哪里是开机时间瓶颈呢？优化后如何测试自己的开机时机呢？
针对这些疑问本文将分享2个重要的方法
1、events日志抓取帮助大家去快速定位开机过程中各个部分的耗时，这部分简单方便可以定位出大概模块耗时瓶颈
2、Perfetto查看可以精细的定位具体哪个方法或者流程到底是怎么耗时长的
总结方法是如下2个：
开机流程log日志查看开机过程实战：
涉及开机流程核心log如下
'boot_progress_start',
'boot_progress_preload_start',
'boot_progress_preload_end',
'boot_progress_system_run',
'boot_progress_pms_start',
'boot_progress_pms_system_scan_start',
'boot_progress_pms_data_scan_start',
'boot_progress_pms_scan_end',
'boot_progress_pms_ready',
'boot_progress_ams_ready',
'boot_progress_enable_screen',
'sf_stop_bootanim',
'wm_boot_animation_done',
抓取方式：
需要使用adb logcat -b all或者-b events来抓取所有日志才可以
adb logcat -b all | grep -E "boot_p|sf_stop|wm_boot"
adb logcat -b events | grep -E "boot_p|sf_stop|wm_boot"
使用后结果如下：
adb logcat -b all | grep -E "boot_p|sf_stop|wm_boot"
03-29 05:23:06.836 903 903 I boot_progress_start: 11143
03-29 05:23:08.586 903 903 I boot_progress_preload_start: 12894
03-29 05:23:13.004 903 903 I boot_progress_preload_end: 17311
03-29 05:23:14.077 1700 1700 I boot_progress_system_run: 18384
03-29 05:23:15.547 1700 1700 I boot_progress_pms_start: 19854
03-29 05:23:16.374 1700 1700 I boot_progress_pms_system_scan_start: 20681
03-29 05:23:19.149 1700 1700 I boot_progress_pms_data_scan_start: 23456
03-29 05:23:19.198 1700 1700 I boot_progress_pms_scan_end: 23505
03-29 05:23:19.531 1700 1700 I boot_progress_pms_ready: 23838
03-09 15:55:58.370 1700 1700 I boot_progress_ams_ready: 27043
03-09 15:56:00.644 1700 1773 I boot_progress_enable_screen: 29318
03-09 15:56:08.079 998 1327 I sf_stop_bootanim: 36753
03-09 15:56:08.080 1700 1773 I wm_boot_animation_done: 36754
上面都是毫秒为单位，有了这个时间指标就可以拿来作为优化前后对比，或者各个机器之间的䶏。
它们分别代表各个阶段意义如下：
boot_progress_start
代表着Android屏幕点亮，开始显示启动动画，标志着kernel启动完成，本例中可以看出kernel启动耗时
boot_progress_preload_start
Zygote启动
boot_progress_preload_end
Zygote结束
boot_progress_system_run
SystemServer ready,开始启动Android系统服务，如PMS，APMS等
boot_progress_pms_start
PMS开始扫描安装的应用
boot_progress_pms_system_scan_start
PMS先行扫描/system目录下的安装包
boot_progress_pms_data_scan_start
PMS扫描/data目录下的安装包
boot_progress_pms_scan_end PMS扫描结束
boot_progress_pms_ready PMS就绪
boot_progress_ams_ready AMS就绪
boot_progress_enable_screen AMS启动完成后开始屏幕，从此以后屏幕才能响应用户的触摸，它在WindowManagerService发出退出开机动画的时间节点之前，而真正退出开机动画还会花费少许时间，具体依赖animation zip 包中的desc.txt。
sf_stop_bootanim SF设置service.bootanim.exit属性值为1，标志系统要结束开机动画了，可以用来跟踪开机动画结尾部分消耗的时间
wm_boot_animation_done 开机动画结束，这一步用户能直观感受到开机结束
以上log可能过多，这里进行一下相关分类
Kernel part : boot_progress_start
Zygote time : boot_progress_preload_end - boot_progress_preload_start
/system Scan time : boot_progress_pms_data_scan_start - boot_progress_pms_system_scan_start
/data Scan time : boot_progress_pms_scan_end- boot_progress_pms_data_scan_start
Home activity start time : boot_progress_enable_screen- boot_progress_ams_ready
event开机过程日志来源：
有时候想要了解上面日志具体是在哪个时候进统计打印的时间，需要查询相关的源码，那么一般如何查找boot_progress_*相关日志打印的代码呢？
这里有个技巧哈，因为是events日志打印出来的，所以可以直接代码中进行查找，但是查找如果自己grep这个日志的tag会有如下结果：
grep boot_progress_enable_screen ./ -rn
./base/services/core/java/com/android/server/am/EventLogTags.logtags:11:3050 boot_progress_enable_screen (time|2|3)
发现只是找到了EventLogTags，所以要进行一下转换，转换方式如下：
boot_progress_enable_screen去除下划线"_"而且首字母大写，变成如下： BootProgressEnableScreen 然后使用这个字符进行grep既可以。
grep BootProgressEnableScreen ./ -rn
./base/services/art-wear-profile:6289:PLcom/android/server/am/EventLogTags;->writeBootProgressEnableScreen(J)V
./base/services/core/java/com/android/server/wm/ActivityTaskManagerService.java:97:import static com.android.server.am.EventLogTags.writeBootProgressEnableScreen;
./base/services/core/java/com/android/server/wm/ActivityTaskManagerService.java:6337: writeBootProgressEnableScreen(SystemClock.uptimeMillis());
可以看看ActivityTaskManagerService.java:6337行
Perfetto抓取开机trace分析
经常在做性能优化时候，可能会有一个开机时间优化的题目，对于这个题目我们有一个比较明显的痛点： 想要抓取开机启动整个过程的trace，放到perfetto上进分析，但是发现开机过程中无法连接上设备，没办法抓到完整的trace，所以perfetto无法分析出整个开机过程。 那么有没有方法可以不需要依赖adb这种连接设备方式抓取，而是系统开机自己就会智能抓取相关的trace呢？ 针对上面的痛点，google在andorid 13上就已经有解决哈
下面来教大家解决这个痛点。
步骤1：
准备好一个config文件，主要用于配置perfetto抓取时候的相关配置，比如要抓哪些tag等，是否也抓取日志等，这个配置官网给了一个最简单的版本
# One buffer allocated within the central tracing binary for the entire trace,
# shared by the two data sources below.
buffers {
size_kb: 32768
fill_policy: DISCARD
}
# Ftrace data from the kernel, mainly the process scheduling events.
data_sources {
config {
name: "linux.ftrace"
target_buffer: 0
ftrace_config {
ftrace_events: "sched_switch"
ftrace_events: "sched_waking"
ftrace_events: "sched_wakeup_new"
ftrace_events: "task_newtask"
ftrace_events: "task_rename"
ftrace_events: "sched_process_exec"
ftrace_events: "sched_process_exit"
ftrace_events: "sched_process_fork"
ftrace_events: "sched_process_free"
ftrace_events: "sched_process_hang"
ftrace_events: "sched_process_wait"
}
}
}
# Resolve process commandlines and parent/child relationships, to better
# interpret the ftrace events, which are in terms of pids.
data_sources {
config {
name: "linux.process_stats"
target_buffer: 0
}
}
# 10s trace, but can be stopped prematurely via `adb shell pkill -u perfetto`.
duration_ms: 10000
把上面的文本内容拷贝保存成boottrace.pbtxt文件。 但是说明一下上面的官方给的基本上抓到的trace没办法分析，主要有以下几个问题： 1、抓到trace没有任何的tag，所以分析也就没有任何意义 2、抓取的时间比较短，内存也比较小 3、抓取trace没有android log，不方便和log结合分析
所以整改后的config如下：
buffers {
size_kb: 65536
fill_policy: DISCARD
}
buffers {
size_kb: 4096
fill_policy: DISCARD
}
data_sources {
config {
name: "linux.ftrace"
ftrace_config {
ftrace_events: "sched/sched_process_exit"
ftrace_events: "sched/sched_process_free"
ftrace_events: "task/task_newtask"
ftrace_events: "task/task_rename"
ftrace_events: "sched/sched_switch"
ftrace_events: "power/suspend_resume"
ftrace_events: "sched/sched_blocked_reason"
ftrace_events: "sched/sched_wakeup"
ftrace_events: "sched/sched_wakeup_new"
ftrace_events: "sched/sched_waking"
ftrace_events: "sched/sched_process_exit"
ftrace_events: "sched/sched_process_free"
ftrace_events: "task/task_newtask"
ftrace_events: "task/task_rename"
ftrace_events: "power/cpu_frequency"
ftrace_events: "power/cpu_idle"
ftrace_events: "power/suspend_resume"
ftrace_events: "ftrace/print"
atrace_categories: "adb"
atrace_categories: "aidl"
atrace_categories: "am"
atrace_categories: "audio"
atrace_categories: "binder_driver"
atrace_categories: "binder_lock"
atrace_categories: "bionic"
atrace_categories: "database"
atrace_categories: "gfx"
atrace_categories: "hal"
atrace_categories: "input"
atrace_categories: "pm"
atrace_categories: "power"
atrace_categories: "res"
atrace_categories: "ss"
atrace_categories: "view"
atrace_categories: "wm"
disable_generic_events: true
}
}
}
data_sources {
config {
name: "linux.process_stats"
process_stats_config {
}
}
}
data_sources {
config {
name: "linux.sys_stats"
sys_stats_config {
stat_period_ms: 500
stat_counters: STAT_CPU_TIMES
stat_counters: STAT_FORK_COUNT
cpufreq_period_ms: 500
}
}
}
duration_ms: 30000
同样用上面内容保存到boottrace.pbtxt文件。
步骤2
push boottrace.pbtxt文件到/data/misc/perfetto-configs/boottrace.pbtxt
adb push <yourfile> /data/misc/perfetto-configs/boottrace.pbtxt
步骤3
使能相关属性 Enable the perfetto_trace_on_boot service
adb shell setprop persist.debug.perfetto.boottrace 1
这个属性设置以后就可以在下一次开机会自动抓取到perfetto相关trace文件
步骤4
重启设备，获取perfetto的trace文件 执行 adb reboot命令 等待20s，然后等系统桌面显示完整后
adb pull /data/misc/perfetto-traces/boottrace.perfetto-trace
打开https://ui.perfetto.dev网站导入boottrace.perfetto-trace进行分析：
学习fw课程和性能相关知识有啥疑问，请记得联系马哥本人或者在马哥vip群中进行讨论
更多vip干货独享知识，及面试定制指导上岸fw工程师服务，课程优惠购买成为vip学员进入vip群，积极讨论各种行业难点痛点疑难问题，答疑服务等。
请联系马哥微信：
