分析引擎
端上分析引擎的性能很重要,这里我们主要对比了 LeakCanary 的分析引擎 Shark 和 Haha 库的 MAT。
图 6. Shark VS MAT
我们在相同客户端环境对 160M 的 HPROF 多次分析对比发现 MAT 分析速度明显优于 Shark,另外针对 MAT 分析后仍持有统治者树占用内存我们也做了主动释放,对比性能收益后采用基于 MAT 库的分析引擎进行分析,对内存泄漏引用链路自动归并、大对象小对象引用链自动分析、大图线下自动还原线上过滤无用链路,分析结果如下:
内存泄漏
图 7. 内存泄漏链路
对泄漏的 Activity 的引用链进行了聚合分析,方便一次性解决该 Activity 的泄漏链释放内存。
大对象
图 8. 大对象链路
大对象不止分析了引用链路,还递归分析了内部 top 持有对象(InRefrenrece
)的 RetainedSize。
小对象
图 9. 小对象链路
小对象我们对 top 的外部持有对象(OutRefrenrece
)进行聚合得到占有小对象最多的链路。
图片
图 10. 图片链路
图片我们过滤了图片库等无效引用且对 Android 8.0 以下的大图在线下进行了还原。
回传分析
为了最大限度的节省用户流量且规避隐私风险,我们通过自研 HPROF 裁剪工具 Tailor 在 dump 过程对 HPROF 进行了裁剪。
裁剪过程
图 11. Tailor 裁剪流程
去除了无用信息
-
跳过 header
-
分 tag 裁剪
-
裁剪无用信息:char[]; byte[]; timestamp; stack trace serial number; class serial number;
-
压缩数据信息
同时对数据进行 zlib 压缩,在 server 端数据还原,整体裁剪效果:180M—>50M---->13M
=======================================================================
除了通过后台根据 GCROOT+ 引用链自动分配研发跟进解决我们常见的内存泄漏外,我们还对系统导致一些内存泄漏进行了分析和修复。
系统异步 UI 泄漏
根据上传聚合的引用链我们发现在 Android 6.0 以下有一个 HandlerThread 作为 GCROOT 持有大量 Activity 导致内存泄漏,根据引用发现这些泄漏的 Activity 都被一个 Runnable(这里是 Runnable 是一个系统事件 SendViewStateChangedAccessibilityEvent
)持有,这些 Runnable 被添加到一个 RunQueuel 中,这个队列本身被 TheadLocal 持有。
图 12. HandlerThread 泄露链路
我们从 SendViewStateChangedAccessibilityEvent
入手对源码进行了分析发现它在 notifyViewAccessibilityStateChangedIfNeeded
中被抛出,系统的大量 view 都会在自身的一些 UI 方法(eg: setChecked)中触发该函数。
SendViewStateChangedAccessibilityEvent
的 runOrPost
方法会走到我们常用的 View 的 postDelay
方法中,这个方法在当 view 还未被 attched 到根 view 的时候会加入到一个 runQueue 中。
这个 runQueue 会在主线程下一次的 performTraversals()
中消费掉。
如果这个 runQueue 不在主线程那就没有消费的机会。
根据上面的分析发现造成这种内存泄漏需要满足一些条件:
-
view 调用了
postDelay
方法 (这里是notifyViewAccessisbilityStateChangeIfNeeded
触发) -
view 处于 detached 状态
-
上述过程是在非主线程里面操作的,ThreadLocal 非 UIThread,持有的 runQueue 不会走
performTraversals
消费掉。
抖音这边大量使用了异步 UI 框架来优化渲染性能,框架内部由一个 HandlerThread 驱动,完全符合上述条件。针对该问题,我们通过反射获取非主线程的 ThreadLocal,在每次异步渲染完主动清理内部的 RunQueue。
图 13. 反射清理流程
另外,Google 在 6.0 上也修复了 notifyViewAccessisbilityStateChangeIfNeeded
的判断不严谨问题。
内存泄漏兜底
大量的内存泄漏,如果我们都靠推进研发解决,经常会出现生产大于消费的情况,针对这些未被消费的内存泄漏我们在客户端做了监控和止损,将 onDestory 的 Activity 添加到 WeakRerefrence 中,延迟 60s 监控是否回收,未回收则主动释放泄漏的 Activity 持有的 ViewTree 的背景图和 ImageView 图片。
主要对三种类型的大对象进行优化
-
全局缓存:针对全局缓存我们按需释放和降级了不需要的缓存,尽量使用弱引用代替强引用关系,比如针对频繁泄漏的 EventBus 我们将内部的订阅者关系改为弱引用解决了大量的 EventBus 泄漏。
-
系统大对象:系统大对象如 PreloadDrawable、JarFile 我们通过源码分析确定主动释放并不干扰原有逻辑,在启动完成或在内存触顶时主动反射释放。
-
动画:用原生动画代替了内存占用较大的帧动画,并对 Lottie 动画泄漏做了手动释放。
图 14. 大对象优化点
小对象优化我们集中在字段优化、业务优化、缓存优化三个纬度,不同的纬度有不同的优化策略。
图 15. 小对象优化思路
通用类优化
在抖音的业务中,视频是最核心且通用的 Model,抖音业务层的数据存储分散在各个业务维护了各自视频的 Model,Model 本身由于聚合了各个业务需要的属性很多导致单个实例内存占用就不低,随着用户使用过程实例增长内存占用越来越大。对 Model 本身我们可以从属性优化和拆分这两种思路来优化。
-
字段优化:针对一次性的属性字段,在使用完之后及时清理掉缓存,比如在视频 Model 内部存在一个 Json 对象,在反序列完成之后 Json 对象就没有使用价值了,可以及时清理。
-
类拆分:针对通用 Model 冗杂过多的业务属性,尝试对 Model 本身进行治理,将各个业务线需要用到的属性进行梳理,将 Model 拆分成多个业务 Model 和一个通用 Model,采用组合的方式让各个业务线最小化依赖自己的业务 Model,减少大杂烩 Model 不必要的内存浪费。
业务优化
-
按需加载:抖音这边 IM 会全局保存会话,App 启动时会一次性 Load 所有会话,当用户的会话过多时相应全局占用的内存就会较大,为了解决该问题,会话列表分两次加载,首次只加载一定数量到内存,需要时再加载全部。
-
内存缓存限制或清理:首页推荐列表的每一次 Loadmore 操作,都不会清理之前缓存起来的视频对象,导致用户长时间停留在推荐 Feed 时,缓存起来的视频对象过多会导致内存方面的压力。在通过实验验证不会对业务产生负面影响情况下对首页的缓存进行了一定数量的限制来减小内存压力。
缓存优化
上面提到的视频 Model,抖音最早使用 Manager 来管理通用的视频实例。Manager 使用 HashMap 存储了所有的视频对象,最初的方案里面没有对内存大小进行限制且没有清除逻辑,随着使用时间的增加而不断膨胀,最终出现 OOM 异常。为了解决视频 Model 无限膨胀的问题设计了一套缓存框架主要流程如下:
图 16. 视频缓存框架
使用 LRU 缓存机制来缓存视频对象。在内存中缓存最近使用的 100 个视频对象,当视频对象从内存缓存中移除时,将其缓存至磁盘中。在获取视频对象时,首先从内存中获取,若内存中没有缓存该对象,则从磁盘缓存中获取。在退出 App 时,清除 Manager 的磁盘缓存,避免磁盘空间占用不断增长。
关于图片优化,我们主要从图片库的管理和图片本身优化两个方面思考。同时对不合理的图片使用也做了兜底和监控。
图片库
针对应用内图片的使用状况对图片库设置了合理的缓存,同时在应用 or 系统内存吃紧的情况下主动释放图片缓存。
图片自身优化
我们知道图片内存大小公式 = 图片分辨率 * 每个像素点的大小。
图片分辨率我们通过设置合理的采样来减少不必要的像素浪费。
//开启采样ImagePipelineConfig config = ImagePipelineConfig.newBuilder(context) .setDownsampleEnabled(true) .build();Fresco.initialize(context, config);//请求图片时,传入resize的大小,一般直接取View的宽高ImageRequest request = ImageRequestBuilder.newBuilderWithSource(uri) .setResizeOptions(new ResizeOptions(50, 50)) .build();mSimpleDraweeView.setController( Fresco.newDraweeControllerBuilder() .setOldController(mSimpleDraweeView.getController()) .setImageRequest(request) .build());
而单个像素大小,我们通过替换系统 drawable 默认色彩通道,将部分没有透明通道的图片格式由 ARGB_8888 替换为 RGB565,在图片质量上的损失几乎肉眼不可见,而在内存上可以直接节省一半。
图片兜底
针对因 activity、fragment 泄漏导致的图片泄漏,我们在 onDetachedFromWindow
时机进行了监控和兜底,具体流程如下:
图 17. 图片兜底流程
图片监控
关于对不合理的大图 or 图片使用我们在字节码层面进行了拦截和监控,在原生 Bitmap or 图片库创建时机记录图片信息,对不合理的大图进行上报;另外在 ImageView 的设置过程中针对 Bitmap 远超过 view 本身超过大小的场景也进行了记录和上报。
图 18. 图片字节码监控方案
=======================================================================
是不是解决了 OOM 内存问题就告一段落了呢?作为一只追求极致的团队,我们除了解决静态的内存占用外也自研了 Kenzo(Memory Insight)工具尝试解决动态内存分配造成的 GC 卡顿。
Kenzo 采用 JVMTI 完成对内存监控工作,JVMTI(JVM Tool Interface)是 Java 虚拟机所提供的 native 编程接口。JVMTI 开发时,应用建立一个 Agent 使用 JVMTI,可以使用 JVMTI 函数,设置回调函数,并从 Java 虚拟机中得到当前的运行态信息,并作出自己的业务判断。
图 19. Agent 时序图
Jvmti SetEventCallbacks
方法可以设置目标虚拟机内部事件回调,可以根据 jvmtiCapabilities
支持的能力和我们关注的事件来定义需要 hook 的事件。
Kenzo 采用 Jvmti 完成如下事件回调:
-
类加载准备事件 -> 监控类加载
-
ClassPrepare:某个类的准备阶段完成。
-
GC -> 监控 GC 事件与时间
-
GarbageCollectionStart:GC 启动时。
-
GarbageCollectionFinish:GC 结束后。
-
对象事件 -> 监控内存分配
-
ObjectFree:GC 释放一个对象时。
-
VMObjectAlloc:虚拟机分配一个对象的时候。
框架设计
Kenzo 整体分为两个部分:
生产端
-
采集内存数据
-
以 sdk 形式集成到宿主 App
消费端
-
处理生产端的数据
-
输入 Kenzo 监控的内存数据
-
输出可视化报表
最后
看完上述知识点如果你深感Java基础不够扎实,或者刷题刷的不够、知识不全面
小编专门为你量身定制了一套<Java一线大厂高岗面试题解析合集:JAVA基础-中级-高级面试+SSM框架+分布式+性能调优+微服务+并发编程+网络+设计模式+数据结构与算法>
针对知识面不够,也莫慌!还有一整套的<Java核心进阶手册>,可以瞬间查漏补缺
全都是一丢一丢的收集整理纯手打出来的
更有纯手绘的各大知识体系大纲,可供梳理:Java筑基、MySQL、Redis、并发编程、Spring、分布式高性能架构知识、微服务架构知识、开源框架知识点等等的xmind手绘图~
找小编(vip1024c)领取
输入 Kenzo 监控的内存数据
- 输出可视化报表
最后
看完上述知识点如果你深感Java基础不够扎实,或者刷题刷的不够、知识不全面
小编专门为你量身定制了一套<Java一线大厂高岗面试题解析合集:JAVA基础-中级-高级面试+SSM框架+分布式+性能调优+微服务+并发编程+网络+设计模式+数据结构与算法>
[外链图片转存中…(img-xkAjFAJB-1721629249126)]
针对知识面不够,也莫慌!还有一整套的<Java核心进阶手册>,可以瞬间查漏补缺
[外链图片转存中…(img-6ttWKhOJ-1721629249127)]
全都是一丢一丢的收集整理纯手打出来的
更有纯手绘的各大知识体系大纲,可供梳理:Java筑基、MySQL、Redis、并发编程、Spring、分布式高性能架构知识、微服务架构知识、开源框架知识点等等的xmind手绘图~
[外链图片转存中…(img-rIWe4lyj-1721629249127)]
[外链图片转存中…(img-zkojG9s3-1721629249128)]
找小编(vip1024c)领取