Android中内存泄漏需要的注意点

2024-10-05 06:21:59

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

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

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

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

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

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

内部类形式使用 Handler 同时发送延时消息，或者在 Handler 里面执行耗时任务，在任务还没完成的时候 Activity 需要销毁。这时候由于 Handler 持有 Activity 的强引用导致 Activity 无法被回收。

同理内部类形式的使用 AsyncTask 执行耗时任务也会导致内存泄漏的发生。

单例作为最长生命周期的对象，自然不应该持有 Activity 从而导致内存泄漏发生；

针对上面这种情况，基本不必多说了，不要使用内部类或者匿名内部类做这样的处理就好了，实际上 IDE 也会弹出警告，我想大家应该还是都知道采用静态内部类或者在销毁页面的时候使用相关方法移除处理的。

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 这样的库去做检测。

Android 5.1 WebView内存泄漏问题及快速解决方法

问题背景在排查项目内存泄漏过程中发现了一些由WebView引起的内存泄漏,经过测试发现该部分泄漏只会出现在android 5.1及以上的机型.虽然项目使用WebView的场景并不多,但秉承着一个泄漏都不放过的精神,我们肯定要把它给解决了. 遇到的问题项目中使用WebView的页面主要在FAQ页面,问题也出现在多次进入退出时,发现内存占用大,GC频繁.使用LeakCanary观察发现有两个内存泄漏很频繁: 我们分析一下这两个泄漏: 从图一我们可以发现是WebView的ContentViewCo
Android中LeakCanary检测内存泄漏的方法

最近要对产品进行内存泄漏的检查,最后选择了使用Square公司开源的一个检测内存泄漏的函数库LeakCanary,在github上面搜索了一下竟然有1.6w个star,并且Android大神JakeWharton也是这个开源库的贡献者.那么就赶快拿来用吧. 先说一下我遇到的坑,我当时是直接google的,然后就直接搜索到稀土掘金的一篇关于LeakCanary的介绍,我就按照他们的文章一步步的操作,到最后才发现,他们那个build.gradle中导入的库太老了,会报这样的错误Closed Fail
Android Handler内存泄漏详解及其解决方案

关联篇:深入Android的消息机制源码详解-Handler,MessageQueue与Looper关系关联篇:HandlerThread 使用及其源码完全解析在android开发过程中,我们可能会遇到过令人奔溃的OOM异常,面对这样的异常我们是既熟悉又深恶痛绝的,因为造成OOM的原因有很多种情况,如加载图片过大,某已不再使用的类未被GC及时回收等等......本篇我们就来分析其中一种造成OOM的场景,它就是罪恶的内存泄漏.对于这样的称呼,我们并不陌生,甚至屡次与之"并肩作战",
Android内存泄漏的轻松解决方法

前言内存管理的目的就是让我们在开发过程中有效避免我们的应用程序出现内存泄露的问题.内存泄露相信大家都不陌生,我们可以这样理解:「没有用的对象无法回收的现象就是内存泄露」. 如果程序发生了内存泄露,则会带来以下这些问题应用可用的内存减少,增加了堆内存的压力降低了应用的性能,比如会触发更频繁的 GC 严重的时候可能会导致内存溢出错误,即 OOM Error 下面我们从基础说起基础知识 Java 的内存分配简述方法区(non-heap):编译时就分配好,在程序整个运行期间都存在.它主要存放静
Android Studio 3.0上分析内存泄漏的原因

以前用eclipse的时候,我们采用的是DDMS和MAT,不仅使用步骤复杂繁琐,而且要手动排查内存泄漏的位置,操作起来比较麻烦.后来随着Android studio的潮流,我也抛弃了eclipse加入了AS. Android Studio也开始支持自动进行内存泄漏检查,并且操作起来也比较方便. 封面戳我下载 Android Studio 3.0 这个不用梯子我会告诉你吗 1.写在前面 Google在上周发布了Android Studio 3.0的正式版本,周四早晨在上班的地铁上就看到群里在沸沸
Android Studio+MAT实战内存泄漏

对于内存泄漏,在Android中如果不注意的话,还是很容易出现的,尤其是在Activity中,比较容易出现,下面我就说下自己是如何查找内存泄露的. 首先什么是内存泄漏? 内存泄漏就是一些已经不使用的对象还存在于内存之中且垃圾回收机制无法回收它们,导致它们常驻内存,会使内存消耗越来越大,最终导致程序性能变差. 其中在Android虚拟机中采用的是根节点搜索算法枚举根节点判断是否是垃圾,虚拟机会从GC Roots开始遍历,如果一个节点找不到一条到达GC Roots的路线,也就是没和GC Roots
Android内存泄漏排查利器LeakCanary

本文为大家分享了Android内存泄漏排查利器,供大家参考,具体内容如下开源地址:https://github.com/square/leakcanary 在 build.gralde 里加上依赖, 然后sync 一下, 添加内容如下 dependencies { .... debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5' releaseCompile 'com.squareup.leakcanary:leakcanar
Android中内存泄漏需要的注意点

内存泄漏对每一位 Android 开发一定是司空见惯,大家或多或少都肯定有些许接触.大家都知道,每一个手机都有一定的承载上限,多处的内存泄漏堆积一定会堆积如山,最终出现内存爆炸 OOM. 而这,也是极有可能在 Android 面试中一道常见的开放题. 内存泄漏的根本原因是一个长生命周期的对象持有了一个短生命周期的对象.如果你对垃圾回收机制有所了解,我想这个问题基本难不住你,因为知道了原理,自然不会去触碰这些极易导致内存泄漏的雷区. 该题重在积累,不需要死记硬背,自己多总结即可. 1. 长生命周期
Android Handler内存泄漏原因及解决方案

目录: 1.须知: 主线程Looper生命周期和Activity的生命周期一致. 非静态内部类,或者匿名内部类.默认持有外部类引用. 2.原因: Handler造成内存泄露的原因.非静态内部类,或者匿名内部类.使得Handler默认持有外部类的引用.在Activity销毁时,由于Handler可能有未执行完/正在执行的Message.导致Handler持有Activity的引用.进而导致GC无法回收Activity. 3.可能造成内存泄漏匿名内部类: //匿名内部类 Handler handl
深入理解JavaScript程序中内存泄漏

垃圾回收解放了我们,它让我们可将精力集中在应用程序逻辑(而不是内存管理)上.但是,垃圾收集并不神奇.了解它的工作原理,以及如何使它保留本应在很久以前释放的内存,就可以实现更快更可靠的应用程序.在本文中,学习一种定位 JavaScript 应用程序中内存泄漏的系统方法.几种常见的泄漏模式,以及解决这些泄漏的适当方法. 一.简介当处理 JavaScript 这样的脚本语言时,很容易忘记每个对象.类.字符串.数字和方法都需要分配和保留内存.语言和运行时的垃圾回收器隐藏了内存分配和释放的具体细节. 许
JavaScript中内存泄漏的介绍与教程（推荐）

本文主要给大家详细介绍了关于JavaScript中内存泄漏的相关内容,文中介绍的非常详细,对大家具有一定的参考学习价值,下面来一起看看详细的介绍: 一.什么是内存泄漏? 程序的运行需要内存.只要程序提出要求,操作系统或者运行时(runtime)就必须供给内存. 对于持续运行的服务进程(daemon),必须及时释放不再用到的内存.否则,内存占用越来越高,轻则影响系统性能,重则导致进程崩溃. 不再用到的内存,没有及时释放,就叫做内存泄漏(memory leak). 有些语言(比如 C 语言)必须手动
Android Native 内存泄漏系统化解决方案

导读:C++内存泄漏问题的分析.定位一直是Android平台上困扰开发人员的难题.因为地图渲染.导航等核心功能对性能要求很高,高德地图APP中存在大量的C++代码.解决这个问题对于产品质量尤为重要和关键,高德地图技术团队在实践中形成了一套自己的解决方案. 分析和定位内存泄漏问题的核心在于分配函数的统计和栈回溯.如果只知道内存分配点不知道调用栈会使问题变得格外复杂,增加解决成本,因此两者缺一不可. Android中Bionic的malloc_debug模块对内存分配函数的监控及统计是比较完善的,但
避免 Android中Context引起的内存泄露

Context是我们在编写Android程序经常使用到的对象,意思为上下文对象. 常用的有Activity的Context还是有Application的Context.Activity用来展示活动界面,包含了很多的视图,而视图又含有图片,文字等资源.在Android中内存泄露很容易出现,而持有很多对象内存占用的Activity更加容易出现内存泄露,开发者需要特别注意这个问题. 本文讲介绍Android中Context,更具体的说是Activity内存泄露的情况,以及如何避免Activity内存泄
Java中关于内存泄漏出现的原因汇总及如何避免内存泄漏（超详细版）

Android 内存泄漏总结内存管理的目的就是让我们在开发中怎么有效的避免我们的应用出现内存泄漏的问题.内存泄漏大家都不陌生了,简单粗俗的讲,就是该被释放的对象没有释放,一直被某个或某些实例所持有却不再被使用导致 GC 不能回收.最近自己阅读了大量相关的文档资料,打算做个总结沉淀下来跟大家一起分享和学习,也给自己一个警示,以后 coding 时怎么避免这些情况,提高应用的体验和质量. 我会从 java 内存泄漏的基础知识开始,并通过具体例子来说明 Android 引起内存泄漏的各种原因,以
Android中SparseArray性能优化的使用方法

之前一篇文章研究完横向二级菜单,发现其中使用了SparseArray去替换HashMap的使用.于是乎自己查了一些相关资料,自己同时对性能进行了一些测试.首先先说一下SparseArray的原理. SparseArray(稀疏数组).他是Android内部特有的api,标准的jdk是没有这个类的.在Android内部用来替代HashMap<Integer,E>这种形式,使用SparseArray更加节省内存空间的使用,SparseArray也是以key和value对数据进行保存的.使用的时候只
对ThreadLocal内存泄漏及弱引用的理解

ThreadLocal内存泄漏及弱引用 1.什么是内存泄漏?Entry的key弱引用与泄漏关系在TreadLocal中内存泄漏是指TreadLocalMap中的Entry中的key为null,而value不为null.因为key为null导致value一直访问不到,而根据可达性分析,始终有threadRef->currentThread->threadLocalMap->entry->valueRef->valueMemory,导致在垃圾回收的时候进行可达性分析的时候,va

Android中内存泄漏需要的注意点

相关推荐

随机推荐