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 中
- 引入第三方库要谨慎
