首页 > 系统相关> > 日积月累 | Android面试：Android 中内存泄漏都有哪些注意点？谈谈你对 LeakCanary 的了解？

日积月累 | Android面试：Android 中内存泄漏都有哪些注意点？谈谈你对 LeakCanary 的了解？

2021-01-29 16:35:24 作者：互联网

作者：nanchen

内存泄漏对每一位 Android 开发一定是司空见惯，大家或多或少都肯定有些许接触。大家都知道，每一个手机都有一定的承载上限，多处的内存泄漏堆积一定会堆积如山，最终出现内存爆炸 OOM。

而这，也是极有可能在 Android 面试中一道常见的开放题。

内存泄漏的根本原因是一个长生命周期的对象持有了一个短生命周期的对象。如果你对垃圾回收机制有所了解，我想这个问题基本难不住你，因为知道了原理，自然不会去触碰这些极易导致内存泄漏的雷区。

该题重在积累，不需要死记硬背，自己多总结即可。

1. 长生命周期对象持有 Activity

这基本是最常见的内存泄漏了，比如

内部类形式使用 Handler 同时发送延时消息，或者在 Handler 里面执行耗时任务，在任务还没完成的时候 Activity 需要销毁。这时候由于 Handler 持有 Activity 的强引用导致 Activity 无法被回收。
同理内部类形式的使用 AsyncTask 执行耗时任务也会导致内存泄漏的发生。
单例作为最长生命周期的对象，自然不应该持有 Activity 从而导致内存泄漏发生；

针对上面这种情况，基本不必多说了，不要使用内部类或者匿名内部类做这样的处理就好了，实际上 IDE 也会弹出警告，我想大家应该还是都知道采用静态内部类或者在销毁页面的时候使用相关方法移除处理的。实际上，使用 Kotlin 或者 Java 8 的 Lambda 表达式同样不会导致内存泄漏的发生，这是因为实际上它也是使用的静态内部类，没有持有外部引用。

Activity 中匿名使用 Handler 实际上会导致 Handler 内部类持有外部类的引用，而 SendMessage() 的时候 Message 会持有 Handler，enqueueMessage 机制又会导致 MeassageQueue 持有 Message。所以当发送的是延迟消息那么 Message 并不会立即的遍历出来处理而是阻塞到对应的 Message 触发时间以后再处理。那么阻塞的这段时间中页面销毁一定会造成内存泄漏。

2. 各种注册操作没有对应的反注册

这一点基本不必多说，相信大家刚刚开始学习广播和 Service 的时候一定对此有所接触，然后就是比如我们常用的第三方框架 EventBus 也是一样的。平时使用的时候注意在对应的生命周期方法中进行反注册。

3. Bitmap 使用完没有注意 recycle()

Bitmap 作为大对象，在使用完毕一定要注意调用 recycle() 进行回收。TypedArray 、Cursor、各种流同理，一定要在最后调用自己的回收关闭方法处理。

4. WebView 使用不当

WebView 是非常常用的控件，但稍有不注意也会导致内存泄漏。内存泄漏的场景：很多人使用 Webview 都喜欢采用布局引用方式, 这其实也是作为内存泄漏的一个隐患。当 Activity 被关闭时，Webview 不会被 GC 马上回收,而是提交给事务，进行队列处理，这样就造成了内存泄漏, 导致 Webview 无法及时回收。

目前所知的比较安全的方案是：

在布局中动态添加 WebView。
采用下面的方法。

override fun onDestroy() {
    webView?.apply {
        val parent = parent
        if (parent is ViewGroup) {
            parent.removeView(this)
        }
        stopLoading()
        // 退出时调用此方法，移除绑定的服务，否则某些特定系统会报错
        settings.javaScriptEnabled = false
        clearHistory()
        removeAllViews()
        destroy()
    }
}

5. 循环引用

循环引用导致内存泄漏比较少见，正常来讲不会有人写出 A 持有 B，B 持有 C，C 又持有A 这样的代码，不过总还是需要注意。

总的来说，内存泄漏很常见，但检测方式也很多。我们的 Android Studio 自带的 Monitors 就可以帮我们找到大部分内存问题，当然我们也可以采用譬如 LeakCanary 这样的库去做检测。

LeakCanary 的基本工作流程是怎样的？

LeakCanary 的使用方式非常简单，只需要在 build.gradle 里面直接写上依赖，并且在 Application 类里面做注册就可以了。

当然，需要在 Application 里面注册这样的操作仅在大多数人接触的 1.x 版本，实际上 LeakCanary 现在已经升级到了 2.x 版本，代码侵入性更低，而且纯 Kotlin 写法。从 Google 各种 Demo 主推 Kotlin 以及各种主流库都在使用 Kotlin 编写来看可见 Kotlin 确实在 Android 开发中愈发重要，没使用的小伙伴必须得去学习一波了，目前我也是纯 Kotlin 做开发的。

对于工作原理我相信大家应该也是或多或少有一定了解，这里刚好有一张非常不错的流程图就直接借用过来了，另外他从源码角度理解 LeakCanary 的这篇文章也写的非常不错，感兴趣的点击文章底部的链接直达。

初次使用 LeakCanary 为什么没有 Icon 入口

我们常常在使用 LeakCanary 的时候会发现这样一个问题：最开始并没有出现 LeakCanary 的 Launcher icon，但当出现了内存泄漏警告的时候系统桌面就多了这么一个图标，一般情况下都是会非常好奇的。

从 1.x 的源码中就可以看出端倪。在 leakcanary-android 的 manifast 中，我们可以看到相关配置：

<!--leakcanary-sample/src/main/AndroidManifest.xml-->
<service
    android:name=".internal.HeapAnalyzerService"
    android:process=":leakcanary"
    android:enabled="false"
    />
<service
    android:name=".DisplayLeakService"
    android:process=":leakcanary"
    android:enabled="false"
    />
<activity
    android:theme="@style/leak_canary_LeakCanary.Base"
    android:name=".internal.DisplayLeakActivity"
    android:process=":leakcanary"
    android:enabled="false"
    android:label="@string/leak_canary_display_activity_label"
    android:icon="@mipmap/leak_canary_icon"
    android:taskAffinity="com.squareup.leakcanary.${applicationId}"
    >
  <intent-filter>
    <action android:name="android.intent.action.MAIN"/>
    <category android:name="android.intent.category.LAUNCHER"/>
  </intent-filter>
</activity>

我们可以看到 DisplayLeakActivity 被设置为了 Launcher，并设置上了对应的图标，所以我们使用 LeakCanary 会在系统桌面上生成 Icon 入口。但是 DisplayLeakActivity 的 enable 属性默认是 false，所以在桌面上是不会显示入口的。而在发生内存泄漏的时候，LeakCanary 会主动将 enable 属性置为 true。

LeakCanary 2 都做了些什么

最近 LeakCanary 升级到了 2.x 版本，这是一次完全的重构，去除了 1.x release 环境下引用的空包 leakcanary-android-no-op。并且 Kotlin 语言覆盖高达 99.8%，也再也不需要在 Application 里面做类似下面的代码。

//com.example.leakcanary.ExampleApplication
@Override
public void onCreate() {
    super.onCreate();
    if (LeakCanary.isInAnalyzerProcess(this)) {
        // This process is dedicated to LeakCanary for heap analysis.
        // You should not init your app in this process.
        return;
    }
    LeakCanary.install(this);
}

只需要在依赖里面添加这样的代码就可以了。

dependencies {
  debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.0-alpha-2'
}

初次看到这样的操作，会觉得非常神奇，仔细阅读源码才回发现它竟然使用了一个骚操作：ContentProvider。

在 leakcanary-leaksentry 模块的 AndroidManifest.xml文件中可以看到：

<?xml version="1.0" encoding="utf-8"?>
<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.squareup.leakcanary.leaksentry"
    >

  <application>
    <provider
        android:name="leakcanary.internal.LeakSentryInstaller"
        android:authorities="${applicationId}.leak-sentry-installer"
        android:exported="false"/>
  </application>
</manifest>

再经过查看 LeakSentryInstaller 可以看到：

package leakcanary.internal

import android.app.Application
import android.content.ContentProvider
import android.content.ContentValues
import android.database.Cursor
import android.net.Uri
import leakcanary.CanaryLog

/**
 * Content providers are loaded before the application class is created. [LeakSentryInstaller] is
 * used to install [leaksentry.LeakSentry] on application start.
 */
internal class LeakSentryInstaller : ContentProvider() {

  override fun onCreate(): Boolean {
    CanaryLog.logger = DefaultCanaryLog()
    val application = context!!.applicationContext as Application
    InternalLeakSentry.install(application)
    return true
  }

  override fun query(
    uri: Uri,
    strings: Array<String>?,
    s: String?,
    strings1: Array<String>?,
    s1: String?
  ): Cursor? {
    return null
  }

  override fun getType(uri: Uri): String? {
    return null
  }

  override fun insert(
    uri: Uri,
    contentValues: ContentValues?
  ): Uri? {
    return null
  }

  override fun delete(
    uri: Uri,
    s: String?,
    strings: Array<String>?
  ): Int {
    return 0
  }

  override fun update(
    uri: Uri,
    contentValues: ContentValues?,
    s: String?,
    strings: Array<String>?
  ): Int {
    return 0
  }
}

确实是真的骚，我们都知道 ContentProvider 的 onCreate() 的调用时机介于 Application 的 attachBaseContext() 和 onCreate() 之间，LeakCanary 这么做，把 init 的逻辑放到库内部，让调用方完全不需要在 Application 里去进行初始化了，十分方便。这样下来既可以避免开发者忘记初始化导致一些错误，也可以让我们庞大的 Application 代码更加简洁。

面试复习笔记：

这份资料我从春招开始，就会将各博客、论坛。网站上等优质的Android开发中高级面试题收集起来，然后全网寻找最优的解答方案。每一道面试题都是百分百的大厂面经真题+最优解答。包知识脉络 + 诸多细节。
节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。
给文章留个小赞，就可以免费领取啦~

戳我获取：Android对线暴打面试指南、超硬核Android面试知识笔记、3000页Android开发者架构师核心知识笔记

《1307页Android开发面试宝典》

包含了腾讯、百度、小米、阿里、乐视、美团、58、猎豹、360、新浪、搜狐等一线互联网公司面试被问到的题目。熟悉本文中列出的知识点会大大增加通过前两轮技术面试的几率。

《507页Android开发相关源码解析》

只要是程序员，不管是Java还是Android，如果不去阅读源码，只看API文档，那就只是停留于皮毛，这对我们知识体系的建立和完备以及实战技术的提升都是不利的。

真正最能锻炼能力的便是直接去阅读源码，不仅限于阅读各大系统源码，还包括各种优秀的开源库。

资料已经上传在我的GitHub

文末

听说点赞关注的小伙伴都面试成功了？如果本篇博客对你有帮助，请支持下小编哦

Android高级面试精选题、架构师进阶实战文档传送门：我的GitHub

整写作易，觉得有帮助的朋友可以帮忙点赞分享支持一下小编~

你的支持，我的动力；祝各位前程似锦，offer不断！！！

标签：泄漏,leakcanary,LeakCanary,日积月累,内存,Android,android
来源： https://www.cnblogs.com/button123/p/14345641.html