内存泄漏定义（memory leak）：一个不再被程序使用的对象或变量还在内存中占有存储空间。
回收废弃常量与回收 Java 堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串”abc”已经进入了常量池中，但是当前系统没有任何一个 String 对象是叫做”abc”的，也没有其他地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个”abc”常量就会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。
内存管理的目的就是让我们在开发过程中有效避免我们的应用程序出现内存泄露的问题。内存泄露相信大家都不陌生，我们可以这样理解：「没有用的对象无法回收的现象就是内存泄露」。
内存泄漏是指无用对象（不再使用的对象）持续占有内存或无用对象的内存得不到及时释放，从而造成内存空间的浪费称为内存泄漏。内存泄露有时不严重且不易察觉，这样开发者就不知道存在内存泄露，但有时也会很严重，会提示你Out of memory。 Android中常见的内存泄露如下： 1.集合类泄漏 集合类如果仅仅有添加元素的方法，而没有相应的删除机制，导致内存被占用。如果这个集合类是全局性的变量 (比如类中的静态属性，全局性的 map 等即有静态引用或 final 一直指向它)，那么没有相应的删除机制，很可能导致集合所占用的内存只增不减。 2.单例造成的内存泄漏 由于单例的静态特性使得其生命周期跟应用的生命周期一样长，所以如果使用不恰当的话，很容易造成内存泄漏。比如下面一个典型的例子
最近在群里看到有人在讨论有关内存分析的话题，比较好奇，Enmmm，也就有了今天这篇博文。
1. Application的生命周期 Application和Activity,Service一样,是Android框架的一个系统组件，当Android程序启动时系统会创建一Application 对象，用来存储系统的一些信息。 Application对象的生命周期是整个程序中最长的，它的生命周期就等于这个程序的生命周期。因为它是全局的单例 的，所以在不同的Activity,Service中获得的Application对象都是同一个对象。所以可以通过Application来进行一些，数据传递，数据共享,数据缓存等操作。 在Application中如果保存对象有导致内存泄漏的风险。并且在onCreate中执行耗时操作会直接影响程序的启动时间。 onCreate（） 程序创建的时候执行。 onTerminate（）程序终止的时候执行,当程序是被内核终止以便为其他应用程序释放资源，不会被调用。 onLowMemory（）低内存的时候执行。可以用来释放一些不必要的资源来应对后台程序已经终止，前台应用程序内存还不够时的情况。 onConfigurationChanged（Configuration newConfig)配置改变时触发这个方法。 onTrimMemory（int level）程序在进行内存清理时执行。
该文章是一个系列文章，是本人在Android开发的漫漫长途上的一点感想和记录，我会尽量按照先易后难的顺序进行编写该系列。该系列引用了《Android开发艺术探索》以及《深入理解Android 卷Ⅰ，Ⅱ，Ⅲ》中的相关知识，另外也借鉴了其他的优质博客，在此向各位大神表示感谢，膜拜！！！另外，本系列文章知识可能需要有一定Android开发基础和项目经验的同学才能更好理解，也就是说该系列文章面向的是Android中高级开发工程师。
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. 巧用对象引用类型
内存管理的目的就是让我们在开发中怎么有效的避免我们的应用出现内存泄漏的问题。内存泄漏大家都不陌生了，简单粗俗的讲，就是该被释放的对象没有释放，一直被某个或某些实例所持有却不再被使用导致 GC 不能回收。最近自己阅读了大量相关的文档资料，打算做个 总结 沉淀下来跟大家一起分享和学习，也给自己一个警示，以后 coding 时怎么避免这些情况，提高应用的体验和质量。
在 GC 的过程中，其它在工作的线程会暂停，包括负责绘制的 UI 线程，并且在不同区域的内存释放速度也有一定的差异，但不管在哪个区域，都要到这次 GC 内存回收完成后，才会继续执行原来的线程。
内存泄漏是一个隐形炸弹，其本身并不会造成程序异常，但是随着量的增长会导致其他各种并发症：OOM，UI 卡顿等。
在正方形寄存器中，我们在位图缓存上绘制客户的签名。这个位图是设备屏幕的大小，我们在创建它时发生了大量的内存不足（OOM）崩溃。
内存优化目的就是让我们在开发中怎么有效的避免我们的应用出现内存泄漏的问题。内存泄漏大家都不陌生了，简单粗俗的讲，就是该被释放的对象没有释放，一直被某个或某些实例所持有却不再被使用导致 GC 不能回收。既然说到内存泄漏和优化，就不得不先简单了解一下内存分配策略，然后再举常见泄漏例子和解决方法，最后做一下总结，这样更直观全面了解Android内存方面处理。
LeakCanary想来也是我们的一个老朋友了，但是它是如何做到对我们的App进行内存泄漏分析的呢？这也是我们今天要去研究的主题了。
一、概述 在 Android内存泄漏终极解决篇（上）中我们介绍了如何检查一个App是否存在内存泄漏的问题，本篇将总结典型的内存泄漏的代码，并给出对应的解决方案。内存泄漏的主要问题可以分为以下几种类型： 静态变量引起的内存泄漏 非静态内部类引起的内存泄漏 资源未关闭引起的内存泄漏 二、静态变量引起的内存泄漏 在java中静态变量的生命周期是在类加载时开始，类卸载时结束。换句话说，在android中其生命周期是在进程启动时开始，进程死亡时结束。所以在程序的运行期间，如果进程没有被杀死，静态变量就会一直存在，不会
在Android开发中最让人们头疼的就是内存泄漏了，今天来介绍一个查看内存是否泄漏的工具LeakCanary，并通过研究源码明白它是如何分析和查找存在泄漏信息的 首先送上LeakCanary文档链接:[LeakCanary中文使用说明](https://www.liaohuqiu.net/cn/posts/leak-canary-read-me/) Part1. 知识回顾 常用工具 1. Mat 2. LeakCanary(Square） 原理
强引用：类似“Object obj = new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
某公司技术人员针对企业应用系统12月10日内存溢出事件进行了广泛的技术探讨，并得到了一些建设性的建议和结论。
前言 内存泄漏向来都是内存优化的重点，它如同幽灵一般存于我们的应用当中，有时它不会现身，但一旦现身就会让你头疼不已。因此，如何避免、发现和解决内存泄漏就变得尤为重要，这一篇我们先来学习如何避免内存泄漏
对于内存泄漏，在Android中如果不注意的话，还是很容易出现的，尤其是在Activity中，比较容易出现，下面我就说下自己是如何查找内存泄露的。
继介绍稳定性ANR类故障和Crash/Tombstone类故障后，本章将介绍第三大类故障资源泄露及其典型场景、分析定位和解决方法。
作为Android开发人员，我们或多或少都听说过内存泄漏。那么何为内存泄漏，Android中的内存泄漏又是什么样子的呢，本文将简单概括的进行一些总结。
Activity承载了应用和用户交互的任务，在Activity中有大量的资源引用和上下文Context这样占用内存较大的资源对象，因为Activity一旦因为外部变量的持有，就会造成比较严重的内存泄漏。造成Activity内存泄漏的场景有以下：
在日常开发中，不可避免的会遇到内存泄漏的问题，从而导致App的内存使用紧张，严重的情况还会导致App的卡顿甚至是奔溃，所以需要开发人员解决这些内存泄漏的问题。
1.概述 如果使用MAT来分析内存问题，会有一些难度，并且效率也不是很高，对于一个内存泄漏问题，可能要进行多次排查和对比。 为了能够简单迅速的发现内存泄漏，Square公司基于MAT开源了LeakCa
内存泄漏（Memory Leak)：是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。
链接：https://juejin.im/post/5e72b2d151882549236f9cb8
关于内存泄漏，Android 开发的小伙伴应该都再熟悉不过了，比如最常见的静态类间接持有了某个 Activity 对象，又比如某个组件库的订阅在页面销毁时没有及时清理等等，这些情况下多数时都会造成内存泄漏，从而对我们App的 流畅度 造成影响，更有甚者造成了 OOM 的情况。
在Java中，内存的分配是由程序完成的，而内存的释放是由垃圾收集器(Garbage Collection，GC)完成的，程序员不需要通过调用函数来释放内存，但也随之带来了内存泄漏的可能，上篇博客，我介绍了 Android性能优化系列之布局优化，本篇博客，我将介绍内存优化的相关知识。
Context在Android系统中的地位很重要，它几乎无所不能，但它也不是你想用就能随便用的，谨防使用不当引起的内存问题。我们总会忽略掉一些比较细节的东西，自己想下Context的作用，你还记得多少？
如HashMap、LinkedList等等。如果这些容器为静态的，那么它们的生命周期与程序一致，则容器中的对象在程序结束之前将不能被释放，从而造成内存泄漏。简单而言，长生命周期的对象持有短生命周期对象的引用，尽管短生命周期的对象不再使用，但是因为长生命周期对象持有它的引用而导致不能被回收。
这篇文章的内容是我回顾和再学习 Android 内存优化的过程中整理出来的，整理的目的是让我自己对 Android 内存优化相关知识的认识更全面一些，分享的目的是希望大家也能从这些知识中得到一些启发。
一、概述 Android内存的文章详见：http://blog.csdn.net/linghu_java/article/details/39480761 在Android的开发中，经常听到“内存泄漏”这个词。“内存泄漏”就是一个对象已经不需要再使用了，但是因为其它的对象持有该对象的引用，导致它的内存不能被回收。“内存泄漏”的慢慢积累，最终会导致OOM的发生，千里之堤，毁于蚁穴。所以在写代码的过程中，应该要注意规避会导致“内存泄漏”的代码写法，提高软件的健壮性。 本文将从发现问题、解决问题、总结问题的三个
可达性分析算法来判断对象是否是不再使用的对象，本质都是判断一个对象是否还被引用。那么对于这种情况下，由于代码的实现不同就会出现很多种内存泄漏问题（让JVM误以为此对象还在引用中，无法回收，造成内存泄漏）。
存在问题： 不少人认为JAVA程序，因为有垃圾回收机制，应该没有内存泄露。 解决方案： 其实如果我们一个程序中，已经不再使用某个对象，但是因为仍然有引用指向它，垃圾回收器就无法回收它，当然该对象占用的内存就无法被使用，这就造成了内存泄露。如果我们的java运行很久,而这种内存泄露不断的发生，最后就没内存可用了。当然java的，内存泄漏和C/C++是不一样的。如果java程序完全结束后，它所有的对象就都不可达了，系统就可以对他们进行垃圾回收，它的内存泄露仅仅限于它本身，而不会影响整个系统的。C/C++的内存
我们经常看到的说法是，安卓内存泄漏是因为长生命周期的对象持有了短生命周期的引用导致本应该本回收的内存无法回收 但是什么是长生命周期呢，正常我们知道单例、Application、static是长生命周期，但是为什么Handler也会造成内存泄漏，Handler和这三种情况没有什么关系
a.建造者模式： 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 使用场景比如最常见的AlertDialog,拿我们开发过程中举例，比如Camera开发过程中，可能需要设置一个初始化的相机配置，设置摄像头方向，闪光灯开闭，成像质量等等，这种场景下就可以使用建造者模式
LeakCanary是Android面试中备受瞩目的一环，各大厂商如腾讯Matrix和快手Koom都自研内存泄漏检测框架，其原理分析也常被引述于帮助文档中。本文旨在抛却浮躁情绪，深入探究该框架的思想。
什么是OOM？OOM，全称“Out Of Memory”，翻译成中文就是“内存用完了”，来源于java.lang.OutOfMemoryError。看下关于的官方说明：Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector. 意思就是说，当JVM因为没有足够的内存来为对象分配空间并且垃圾回收器也已经没有空间可回收时，就会抛出这个error（注：非exception，因为这个问题已经严重到不足以被应用处理）。
一直以来以为只有C/C++才存在内存泄漏的问题，没想到拥有内存回收机制的Java也可能出现内存泄漏。C/C++存在指针的概念，程序中需要使用指针变量时，就从内存中开辟一块区域，并把该区域的首地址赋值给一个指针，这样程序才可操作该指针指向的内存区域。因为C/C++设计上的原因，手工分配的内存，也要手工来释放，如malloc/free是C中分配/释放内存的运算符，而new/delete则是C++中新增的分配/释放内存的运算符。 Java设计之初就是能够自动回收内存，可是有些时候因为某些因素，内存回收机制并不会都奏效。情况之一是调用了非java接口，比如调用了jni接口，jni中C/C++的内存就要手工回收；情况之二是调用了外部服务，使用完毕就得手工通知外部服务去回收；情况之三是异步处理，实时的内存回收显然顾不上异步处理的任务。
LeakCanary内部用到了Refercence及ReferenceQueue来实现对对象是否被回收的监听。这是LeakCanary的核心逻辑，因此在讲解LeakCanary之前，我们先来简单了解一下Refercence及ReferenceQueue。
当android程序启动时系统会创建一个 application对象，用来存储系统的一些信息。通常我们是不需要指定一个Application的，这时系统会自动帮我们创建，如果需要创建自己 的Application，也很简单创建一个类继承 Application并在manifest的application标签中进行注册(只需要给Application标签增加个name属性把自己的 Application的名字定入即可)。 android系统会为每个程序运行时创建一个Application类的对象且仅创建
对于开发老手，这个问题想必已经深入你的心；若是一名新手或者一直对内存泄漏这个东西模模糊糊的工程师，你的答案可能让面试官并不满意，这里将从底到上对内存泄漏的原因、排查方法和一些经验为你做一次完整的解剖。
作为Android开发者，不知道你有没有思考过这个问题，Activity可以new吗？Android的应用程序开发采用JAVA语言，Activity本质上也是一个对象，那上面的写法有什么问题呢？估计很多人说不清道不明。Android程序不像Java程序一样，随便创建一个类，写个main()方法就能运行，Android应用模型是基于组件的应用设计模式，组件的运行要有一个完整的Android工程环境，在这个环境下，Activity、Service等系统组件才能够正常工作，而这些组件并不能采用普通的Java对象创建方式，new一下就能创建实例了，而是要有它们各自的上下文环境，也就是我们这里讨论的Context。可以这样讲，Context是维持Android程序中各组件能够正常工作的一个核心功能类。
面试造火箭，工作拧螺丝，虽然我只想拧螺丝，可是我需要用造火箭的技术去寻找拧螺丝的工作，如何能在面试过程中让自己处于不败的地步呢，刷题是一个比较好的捷径，今天就汇总了一些比较经典的面试题进行了汇总，分享给大家。
OOM，全称“Out Of Memory”，翻译成中文就是“内存用完了”，来源于java.lang.OutOfMemoryError。看下关于的官方说明：Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector. 意思就是说，当JVM因为没有足够的内存来为对象分配空间并且垃圾回收器也已经没有空间可回收时，就会抛出这个error（注：非exception，因为这个问题已经严重到不足以被应用处理）。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
