信任一步步走过来的Android从业者，每个人都会遇到OOM的状况。怎么防止和防备OOM的呈现，关于每一个程序员来说确实是一门必不可少的才干。今日咱们就谈谈在Android平台下内存的办理之道，开端今日的主题之前，先再次回忆两个概念。
内存走漏：目标在内存heap堆中中分配的空间，当不再运用或没有引证指向的状况下，仍不能被GC正常收回的状况。大都呈现在不合理的编码状况下，比方在Activity中注册了一个播送接收器，可是在页面封闭的时分进行unRegister，就会呈现内存溢出的现象。通常状况下，许多的内存走漏会形成OOM。
OOM：即OutOfMemoery，望文生义便是指内存溢出了。内存溢出是指APP向体系恳求超越最大阀值的内存恳求，体系不会再分配剩余的空间，就会形成OOM error。在咱们Android平台下，大都状况是呈现在图片不妥处理加载的时分。
内存办理之道嘛，无非便是先了解并找出内存走漏的原因，再依据这些反式去合理的编码，去防备然后防止内存开支过大的景象。学习怎么合理的办理内存，最好先了解内存分配的机制和原理。只要深层次的了解了内部的原理，才干真实防止OOM的产生。可是本文就不介绍Jvm/Davilk内存分配的机制了，如有爱好，请检查前史音讯，曾经做过题为《JVM运转时数据区域剖析》的共享。
Android APP的所能恳求的最大内存巨细是多少，有人说是16MB，有人又说是24MB。这种工作，仍是亲自用自己的手机测验下比较靠谱。测验办法也比较简略，Java中有个Runtime类，首要用作APP与运转环境交互，APP并不会为咱们创立Runtime的实例，可是Java为咱们供给了单例获取的办法Runtime.getRuntime()。经过maxMemory()办法获取体系可为APP分配的最大内存，totalMemory()获取APP当时所分配的内存heap空间巨细。我手上有两部手机，一部Oppo find7，运转Color OS，实测最大内存分配为192MB;一部天语v9，运转小米体系，实测最大内存分配为100MB。这下看出点端倪了吧，因为Android是开源体系，不同的手机厂商其实是具有修正这部分权限才干的，所以就形成了不同品牌和不同体系的手机，关于APP的内存支撑也是不相同的，和IOS的长久100MB是不同的。一般来说，手机内存的装备越高，厂商也会调大手机支撑的内存最大阀值，特别是现在旗舰机满天发布的状况下。可是开发者为了考虑开宣布的APP的内存兼容性，无法保证APP运转在何种手机上，只能从编码视点来优化内存了。
下面咱们逐条来剖析Android内存优化的要害点。
1、万恶的static
static是个好东西，声明赋值调用便是那么的简略便利，可是随同而来的还有功能问题。因为static声明变量的生命周期其实是和APP的生命周期相同的，有点相似与Application。假如许多的运用的话，就会占有内存空间不开释，集腋成裘也会形成内存的不断开支，直至挂掉。static的合理运用一般用来润饰根本数据类型或许轻量级目标，尽量防止修正调集或许大目标，常用作润饰大局装备项、东西类办法、内部类。
2、无关引证
许多状况下，咱们需求用到传递引证，可是咱们无法保证引证传递出去后能否及时的收回。比方比较有代表性的Context走漏，许多状况下当Activity 结束掉后，因为仍被其他的目标指向导致一向迟迟不能收回，这就形成了内存走漏。这时能够考虑第三条主张。
3、善用SoftReference/WeakReference/LruCache
Java、Android中有没有这样一种机制呢，当内存吃紧或许GC扫过的状况下，就能及时把一些内存占用给开释掉，然后分配给需求分配的当地。答案是必定的，java为咱们供给了两个处理方案。假如对内存的开支比较重视的APP，能够考虑运用WeakReference，当GC收回扫过这块内存区域时就会收回;假如不是那么重视的话，能够运用SoftReference，它会在内存恳求缺乏的状况下自动开释，相同也能处理OOM问题。一起Android自3.0今后也推出了LruCache类，运用LRU算法就开释内存，相同的能处理OOM，假如兼容3.0一下的版别，请导入v4包。关于第二条的无关引证的问题，咱们传参能够考虑运用WeakReference包装一下。
4、慎重handler
在处理异步操作的时分，handler + thread是个不错的挑选。可是信任在运用handler的时分，我们都会遇到正告的景象，这个便是lint为开发者的提示。handler运转于UI线程，不断处理来自MessageQueue的音讯，假如handler还有音讯需求处理可是Activity页面现已结束的状况下，Activity的引证其实并不会被收回，这就形成了内存走漏。处理方案，一是在Activity的onDestroy办法中调用
handler.removeCallbacksAndMessages(null);撤销一切的音讯的处理，包含待处理的音讯;二是声明handler的内部类为static。
5、Bitmap终极杀手
Bitmap的不妥处理极或许形成OOM，绝大大都状况都是因这个原因呈现的。Bitamp位图是Android中名副其实的胖小子，所以在操作的时分当然是非常的当心了。因为Dalivk并不会自动的去收回，需求开发者在Bitmap不被运用的时分recycle掉。运用的过程中，及时开释是非常重要的。一起假如需求答应，也能够去BItmap进行必定的缩放，经过BitmapFactory.Options的inSampleSize特点进行操控。假如只是只想取得Bitmap的特点，其实并不需求依据BItmap的像素去分配内存，只需在解析读取Bmp的时分运用BitmapFactory.Options的inJustDecodeBounds特点。最终主张我们在加载网络图片的时分，运用软引证或许弱引证并进行本地缓存，引荐运用android-universal-imageloader或许xUtils，牛人出品，必属精品。前几天在讲《自定义控件(三) 承继控件》的时分，也收拾一个，我们能够去Github下载看看。
6、Cursor及时封闭
在查询SQLite数据库时，会回来一个Cursor，当查询结束后，及时封闭，这样就能够把查询的成果集及时给收回掉。
7、页面布景和图片加载
在布局和代码中设置布景和图片的时分，假如是纯色，尽量运用color;假如是规矩图形，尽量运用shape画图;假如略微复杂点，能够运用9patch图;假如不能运用9patch的状况下，针对几种干流分辨率的机型进行切图。
8、ListView和GridView的item缓存
关于移动设备，特别硬件良莠不齐的android生态，页面的制作其实是很耗时的，findViewById也是蛮慢的。所以不重用View，在有列表的时分就尤为明显了，常常会呈现滑动很卡的现象。详细参照前史文章《说说ViewHolder的另一种写法》
