Android应用性能优化和性能分析

Memory 分析和优化

有OOM发生但是没有现场保留

结合logcat和代码分析造成oom的泄漏点，一般OOM 都是程序员自身每注意Handler, bitmap，以及对象相互引用等等造成的，具体平时怎么防范可以参考【没有OOM发生Memory分析】

有OOM 发生但是有现场保留

现场有保留情况dump memory 和查看进程top 信息，然后按照测试手法操作查看memory 信息，结合操作和日志确认最终泄漏点

没有OOM发生Memory分析

OOM 产生一般都是程序员疏忽产生的，以下分享一下自己对memory 的一些处理

代码每次书写完毕，可以使用AS Profiler 分析一下对应memory，一般比较常见的leak 都可以被发现

Screenshot from 2021-08-01 15-36-12.png
操作apk 界面一段时间，期间查看AS Profiler Memory 走形曲线，如果曲线一直处于上升，GC 后也没有太大变化，此时可以record 并查看对应memory分析文件
使用monkey 工具进行测试，并记录对应进程的memory, cpu信息，操作相对一段时间，将产生的memory和cpu数据导成图形，查看对应图形曲线，结合对应时间点和monkey 操作进行分析
使用LeakCanary 等第三方工具，具体使用流程网上有很多，我这里就不多做介绍。

应用启动速度

分析应用启动优化点

adb shell am start -W -S com.test.Myaplication/.MainActivity 该命令只能大致看到应用启动条件
log过滤Displayed关键字
获得并分析trace 文件

// 进程启动时加入
 Debug.startMethodTracing("XXXTrace");
在自己想结束trace的地方加入
 // Debug.stopMethodTracing();
// 自己可以根据自己的需求进行trace 文件的记录, 分享一下我的做法
1. application onCreate 加入Debug.startMethodTracing("XXXTrace");
2. 第一帧上屏时结束
getWindow().getDecorView().post(() -> new Handler().post(() -> {
       Debug.stopMethodTracing();
})); 
// trace 文件地址
/sdcard/Android/data/包名/files/XXXXTrace.trace

然后自己可以使用Chrome或者AS 分析产生的trace 文件, 分析对应组件的启动时间

关键点埋日志, 并计算执行时差, 这个也是最通用也最简单的方式

优化应用启用速度

使用懒加载, 建议数据在首帧上屏后再加载
有广告页的app, 可以利用广告页空隙进行预加载
禁止使用xml 加载帧数比较多的帧动画
采用分页加载

Apk 瘦身

网络加载图片, 图片尽量少预置
简单图片或者动画采用自定义view 或者 Vector 的方式加载
动态下载文件, 不要将文件轻易放到asset 中
引入第三方库要谨慎