当应用程序为对象分配内存，而对象不再被使用时却没有释放，就会发生内存泄漏。随着时间的推移，泄漏的内存会累积，导致应用程序性能变差，甚至崩溃。泄漏可能发生在任何程序和平台上，但由于活动生命周期的复杂性，这种情况在 Android 应用中尤其普遍。最新的 Android 模式，如 ViewModel 和 LifecycleObserver 可以帮助避免内存泄漏，但如果你遵循旧的模式或不知道要注意什么，很容易漏过错误。
本文最初发布于 Dropbox 技术博客，经原作者授权由 InfoQ 中文站翻译并分享。
最近在群里看到有人在讨论有关内存分析的话题，比较好奇，Enmmm，也就有了今天这篇博文。
移动app开发是一个漫长而费力的过程。然而，现在的企业总是希望能够尽快发布app。幸运的是，我们有很多帮助移动开发人员加快工作步伐的工具。
完整高频题库仓库地址：https://github.com/hzfe/awesome-interview
作为Android开发人员，我们或多或少都听说过内存泄漏。那么何为内存泄漏，Android中的内存泄漏又是什么样子的呢，本文将简单概括的进行一些总结。
该文章是一个系列文章，是本人在Android开发的漫漫长途上的一点感想和记录，我会尽量按照先易后难的顺序进行编写该系列。该系列引用了《Android开发艺术探索》以及《深入理解Android 卷Ⅰ，Ⅱ，Ⅲ》中的相关知识，另外也借鉴了其他的优质博客，在此向各位大神表示感谢，膜拜！！！另外，本系列文章知识可能需要有一定Android开发基础和项目经验的同学才能更好理解，也就是说该系列文章面向的是Android中高级开发工程师。
内存泄漏原理 : 长生命周期对象 , 持有短生命周期对象的引用 , 并且是强引用持有 , GC 无法释放该短生命周期对象引用 , 造成 OOM ;
Android应用大部分性能问题归根结底都会成为内存的问题，今天我们就先以Out of Memory（OOM）为起点介绍一下Android内存的原理以及排查内存问题的方法。
一、概述 Android内存的文章详见：http://blog.csdn.net/linghu_java/article/details/39480761 在Android的开发中，经常听到“内存泄漏”这个词。“内存泄漏”就是一个对象已经不需要再使用了，但是因为其它的对象持有该对象的引用，导致它的内存不能被回收。“内存泄漏”的慢慢积累，最终会导致OOM的发生，千里之堤，毁于蚁穴。所以在写代码的过程中，应该要注意规避会导致“内存泄漏”的代码写法，提高软件的健壮性。 本文将从发现问题、解决问题、总结问题的三个
如上，在Activity内部如果声明一个这样的Handler，那么myHandler就默认持有Activity引用，假设Activity退出了，但是可能这时候才有myHandler的任务post，那么Activity是无法被回收的，可以采用以下方式解决：
存在问题： 不少人认为JAVA程序，因为有垃圾回收机制，应该没有内存泄露。 解决方案： 其实如果我们一个程序中，已经不再使用某个对象，但是因为仍然有引用指向它，垃圾回收器就无法回收它，当然该对象占用的内存就无法被使用，这就造成了内存泄露。如果我们的java运行很久,而这种内存泄露不断的发生，最后就没内存可用了。当然java的，内存泄漏和C/C++是不一样的。如果java程序完全结束后，它所有的对象就都不可达了，系统就可以对他们进行垃圾回收，它的内存泄露仅仅限于它本身，而不会影响整个系统的。C/C++的内存
前言 [1509678808988_1609_1509678856629.png] 对于C++来说，内存泄漏就是new出来的对象没有delete，俗称野指针；对于Java来说，就是new出来的Ob
以前用eclipse的时候，我们采用的是DDMS和MAT，不仅使用步骤复杂繁琐，而且要手动排查内存泄漏的位置，操作起来比较麻烦。后来随着Android studio的潮流，我也抛弃了eclipse加入了AS。
本文介绍了Android App如何实现场景化性能测试，通过具体实践案例，讲解了如何利用Dart语言和AppScan TraceView工具进行代码分析和数据采集，并利用这些数据来定位解决内存泄漏问题。同时，也介绍了如何通过MAT来分析内存泄漏。
Android技术优化日新月异，如今Android 10.0 已经发布，系统性能非常流畅，体验上完全可以媲美iOS；到了各大厂商手里，改源码、自定义系统，使得Android原生系统变得鱼龙混杂；再到不同层次的开发工程师手里，做出来的应用参差不齐，所以很多手机跑分软件上遥遥领先，打开应用依然会卡顿。
在 Android 开发中，内存泄漏是一个常见的问题。这个问题可能会导致应用程序变慢、崩溃或者消耗大量的内存，最终导致设备性能下降。
在长久以来的 Android 开发过程中，内存泄漏一直是一个比较头疼的问题。内存泄漏会导致应用卡顿，用户体验不佳，甚至会造成应用崩溃的严重后果。所以如何科学地进行内存管理一直是大家探讨的话题，从一开始主动使用 MAT 分析 hprof 文件，到后来 LeakCanary “被动”的接收内存泄漏消息。应用中发现内存泄漏的手段越来越多了，操作也越来越便捷，但内存泄漏的问题还是不能轻易忽视的，提高应用的体验和质量也是迫在眉睫。
对于开发老手，这个问题想必已经深入你的心；若是一名新手或者一直对内存泄漏这个东西模模糊糊的工程师，你的答案可能让面试官并不满意，这里将从底到上对内存泄漏的原因、排查方法和一些经验为你做一次完整的解剖。
Java是垃圾回收语言的一种，其优点是开发者无需特意管理内存分配，降低了应用由于局部故障(segmentation fault)导致崩溃，同时防止未释放的内存把堆栈(heap)挤爆的可能，所以写出来的代码更为安全。
关联篇：深入Android的消息机制源码详解－Handler,MessageQueue与Looper关系
在正方形寄存器中，我们在位图缓存上绘制客户的签名。这个位图是设备屏幕的大小，我们在创建它时发生了大量的内存不足（OOM）崩溃。
最近要对产品进行内存泄漏的检查，最后选择了使用Square公司开源的一个检测内存泄漏的函数库LeakCanary，在github上面搜索了一下竟然有1.6w个star，并且Android大神JakeWharton也是这个开源库的贡献者。那么就赶快拿来用吧。
一直以来以为只有C/C++才存在内存泄漏的问题，没想到拥有内存回收机制的Java也可能出现内存泄漏。C/C++存在指针的概念，程序中需要使用指针变量时，就从内存中开辟一块区域，并把该区域的首地址赋值给一个指针，这样程序才可操作该指针指向的内存区域。因为C/C++设计上的原因，手工分配的内存，也要手工来释放，如malloc/free是C中分配/释放内存的运算符，而new/delete则是C++中新增的分配/释放内存的运算符。 Java设计之初就是能够自动回收内存，可是有些时候因为某些因素，内存回收机制并不会都奏效。情况之一是调用了非java接口，比如调用了jni接口，jni中C/C++的内存就要手工回收；情况之二是调用了外部服务，使用完毕就得手工通知外部服务去回收；情况之三是异步处理，实时的内存回收显然顾不上异步处理的任务。
对于内存泄漏，在Android中如果不注意的话，还是很容易出现的，尤其是在Activity中，比较容易出现，下面我就说下自己是如何查找内存泄露的。
内存泄漏对每一位 Android 开发一定是司空见惯，大家或多或少都肯定有些许接触。大家都知道，每一个手机都有一定的承载上限，多处的内存泄漏堆积一定会堆积如山，最终出现内存爆炸 OOM。
强引用：类似“Object obj = new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
1.Bitmap优化 Bitmap非常消耗内存， 而且在Android中，读取bitmap时， 一般分配给虚拟机的图片堆栈只有8M，所以经常造成OOM问题。 所以有必要针对Bitmap的使用作出优化： 1.1. 图片显示：加载合适尺寸的图片，比如显示缩略图的地方不要加载大图。 1.2. 图片回收：使用完bitmap，及时使用Bitmap.recycle()回收。 问题：Android不是自身具备垃圾回收机制吗？此处为何要手动回收。 Bitmap对象不是new生成的，而是通过BitmapFactory生产的。 通过源码可发现是通过调用JNI生成Bitmap对象（nativeDecodeStream()等方法）。 所以， 加载bitmap到内存里包括两部分， Dalvik（ART）内存和Linux kernel内存。 前者会被虚拟机自动回收。 而后者必须通过recycle()方法， 内部调用nativeRecycle()让linux kernel回收。 1.3. 捕获OOM异常：程序中设定如果发生OOM的应急处理方式。 1.4. 图片缓存：内存缓存、硬盘缓存等 1.5. 图片压缩：直接使用ImageView显示Bitmap时会占很多资源， 尤其当图片较大时容易发生OOM。 可以使用BitMapFactory.Options对图片进行压缩。 1.6. 图片像素（质量）：android默认颜色模式为ARGB_8888， 显示质量最高，占用内存最大。 若要求不高时可采用RGB_565等模式。 还可以使用WebP； 图片大小：图片长度 * 宽度 * 单位像素 所占据字节数 ARGB_4444：每个像素占用2byte内存 ARGB_8888：每个像素占用4byte内存 （默认） RGB_565：每个像素占用2byte内存 1.7. 考虑使用inBitmap；图片优化之inBitmap 2. 巧用对象引用类型
前言 内存泄漏向来都是内存优化的重点，它如同幽灵一般存于我们的应用当中，有时它不会现身，但一旦现身就会让你头疼不已。因此，如何避免、发现和解决内存泄漏就变得尤为重要，这一篇我们先来学习如何避免内存泄漏
链接：https://juejin.im/post/5e72b2d151882549236f9cb8
Android 系统从 2008 年正式发布到现在已经过去了 11年，系统版本也来到了 10，作为开发者，或者作为用户，我们见证了系统一次次大大小小的改动，见证了系统的不断完善，见证了我们写的每个 Android 小程序给我们带来的成就感。但是，当我们写的程序越来越多时，当我们对 Android 应用开发越来越了解时，我们发现它并不完美，甚至有些简陋：
引言 今天又是没什么事情，好，不多说，直接进入我们的主题吧。 今天说的是关于内存泄漏的检测与解决。这个问题想必对于初学者是个迷，也不知道从何出入手，那么今天这个文章可以帮助你。如果有什么地方写的不好，请谅解，毕竟我还是个孩子！！！ 找出内存泄漏与解决 请各位同学打开我们的开发工具（AS），来跟我一起写个内存泄漏的项目（嘻嘻）。不多说，上代码！！！ /** * Author lingchen * Email 838878458@qq.com * Time 2016/11/3
刚入门的童鞋肯能都会有一个疑问，Java不是有虚拟机了么，内存会自动化管理，我们就不必要手动的释放资源了，反正系统会给我们完成。其实Java中没有指针的概念，但是指针的使用方式依然存在，一味的依赖系统
前言 在这个系列的前四篇文章中，我分别介绍了DVM、ART、内存泄漏和内存检测工具的相关知识点，这一篇我们通过一个小例子，来学习如何使用内存分析工具MAT。 1.概述 在进行内存分析时，我们可以使用Memory Monitor和Heap Dump来观察内存的使用情况、使用Allocation Tracker来跟踪内存分配的情况，也可以通过这些工具来找到疑似发生内存泄漏的位置。但是如果想要深入的进行分析并确定内存泄漏，就要分析 疑似发生内存泄漏时所生成堆存储文件。堆存储文件可以使用DDMS或者Memory
戳我下载 Android Studio 3.0：https://developer.android.google.cn/studio/index.html
1.概述 如果使用MAT来分析内存问题，会有一些难度，并且效率也不是很高，对于一个内存泄漏问题，可能要进行多次排查和对比。 为了能够简单迅速的发现内存泄漏，Square公司基于MAT开源了LeakCa
虚拟机栈：线程私有，随线程创建而创建。栈里面是一个一个“栈帧”，每个栈帧对应一次方法调用。栈帧中存放了局部变量表（基本数据类型变量和对象引用）、操作数栈、方法出口等信息。当栈调用深度大于JVM所允许的范围，会抛出StackOverflowError的错误。
当打开一个内存泄漏追踪日志时，我首先会看底部的对象，了解它的生命周期，这将帮助我理解内存泄漏追踪中的其他对象是否应该有相同的生命周期。
在Android开发中最让人们头疼的就是内存泄漏了，今天来介绍一个查看内存是否泄漏的工具LeakCanary，并通过研究源码明白它是如何分析和查找存在泄漏信息的 首先送上LeakCanary文档链接:[LeakCanary中文使用说明](https://www.liaohuqiu.net/cn/posts/leak-canary-read-me/) Part1. 知识回顾 常用工具 1. Mat 2. LeakCanary(Square） 原理
对于Android开发者来说，懂得基本的应用开发技能往往是不够，因为不管是工作还是面试，都需要开发者懂得大量的性能优化，这对提升应用的体验是非常重要的。对于Android开发来说，性能优化主要围绕如下方面展开：启动优化、渲染优化、内存优化、网络优化、卡顿检测与优化、耗电优化、安装包体积优化、安全问题等。 下面是我整理了网上很多大佬的经验分享对Android性能优化做了一个总结。
为了简单方便的检测内存泄漏，Square开源了LeakCanary，它可以实时监测活动是否发生了泄漏，一旦发现就会自动弹出提示及相关的泄漏信息供分析。
最近,因为项目时间不紧的原因,就对项目的某些页面进行了内存观察,发现了两处优化点.特意记录下来
【Android 内存优化】Android Profiler 工具常用功能 ( 监测内存 | 内存快照 )
一、概述 在 Android内存泄漏终极解决篇（上）中我们介绍了如何检查一个App是否存在内存泄漏的问题，本篇将总结典型的内存泄漏的代码，并给出对应的解决方案。内存泄漏的主要问题可以分为以下几种类型： 静态变量引起的内存泄漏 非静态内部类引起的内存泄漏 资源未关闭引起的内存泄漏 二、静态变量引起的内存泄漏 在java中静态变量的生命周期是在类加载时开始，类卸载时结束。换句话说，在android中其生命周期是在进程启动时开始，进程死亡时结束。所以在程序的运行期间，如果进程没有被杀死，静态变量就会一直存在，不会
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
