1概述
介绍
内存抖动:锯齿状,GC导致卡顿
内存泄漏,可用内存减少,频繁GC
内存溢出:OOM,程序异常
工具
1Memory Profiler
AS自带实时图表展示应用内存使用量
识别内存泄漏(简单判断)、抖动
提供捕获堆转储、强制GC以及跟踪内存分配的能力
方便直观
线下平时使用
2Memory Analyzer --》MAT
强大的java Heap分析工具,查找内存泄漏及内存占用
生成整体报告、分析问题等
线下深入使用
3LeakCanary
自动内存泄漏检测
也是线下集成
2Android 内存管理机制
java内存管理机制
java内存分配
1.pngjava内存回收算法
2.png 3.png效率不高:需要从头到尾
产生大量不连续碎片
实现简单,运行相比上一个高效
浪费一半内存,代价大
避免了标记清除导致的内存碎片
避免了复制算法的看空间浪费
Android内存管理机制
9.png 10.png 11.png3内存抖动解决实战
内存抖动介绍
定义:内存频繁分配和税收导致的内存不稳定
表现:频繁GC、内存曲线呈锯齿状
危害:卡顿、OOm;频繁创建对象,导致内存不足及不连续,不连续的内存无法被分配,导致OOm。
内存抖动解决实战
使用Memort Profiler初步排查:
12.png 13.png 14.png 16.png找到了。
4内存泄漏实战解决
内存泄漏介绍
定义:内存中存在已经没有用的对象
表现:内存抖动,可用内存逐渐减少
危害:内存不足,GC频繁,OOM
Memory Analyzer MAT
17.png内存泄漏实战
18.png 19.pngMemort Profiler发现 逐渐上升,此时用MAT了
20.png点击进行堆转储
后执行命令
用MAT打开
22.png现在要找到内存泄漏位置
23.pngHistogram
24.png 25.png 26.png当然这里也没有软引用
27.png左下角有个圆圈 "sCallBacks"
28.png添加解决方案
29.png5全面理解MAT
略
6ARTHook优雅检测不合理图片
Bitmap内存模型
API10之前Bitmap自身在Balvik Heap中,像素在Native中(不占用java 内存;回收时机不确定);
API10之后像素也放在Balvik Heap中;
API26之后,更优的方法又把像素在Native中。
常规方式
背景:图片对内存优化至关重要、图片宽高远大于控件宽高。
实现:继承ImageView,复写实现计算大小。
1侵入性强
2不通用
ARTHook实战
挂钩,将额外的代码勾住原有方法,修改执行逻辑
1运行时插桩
2性能分析
注入
35.png无侵入性
通用性强
兼容问题大,开源方案不能带到线上环境
7线上内存监控方案
常规方案
设定场景线上Dump:Debug.dumpHprofData();将当前内存信息转化成本地文件(比较大,wifi时)
36.pngDump文件太大,和对象数正相关,可裁剪,还有几十兆。
上传失败率高、分析困难。
配合一定策略有一定效果
LeakCanary
LeakCanary带到线上
预设泄漏怀疑点
发现泄漏回传
不适合所有情况,必须预设怀疑点
分析比较耗时,也容易oom
LeakCanary原理
监控生命周期,onDestroy添加RefWatcher检测
二次确认断定发生内存泄漏
分析泄漏找出引用链
监控组件+分析组件
LeakCanary改良
预设怀疑点---》自动找怀疑点
分析泄露链路慢---》分析Retain size大的对象
分析oom---》对象裁剪,不全都加载到内存
完整线上内存监控方案
37.png8内存优化总结
38.png优化细节
LargeHeap 属性 --》申请更多内存
onTrimMemory 低内存回调
使用优化过得集合:SparseArray
谨慎使用SharedPreference:第一次会全都加载到内存里;
谨慎使用外部库:未经过大规模验证的
业务架构设计合理
9内存优化模拟面试
你们内存优化怎么做的?
1分析现状 确认问题。
抖动、泄漏 bitmap粗狂
2针对性优化
抖动--》memory profler
3效率提升
使用arthook没有侵入性,写了文档分享给团队。
内存优化最大感受
1磨刀不误砍柴工。
学习memory profler 、Mat后能很快定位解决
2技术优化必须结合业务代码
比如用了多个图片库。
3系统化完善解决方案
如何检测所有不合理的地方
ArtHook
重点强调区别:最初是继承ImageView复写OnDraw方法,但是推广过程中不理想。后来是用ArtHook
网友评论