15 企业网站优化方案有哪些内容,wordpress 梦月酱,广东深圳网站建设微信商城开发,网络营销ppt模板内存泄漏是一个隐形炸弹#xff0c;其本身并不会造成程序异常#xff0c;但是随着量的增长会导致其他各种并发症#xff1a;OOM#xff0c;UI 卡顿等。
为什么要将 Activity 单独做预防#xff1f;
因为 Activity 承担了与用户交互的职责#xff0c;因此内部需要持有大…内存泄漏是一个隐形炸弹其本身并不会造成程序异常但是随着量的增长会导致其他各种并发症OOMUI 卡顿等。
为什么要将 Activity 单独做预防
因为 Activity 承担了与用户交互的职责因此内部需要持有大量的资源引用以及与系统交互的 Context这会导致一个 Activity 对象的 retained size 特别大。一旦 Activity 因为被外部系统所持有而导致内存泄漏会牵连导致其他对象的内存泄漏也会非常多。
造成 Activity 内存泄漏的场景
1)将 Context 或者 View 置为 static View 默认会持有一个 context 的引用如果将其设置为 static将会照成 view 在方法区中无法被快速回收最终导致 Activity 内存泄漏。上图中的 ImvageView 会造成 ActivityB 无法被 GC 回收。
2未解注册各种 Listener 在 Activity 中可能会注册各种系统监听器比如广播。运行上述 ActivityC 然后按下返回键控制台将会显示如下 log提示有内存泄漏发生。 3非静态 Handler 导致 Activity 泄漏 上述代码中的 Handler 也会造成 ActivityD 发生内存泄漏。一般需要将其置为 static然后内部持有一个 Activity 的弱引用来避免内存泄漏。如下所示 4第三库使用 Context 在项目中经常会使用各种第三方库有些第三方库的初始化需要我们传入一个 context 对象。但是第三方库中很有可能一直持有此 context 的引用。上述代码中将ActivityE 本身当做了一个 context 传递给了一个模拟的第三方库 ThirdParty 中。但是在第三方库中将传入的 context 重新置为一个静态的 static 类型。这种情况是一个隐形的 Activity 泄漏在我们自己的项目中很难查出。所以在开发过程中尽量使用 Context.getApplicationContext不要直接将 Activity 传递给其它组件。
内存泄漏检测
在开发阶段可以直接使用 Android Studio 来查看 Activity 是否存在内存泄漏并结合 MAT 来查看发生内存泄漏的具体对象。详细使用过程可以参考Android Studio 和 MAT 结合使用来分析内存问题
LeakCanary
除了 Android Studio另一检测内存泄漏的神器就是 LeakCannary。LeakCanary 是 Square 公司的一个开源库通过它可以在 App 运行过程中检测内存泄漏。当内存泄漏发生时会生成发生泄漏对象的引用链并通知程序开发人员。LeakCanary 主要分2大核心部分
1如何检测内存泄漏
2分析内存泄漏对象的引用链。
如何检测内存泄漏---JVM理论知识
Java 中的 WeakReference 是弱引用类型每当发生 GC 时它所持有的对象如果没有被其它强引用持有那么它所引用的对象就会被回收。比如以下代码 上述代码执行过后打印如下
可以看出BigObject 并没有被其它强引用所持有所以在 GC 回收后WeakReference 所持有的 BigObject 对象被回收了。
WeakReference 的构造函数可以传入一个 ReferenceQueue当 WeakReference 指向的对象被垃圾回收器回收时会把 WeakReference 放入 ReferenceQueue 中如下所示 上述代码调用 WeakReference 的构造器时传入一个自定义的 ReferenceQueue那么打印结果如下 可以看出当 BigObject 被回收之后WeakReference 会被添加到所传入的 ReferenceQueue 中。
在修改一下上述代码模拟一个内存泄漏。如下代码所示 BigObject 是一个强引用导致 new BigObject 的内存空间不会被 GC 回收。最终打印结果如下 LeakCanary 实现思路
LeakCanary 中对内存泄漏检测的核心原理就是基于 WeakReference 和 ReferenceQueue 实现的 当一个 Activity 需要被回收时就将其包装到一个 WeakReference 中。并且在 WeakReference 的构造器中传入自定义的 ReferenceQueue 给包装后的 WeakReference 做一个标记 Key并且在一个强引用 Set 中添加相应的 Key 记录 主动触发 GC遍历自定义 ReferenceQueue 中所有的记录并根据获取的 Reference 对象将 Set 中的记录也删除。
经过上面3步还保留在 Set 中的就是应当被 GC 回收但实际还保留在内存中的对象也就是发生泄漏的对象。
源码分析
在上面原理介绍的例子里一个可回收的对象在 System.gc() 之后就应该被 GC 回收。可是在 Android App 中我们并不清楚系统何时会回收 Activity。按照正常流程当 Activity 调用 onDestory 方法时就说明这个 Activity 就已经处于无用状态了。因此需要监听到每一个 Activity 的 onDestory 方法的调用。
ActivityRefWatch
LeakCanary 中监听 Activity 生命周期是由 ActivityRefWatch 来负责的。主要是通过注册 Android 系统提供的 lifecycleCallbacks 来监听 Activity 生命周期方法的调用。如下所示 lifecycleCallbacks 的具体代码如下 可以看出当监听到 Activity 的 onDestory() 方法后会将其传给 refWatcher 的 watch() 方法
RefWatcher
RefWatcher 它是 LeakCanary 的一个核心类用来检测一个对象是否会发生内存泄漏。主要实现是在 watch() 方法中如下代码所示 图中1处生成一个随机的字符串 key这个 key 就是用来标识 WeakReference 的就相当于给 WeakReference 打了一个标签。图中2处将一个被检测对象包装的 WeakReference 中并将其标识为步骤1中生成的 key。图中3处调用 ensureGoneAsync 开始执行检测操作因此关键代码就是在 ensureGoneAsync 中。代码如下 通过 WatchExecutor 执行了一个重载的方法 ensureGone。ensureGone中实现了内存泄漏的检测 图中1处会遍历 ReferenceQueue 中的所有元素并根据每个元素中的 key 相应的将集合 retainedKeys 中的元素也删除图中2处判断集合 retainedKeys 是否还包含被检测对象的弱引用。如果包含说明被检测对象并没有被回收也就是发生了内存泄漏。图中3处生成 heap 堆信息并生成内存泄漏的分析报告上报给程序开发人员。
removeWeaklyReachableReferences() 方法如下 这个方法的主要目的就是从 retainedKeys 中移除已经被回收的 WeakReference 的标志。
gone(reference) 方法判断 reference 是否被回收如下 实现很简单只要在 retainedKeys 中不包含此 reference 就说明 WeakReference 引用的对象已经被回收。
LeakCanary 的实现原理其实比较简单但是内部实现还有一些其它细节值得我们注意。
内存泄漏的检测时机
很显然这种内存泄漏的检测与分析是比较消耗性能的因此为了尽量不影响 UI 线程的渲染LeakCanary 也做了些优化操作。在 ensureGoneAsync 方法中调用 watchExecutor.execute() 方法来执行检测操作如下所示 可以看出实际是向主线程的 MessageQueue 中插入了一个 IdleHandler。IdleHandler 只会在主线程空闲时才会被 Looper 从队列中取出并执行。因此能够有效避免内存检测工作占用 UI 渲染时间。
通过 addIdleHandler也经常用来做 App 的启动优化。比如在 Application 的 onCreate 方法中经常做第三方库的初始化工作。可以将优先级较低、暂时使用不到的第三方库的初始化操作放到 IdleHandler 中从而加快 Application 的启动过程。
特殊机型适配
因为有些特殊机型系统本身就存在一些内存泄漏情况导致 Activity 不被回收所以在检测内存泄漏时需要将这些情况排除在外。
在 LeakCanary 的初始化方法 Install 中通过 excludedRefs 方法指定了一系列需要忽略的场景。这些场景都被枚举在 AndroidExcludedRefs 中。 这种统一规避特殊机型的方式也值得我们借鉴因为国内的手机厂商实在是太多了。
LeakCanary 如何检测其它类
LeakCanary 默认只能检测 Activity 的泄漏但是 RefWatcher 的 watch 方法传入的参数实际是 Object所以理论上是可以检测任何类的。 LeakCanary 的 install() 方法会返回一个 RefWatcher 对象我们只需要在 Application 中保存此 RefWatcher 对象然后将需要被检测的对象传给 watch 方法即可。如上代码所示testedObj 就是一个需要被检测内存泄漏的对象。
总结
本次主要介绍了 Android 内存泄漏优化的相关知识 内存泄漏预防
这需要了解 JVM 发生内存泄漏的原因并在平时开发阶段养成良好的编码规范。针对编码规范 Android Studio 可以安装又给阿里代码规范的插件能够起到一定的代码检查效果。 内存泄漏检测
内存泄漏检测工具有很多 Android Stuido 自带的 Profiler以及 MAT 都是不错的选择。使用这些工具排查内存泄漏门槛稍高并且全部是手动操作略显麻烦。
此外还介绍了一个自动检测内存泄漏的开源库---LeakCanary主要包括它的实现原理以及部分源码实现细节。
