网页设计比较优秀的网站,沈阳网站推广公司,网站做中英文切换,加快政务网站群建设管理分析思路
内存泄漏是指 Android 进程中#xff0c;某些对象已经不再使用#xff0c;但被一些生命周期更长的对象引用#xff0c;导致其占用的内存资源无法被GC回收#xff0c;内存占用不断增加的一种现象#xff1b;内存泄漏是导致我们应用性能下降、卡顿的一种常见因素某些对象已经不再使用但被一些生命周期更长的对象引用导致其占用的内存资源无法被GC回收内存占用不断增加的一种现象内存泄漏是导致我们应用性能下降、卡顿的一种常见因素解决此类问题最核心的思路可以总结为以下两步
模拟内存泄漏的操作路径观察应用 Heap 内存变化确定出现问题的大概位置针对具体位置展开分析找到泄漏对象指向 GC Root 的完整引用链从源头治理内存泄漏。
分析工具Android Stuido Profiler
Profiler 中常用到的内存分析的工具有两个内存曲线图和 Heap Dump内存曲线可以实时观察内存使用状态协助我们进行内存的动态分析
内存泄漏出现时内存曲线典型的现象就是呈现阶梯状一旦上升则难以下降例如 Activity 泄漏后反复打开、关闭页面内存占用会一路上升并且点击垃圾桶图标手动GC后占用量无法下降到打开 Activity 之前的水平这时大概率出现内存泄漏了。
这时我们可以手动 dump 此时刻应用堆内存中的内存分布情况用作静态分析 UI中的各项指标说明
Allocations堆内存中该类的实例个数Native Size该类所有实例引用到的Native对象所占内存Shallow Size该类所有实例自身的实际内存占用大小不包括其所引用到的对象的内存占用大小Retained Size与 Shallow Size 不同这个数字代表该类所有实例及其所有引用到的对象的内存占用大小
借助一张图可以对这几个属性有更直观的印象 如上图红点的内存大小代表 Shallow Size蓝点为 Native Size所有橙色点的内存大小则为 Retained Size当出现内存泄漏时我们更应该关注 Retained Size 这个数字它的意义是因内存泄漏导致 Java 堆内存中所浪费的内存空间大小。 因为内存泄漏往往会形成“链式效应”从泄漏的对象出发该对象引用的所有对象和 Native 资源都无法回收造成内存使用效率的下降。
另外 Leaks 代表可能的内存泄漏实例数量点击列表中的类可以查看该类的实例详情Instance 列表中的 depth 代表该实例到达 GC Root 的最短调用链深度在图1右侧 Reference 一栏堆栈中可以直观地看到完整调用链这时就可以一路追溯找出最可疑的引用结合代码分析泄漏原因并对症下药根治问题。
接下来分析几个我们在项目中遇到一部分典型内存泄漏的案例
案例剖析
案例1BitmapBinder 内存泄漏
在涉及跨进程传输 Bitmap 的场景时我们采用了一种 BitmapBinder 的方法因为 Intent 支持我们传入自定义的 Binder因此可以借助 Binder 实现 Intent 传输 Bitmap 对象
// IBitmapBinder AIDL文件
import android.graphics.Bitmap;
interface IBitmapInterface { Bitmap getIntentBitmap();
}然而Activity1 在使用 BitmapBinder 向 Activity2 传递 Bitmap 后出现了两个严重的内存泄漏问题
跳转后再返回Activity1 finish 时无法回收反复跳转时Bitmap 和 Binder 对象会反复创建且无法回收
先分析 Heap Dump 这是一个『多实例』内存泄漏即每次 finish Activity1 再打开都会增加一个 Activity 对象留在 Heap 中无法销毁常见于内部类引用、静态数组引用如监听器列表等场景根据 Profiler 提供的引用链我们找到了 BitmapExt 这个类
suspend fun Activity.startActivity2WithBitmap() {val screenShotBitmap withContext(Dispatchers.IO) { SDKDeviceHelper.screenShot() } ?: returnstartActivity(Intent().apply {val bundle Bundle()bundle.putBinder(KEY_SCREENSHOT_BINDER, object : IBitmapInterface.Stub() {override fun getIntentBitmap(): Bitmap {return screenShotBitmap}}) putExtra (INTENT_QUESTION_SCREENSHOT_BITMAP, bundle)})
}BitmapExt 有一个 Activity 的全局扩展方法 startActivity2WithBitmap里面创建了一个 Binder将获取到的屏幕截图 Bitmap 丢进去并包在 Intent 中发送到 Activity2 显然这里有个IBitmapInterface的匿名内部类看来泄漏是从这里发生的
但有两个疑问一是这个内部类是写在方法里的方法结束时不会把方法栈中的内部类引用清除掉吗二是这个内部类也并没有引用到 Activity 吧
要搞明白这两点就要把 Kotlin 代码反编译成 Java 看看了
Nullable
public static final Object startActivity2WithBitmap(NotNull Activity $this$startActivity2WithBitmap, boolean var1, NotNull Continuation var2) {...Bitmap var14 (Bitmap)var10000;if (var14 null) {return Unit.INSTANCE;} else {Bitmap screenShotBitmap var14;Intent var4 new Intent();int var6 false;Bundle bundle new Bundle();// 内部类创建位置bundle.putBinder(screenShotBinder, (IBinder)(new BitmapExtKt$startActivity2WithBitmap$$inlined$apply$lambda$1($this$startActivity2WithBitmap, screenShotBitmap)));var4.putExtra(question_screenshot_bitmap, bundle);Unit var9 Unit.INSTANCE;$this$startActivity2WithBitmap.startActivity(var4);return Unit.INSTANCE;}
}// 这是kotlin compiler自动生成的一个普通类
public final class BitmapExtKt$startActivity2WithBitmap$$inlined$apply$lambda$1 extends IBitmapInterface.Stub {// $FF: synthetic fieldfinal Activity $this_startActivity2WithBitmap$inlined; // 引用了activity// $FF: synthetic fieldfinal Bitmap $screenShotBitmap$inlined;BitmapExtKt$startActivity2WithBitmap$$inlined$apply$lambda$1(Activity var1, Bitmap var2) {this.$this_startActivity2WithBitmap$inlined var1;this.$screenShotBitmap$inlined var2;}NotNullpublic Bitmap getIntentBitmap() {return this.$screenShotBitmap$inlined;}
}在 Kotlin Compiler 编译生成的 Java 文件中IBitmapInterface 匿名内部类被替换为普通类 BitmapExtKt$startActivity2WithBitmap$$inlined$apply$lambda$1并且这个普通类持有了 Activity。出现这个情况的原因是Kotlin 为了在该类的内部能正常使用方法内的变量把方法的入参以及内部类代码以上创建的所有变量都写进了该类的成员变量中因此 Activity 被该类引用另外 Binder 本身生命周期长于 Activity因此产生内存泄漏。
解决方法是直接声明一个普通类即可绕过 Kotlin Compiler 的“优化”移除 Activity 的引用。
class BitmapBinder(private val bitmap: Bitmap): IBitmapInterface.Stub() {override fun getIntentBitmap( ) bitmap
}// 使用
bundle.putBinder(KEY_SCREENSHOT_BINDER, BitmapBinder(screenShotBitmap))接下来问题是 Bitmap 和 Binder 会反复创建且无法回收的问题内存现象如图每次跳转再关闭内存都会上涨一点如同阶梯GC 后无法释放 heap 中通过 Bitmap 尺寸 2560x1600, 320density 可以推断这些都是未能回收的截图 Bitmap 对象被 Binder 持有但查看 Binder 的引用链却并没有发现任何被我们应用相关的引用 我们推测 Binder 应该是被生命周期较长的 Native 层引用了与 Binder 的实现有关但没找到回收 Binder 的有效方法
一种解决办法是复用 Binder确保每次打开 Activity2 时Binder 不会重复创建另外将 BitmapBinder 的 Bitmap 改为弱引用这样即使 Binder 不能回收Bitmap 也能被及时回收毕竟 Bitmap 才是内存大户。
object BitmapBinderHolder {private var mBinder: BitmapBinder? null // 保证全局只有一个BitmapBinderfun of(bitmap: Bitmap): BitmapBinder {return mBinder ?: BitmapBinder(WeakReference(bitmap)).apply { mBinder this }}
}class BitmapBinder(var bitmapRef: WeakReferenceBitmap?): IBitmapInterface.Stub() {override fun getIntentBitmap() bitmapRef?.get()
}// 使用
bundle.putBinder(KEY_SCREENSHOT_BINDER, BitmapBinderHolder.of(screenShotBitmap))验证如内存图一次 GC 后创建的所有 Bitmap 都可以正常回收。 案例2Flutter 多引擎场景 插件内存泄漏
有不少项目使用了多引擎方案实现 Flutter 混合开发在 Flutter 页面关闭时为避免内存泄漏不但要将 FlutterView、FlutterEngine、MessageChannel 等相关组件及时解绑销毁同时也需要关注各个 Flutter 插件是否有正常的释放操作。
例如在我们的一个多引擎项目中通过反复打开关闭一个页面发现了一个内存泄漏点 这个activity是一个二级页面使用多引擎方案在上面跑了一个 FlutterView 看样子是一个『单实例』的内存泄漏即无论开关多少次Activity 只会保留一个实例在heap中无法释放常见的场景是全局静态变量的引用。这种内存泄漏对内存的影响比多实例泄漏略轻一点但如果这个 Activity 体量很大持有较多的 Fragment、View这些相关组件一起泄漏的话也是要着重优化的。
从引用链来看这是 FlutterEngine 内的一个通信 Channel 引起的内存泄漏当 FlutterEngine 被创建时引擎内的每个插件会创建出自己的MessageChannel并注册到FlutterEngine.dartExecutor.binaryMessenger中以便每个插件都能独立和 Native 通信。
例如一个普通插件的写法可能是这样
class XXPlugin: FlutterPlugin {private val mChannel: BasicMessageChannelAny? nulloverride fun onAttachedToEngine(NonNull flutterPluginBinding: FlutterPlugin.FlutterPluginBinding) { // 引擎创建时回调mChannel BasicMessageChannel(flutterPluginBinding.flutterEngine.dartExecutor.binaryMessenger, CHANNEL_NAME, JSONMessageCodec.INSTANCE)mChannel?.setMessageHandler { message, reply -...}}override fun onDetachedFromEngine(NonNull binding: FlutterPlugin.FlutterPluginBinding) { // 引擎销毁时回调mChannel?.setMessageHandler(null)mChannel null}
}可以看到其实 FlutterPlugin 其实是会持有 binaryMessenger 的引用的而 binaryMessenger 又会有 FlutterJNI 的引用… 这一系列引用链最终会使 FlutterPlugin 持有 Context因此如果插件没有正确释放引用就必然会出现内存泄漏。
我们看下上图引用链中 loggerChannel 的写法是怎么样的
class LoggerPlugin: FlutterPlugin {override fun onAttachedToEngine(flutterPluginBinding: FlutterPlugin.FlutterPluginBinding) {LoggerChannelImpl.init(flutterPluginBinding.getFlutterEngine())}override fun onDetachedFromEngine(binding: FlutterPlugin.FlutterPluginBinding) {}
}object LoggerChannelImpl { // 这是一个单例private var loggerChannel: BasicMessageChannelAny? nullfun init(flutterEngine: FlutterEngine) {loggerChannel BasicMessageChannel(flutterEngine.dartExecutor.binaryMessenger, LOGGER_CHANNEL, JSONMessageCodec.INSTANCE)loggerChannel?.setMessageHandler { messageJO, reply -...}}
}在 LoggerPlugin.onAttachedToEngine 中将 FlutterEngine 传入到了单例 LoggerChannelImpl 里面binaryMessenger 被单例持有且 onDetachedFromEngine 方法未做销毁操作因此一直被单例引用context无法释放。
这个插件可能在设计时没有考虑到多引擎的场景单引擎时插件的 onAttachedToEngine、onDetachedFromEngine 相当于是跟着应用的生命周期走的因此不会出现内存泄漏但在多引擎场景下DartVM 会为每个引擎分配 isolate和进程有些类似isolate 的 dart 堆内存是完全独立的因此引擎之间任何对象包括静态对象都不互通因此 FlutterEngine 会在自己的 isolate 中创建各自的 FlutterPlugin 实例这使得每次创建引擎插件的生命周期都会重走一遍。当销毁一个引擎时插件没有正常回收没有及时释放 Context、FlutterEngine 的相关引用就会出现内存泄漏。
修改方案
LoggerChannelImpl 无需使用单例写法替换为普通类即可确保每个引擎的 MessageChannel都是独立的LoggerPlugin.onDetachedFromEngine 需要对 MessageChannel 做销毁和置空操作
案例3三方库 Native 引用 内存泄漏
项目中接入了一个三方阅读器 SDK在一次内存分析时发现每次打开该阅读器内存便会上升一截并且无法下降从 heap dump 文件看Profiler 并未指出项目中存在内存泄漏但可以看到 app heap 中有一个 Activity 未能回收的实例个数非常多且内存占用较大。
查看 GCRoot References发现这些 Activity 没有被任何已知的 GCRoot 引用 毫无疑问这个 Activity 是存在内存泄漏的因为操作的时候已经把相关页面都 finish 掉并且手动 GC因此原因只能是 Activity 被某个不可见的 GCRoot 引用了。
事实上Profiler 的 Heap Dump 只会显示 Java 堆内存的 GCRoot而在 Native 堆中的 GCRoot 并不会显示到这个引用列表中。所以有没有可能是这个Activity被 Native 对象持有了
我们用动态分析工具 Allocations Record 看一下 Java 类在 Native 堆的引用果然发现了这个 Activity 的一些引用链 但可惜引用链都是一些内存地址没有显示类名没法知道是何处引用到了 Activity后面用 LeakCanary 试了一下虽然也明确说明了是 Native 层 Global Variable 的引用造成的内存泄漏但还是没有提供具体的调用位置 我们只好回到源码去分析下可能的调用处了。这个是 DownloadActivity 是我们为了适配阅读器SDK做的一个书籍下载的页面当本地没有图书时会先下载书籍文件随后传入 SDK 中打开 SDK 自己的 Activity因此DownloadActivity 的功能就是下载、校验、解压书籍并处理 SDK 阅读器的一些启动流程。
按常规思路先检查下载、校验、解压的代码都没有发现疑点listener 之类的都做了弱引用封装因此推测是 SDK 自身的写法导致的内存泄漏。
发现阅读器 SDK 启动时有一个 context 入参
class DownloadActivity {... private fun openBook() {... ReaderApi.getInstance().startReader(this, bookInfo) }
}由于这个 SDK 的源码都是混淆过的只能硬啃了从 startReader 方法点进去一路跟踪调用链
class ReaderApi: void startReader(Activity context, BookInfo bookInfo) ↓
class AppExecutor: void a(Runnable var1) ↓
class ReaderUtils: static void a(Activity var0, BookViewerCallback var1, Bundle var2) ↓
class BookViewer: static void a(Context var0, AssetManager var1) ↓
class NativeCpp: static native void initJNI(Context var0, AssetManager var1);最后到了 NativeCpp 这个类的 initJNI 方法可以看到这个本地方法把我们的 Activity 传进去了后续处理不得而知但基于上面的内存分析我们基本可以断定正是由于这个方法Activity 的引用被 Native 的长生命周期对象持有导致 Activity 出现内存泄漏。
至于为什么 Native 需要用到 context 则没法分析了我们只能将这个问题反馈给 SDK 供应商让他们做进一步处理。解决办法也不难
在销毁阅读器时及时置空 Activity 引用startReader 方法不需要指定 Activity 对象入参声明改为 Context 即可外部就可以将 Application Context 传进去。
为了帮助到大家更好的全面清晰的掌握好性能优化准备了相关的核心笔记还该底层逻辑https://qr18.cn/FVlo89
性能优化核心笔记https://qr18.cn/FVlo89
启动优化 内存优化 UI优化 网络优化 Bitmap优化与图片压缩优化https://qr18.cn/FVlo89 多线程并发优化与数据传输效率优化 体积包优化
《Android 性能监控框架》https://qr18.cn/FVlo89 《Android Framework学习手册》https://qr18.cn/AQpN4J
开机Init 进程开机启动 Zygote 进程开机启动 SystemServer 进程Binder 驱动AMS 的启动过程PMS 的启动过程Launcher 的启动过程Android 四大组件Android 系统服务 - Input 事件的分发过程Android 底层渲染 - 屏幕刷新机制源码分析Android 源码分析实战
