安卓开机时间优化，就认这2招

背景：

在很多同学做性能优化相关工作时候，都会避免不了有个开机时间优化的任务，但是如何优化整个开机时间，开机涉及的各个阶段太多了，具体哪里是开机时间瓶颈呢？优化后如何测试自己的开机时机呢？

针对这些疑问本文将分享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进行分析：

原文地址：
https://mp.weixin.qq.com/s/TGBdACv6NAPRMymr9SLXvw