app_process 初始化阶段trace

背景

android 中为了提升程序启动速度,将许多的初始化动作前移到了 app_process中。
这为调试一些系统行为(尤其启动时行为)造成了比较大的障碍。
因此希望获得一种能够debug或者至少trace 启动阶段行为的方案。

尝试调试

先行尝试调试。执行app_process -v 可以在logcat中看到各种可用的命令。
再参考https://blog.csdn.net/tanzui/article/details/87901884,添加如下的命令可以使得程序能够被调试。
export 变量参考/system/bin/am脚本。

1
2
export CLASSPATH=/system/framework/am.jar
app_process -XjdwpProvider:adbconnection -XjdwpOptions:suspend=n,server=y -Xcompiler-option --debuggable /system/bin com.android.commands.am.Am instrument

但是当我们将suspend=n改为suspend=y时,ART会abort,提示Cannot use suspend=y with late-init jdwp。原理上看,应该是未完全初始化前,无法使用调试器。

1-23 15:44:02.062 15371 15371 D AndroidRuntime: >>>>>> START com.android.internal.os.RuntimeInit uid 0 <<<<<<
01-23 15:44:02.071 15371 15371 I AndroidRuntime: Using default boot image
01-23 15:44:02.071 15371 15371 I AndroidRuntime: Leaving lock profiling enabled
01-23 15:44:02.076 15371 15371 I app_process: Core platform API reporting enabled, enforcing=false
01-23 15:44:02.243 15371 15371 E app_process: Cannot use suspend=y with late-init jdwp.
01-23 15:44:02.244 15371 15371 F app_process: runtime.cc:1657] Plugin { library=”libadbconnection.so”, handle=0x0 } failed to load: Initialization of plugin failed
01-23 15:44:02.314 15371 15371 F app_process: runtime.cc:630] Runtime aborting…
01-23 15:44:02.314 15371 15371 F app_process: runtime.cc:630] Dumping all threads without mutator lock held
01-23 15:44:02.314 15371 15371 F app_process: runtime.cc:630] All threads:
01-23 15:44:02.314 15371 15371 F app_process: runtime.cc:630] DALVIK THREADS (1):
01-23 15:44:02.314 15371 15371 F app_process: runtime.cc:630] “main” prio=5 tid=1 Runnable (still starting up)
01-23 15:44:02.314 15371 15371 F app_process: runtime.cc:630] | group=”” sCount=0 dsCount=0 flags=0 obj=0x0 self=0x77abc10800
01-23 15:44:02.314 15371 15371 F app_process: runtime.cc:630] | sysTid=15371 nice=0 cgrp=default sched=0/0 handle=0x78321e6ed8
01-23 15:44:02.314 15371 15371 F app_process: runtime.cc:630] | state=R schedstat=( 496134003 4942656 33 ) utm=20 stm=29 core=4 HZ=100
01-23 15:44:02.314 15371 15371 F app_process: runtime.cc:630] | stack=0x7fdbd37000-0x7fdbd39000 stackSize=8192KB
01-23 15:44:02.314 15371 15371 F app_process: runtime.cc:630] | held mutexes= “abort lock” “mutator lock”(shared held)
01-23 15:44:02.314 15371 15371 F app_process: runtime.cc:630] native: #00 pc 0000000000411f18 /apex/com.android.runtime/lib64/libart.so (art::DumpNativeStack(std::1::basic_ostream<char, std::1::char_traits>&, int, BacktraceMap, char const, art::ArtMethod, void, bool)+140)
01-23 15:44:02.314 15371 15371 F app_process: runtime.cc:630] native: #01 pc 00000000004f977c /apex/com.android.runtime/lib64/libart.so (art::Thread::DumpStack(std::1::basic_ostream<char, std::1::char_traits>&, bool, BacktraceMap, bool) const+512)
01-23 15:44:02.314 15371 15371 F app_process: runtime.cc:630] native: #02 pc 00000000005140c0 /apex/com.android.runtime/lib64/libart.so (art::DumpCheckpoint::Run(art::Thread
)+828)

尝试trace

由于需要初始化时的trace,普通的trace功能肯定是无法满足要求了。
因为前面app_process -v中给出了art支持 -Xmethod-trace,所以尝试了如下命令(也参考了art自己的测试用例304-method-tracing/run)。

1
app_process -verbose:class  -Xmethod-trace  -Xmethod-trace-file:/data/local/tmp/trace.bin  /system/bin com.android.commands.am.Am instrumen

这一命令可以正常地生成trace文件,直接用文本编辑器可以打开并查看头部信息,但是剩余信息是二进制的。
将其pull到pc机器上,可以用android studio打开。
具体方法是:
将文件pull到pc上
将文件名改为.trace结尾(一定要改,否则android studio会报错)
android studio中打开profiler
点击+号,选择load from file,然后选中前面的trace即可