我的进阶曲线十三

binder_mmap目前在代码中size为：

BINDER_VM_SIZE

在我们手机里面通过 adb shell cat /proc/vmallocinfo 可以看到，

通过binder_mmap映射的虚拟内存正好是这么大：（1020K）

查看应用启动时长

am start -W -n com.example.appstart.preview/com.example.MainActivity

在构造HWComposer对象时，选择了VSync信号产生方式：1.硬件产生；2.软件模拟产生；假如当前系统可以成功加载HWC_HARDWARE_MODULE_ID=hwcomposer，并且通过这个库能顺利打开设备(hwc_composer_device_t)，并且其版本号又大于HWC_DEVICE_API_VERSION_0_3的话，我们就采用硬件方式产生VSync，否则需要创建一个新的VSync线程来模拟产生信号。

Q家抓FTRACE

查询所有可跟踪的event：

adb shell cat /sys/kernel/debug/tracing/available_events 

根据查询结果，选取你所感兴趣的event（如这里的mdss）来配置ftrace event：

adb shell "echo mdss:* >> /sys/kernel/debug/tracing/set_event".

操作手机的同时，按如下方式抓取ftrace信息：

adb shell cat /sys/kernel/debug/tracing/trace 

https://www.projecth.us/source s

systrace 分析 tips：

和正常流畅的surfaceflinger信息进行对比。

关注cpu/gpu频率，状态。

关注surfaceflinger是否和vsync同步，不同步（16ms时间内未能交给GPU）就容易造成掉帧。

不同步，

很可能是因为MDP合成时间太长（此时在surfaceflinger这一行应该出现eglSwapBuffers）

或者是因为GPU处理时间太长，迟迟不能释放FB。

postFramebuffer执行之后，表明此时交给了GPU去执行，surfaceflinger这一行应该有空白时间间隔才正常。

surfaceflinger分析时候，也要看看最顶部的进程状态条颜色，如果是棕色，表明surfaceflinger进程处于sleep状态。

最后，

要特别关注上一次 eglswapbuffer 结束到下一次 eglswapbuffer 结束的时长（不管是surfaceflinger 还是具体应用，严重超过16ms都会有问题）。

分析surfacefligner dump小技巧：                 

从dump出来的layer的信息来看，在黑屏的时候，UsbSettings界面的visibleRegion是0，所以这个layer并没有被composer到底层，导致黑屏的时候画出来的是imagewallpaper。

+ Layer 0x7f94885000 (com.android.settings/com.android.settings.activities.UsbSettings)

               Region transparentRegion (this=0x7f948851e0, count=1)

              [  0,   0,   0,   0]

               Region visibleRegion (this=0x7f94885010, count=1)

               [  0,   0,   0,   0]

heapminfree 配置越大，GC次数越少，单次GC耗时越长，GC总耗时越大，开机内存占用越高。

场景	GC次数	单次GC平均值	GC总耗时时长	开机使用内存
默认场景	29	98.43	2854	806MB
512k-8m	28	149.29	4180	857MB
4m-8m	21	215.64	4528	880MB

M家FTARCE:

当您拿到ftrace_all_in_one_latest.zip之后，请在user mode下按照如下步骤进行： 
一般情况下只需要0xE即可 
需要使用如下命令： 
adb shell setprop debug.atrace.tags.enableflags 0xE 
adb shell "setprop debug.egl.traceGpuCompletion 1" 
adb shell stop 
adb shell start 
2 .双击打开ftrace_all_in_one里面的01-catch.bat，按照提示按任意键开始，然后开始模拟你认为卡顿的操作，但卡顿发生之后，按照提示按任意键结束，待01-catch.bat运行完后自动会退出。 
3.双击打开02-parse.bat，结束后会自动生成trace.html 
4.上传trace.html 给我们分析(请告诉我们卡顿发生几秒后停止录Ftrace的，便于我们找到相关时间点)

input keyevent KEYCODE_HOME

导出data分区：

/dev/block/platform/7824900.sdhci/by-name
mount | grep data
/dev/block/bootdevice/by-name/userdata /data
userdata -> /dev/block/mmcblk0p42

adb shell reboot bootloader

fastboot.exe flash boot   boot.im g

grep -nrw string ./

Android如何生成成coredump文件？ 
(1)修改init.rc增加如下(相关于执行ulimit -c unlimited) 
setrlimit 4 -1 -1 
write /proc/sys/kernel/core_pattern "/local/log/core-%e-%p-%t" 
(2)也需要增加如下脚本： 
echo "1" > /proc/sys/kernel/core_uses_pid //允许文件名后加pid 
echo "/local/log/core-%e-%p" > /proc/sys/kernel/core_pattern 
echo 1 > /proc/sys/fs/suid_dumpable

echo c > /proc/sysrq-trigger