Android之内存管理-内存监测-内存优化
1.1 Dalvik
Dalvik是程序的虚拟机，是Android中程序的运行基础。其指令集基于寄存器架构，执行其特有的文件格式&&dex字节码来完成对象生命周期管理、堆栈管理、线程管理、安全异常管理、垃圾回收等重要功能。
Dalvik虚拟机的内存大体上可以分为 Java Object Heap、Bitmap Memory和Native Heap三种。
Java Object Heap：用于分配对象
Bitmap Memory：用来处理图像，&Android 3.0, 归到Object Heap中
Native Heap: malloc分配，受限制
1.2 查看单个进程最大内存限制
Android设备出厂以后，java虚拟机对单个应用的最大内存分配就确定下来了，超出这个值就会OOM。
这个属性值是定义在/system/build.prop文件中的
dalvik.vm.heapstartsize=8m //它表示堆分配的初始大小，
它会影响到整个系统对RAM的使用程度，和第一次使用应用时的流畅程度。它值越小，系统ram消耗越慢，但一些较大应用一开始不够用，需要调用gc和堆调整策略，导致应用反应较慢。它值越大，这个值越大系统ram消耗越快，但是应用更流畅。
dalvik.vm.heapgrowthlimit=64m // 单个应用可用最大内存
主要对应的是这个值,它表示单个进程内存被限定在64m,即程序运行过程中实际只能使用64m内存，超出就会报OOM。（仅仅针对dalvik堆，不包括native堆）
dalvik.vm.heapsize=384m //heapsize参数表示单个进程可用的最大内存，
但如果存在heapgrowthlimit参数，则以heapgrowthlimit为准.
heapsize表示不受控情况下的极限堆，表示单个虚拟机或单个进程可用的最大内存。而android上的应用是带有独立虚拟机的，也就是每开一个应用就会打开一个独立的虚拟机（这样设计就会在单个程序崩溃的情况下不会导致整个系统的崩溃）。
注意：在设置了heapgrowthlimit的情况下，单个进程可用最大内存为heapgrowthlimit值。在android开发中，如果要使用大堆，需要在manifest中指定android:largeHeap为true，这样dvm heap最大可达heapsize。
Android不同设备单个进程可用内存是不一样的，可以查看/system/build.prop文件。
# This is a high density device with more memory, so larger vm heaps for it.
dalvik.vm.heapsize=24m
上面heapsize参数表示单个进程可用的最大内存，单如果存在如下参数：
dalvik.vm.heapgrowthlimit=16m
largeheaplimit参数表示单个进程内存被限定在16m,即程序运行过程中实际只能使用16m内存，不过有一个办法可以解决，编辑AndroidManifest.xml中的Application节点，增加属性largeheap=&true&参数.
// 应用程序最大可用内存
dalvik.vm.heapsize的值我的手机是256M
long maxMemory = ((int) Runtime.getRuntime().maxMemory())/;
//应用程序已获得内存
dalvik.vm.heapgrowthlimit的值我的手机是25M
long totalMemory = ((int) Runtime.getRuntime().totalMemory())/;
//应用程序已获得内存中未使用内存
long freeMemory = ((int) Runtime.getRuntime().freeMemory())/;
System.out.println(&---& maxMemory=&+maxMemory+&M,totalMemory=&+totalMemory+&M,freeMemory=&+freeMemory+&M&);
Toast.makeText(MainActivity.this, &---& maxMemory=&+maxMemory+&M,totalMemory=&+totalMemory+&M,freeMemory=&+freeMemory+&M&, Toast.LENGTH_SHORT).show();
JAVA的内存管理
大家都知道，android应用层是由java开发的，android的davlik虚拟机与jvm也类似，只不过它是基于寄存器的。因此要了解android的内存管理就必须得了解java的内存分配和垃圾回收机制。
在java中，是通过new关键字来为对象分配内存的，而内存的释放是由垃圾收集器（GC）来回收的，工程师在开发的过程中，不需要显式的去管理内存。但是这样有可能在不知不觉中就会浪费了很多内存，最终导致java虚拟机花费很多时间去进行垃圾回收，更严重的是造成JVM的OOM。因此，java工程师还是有必要了解JAVA的内存分配和垃圾回收机制。
1，内存结构
上面这张图是JVM的结构图，它主要四个部分组成：Class Loader子系统和执行引擎，运行时方法区和本地方法区，我们主要来看下RUNTIME DATA AREA区，也就是我们常说的JVM内存。从图中可以看出，RUNTIMEDATA AREA区主要由5个部分组成：
Method Area:被装载的class的元信息存储在Method Area中，它是线程共享的
Heap(堆)：一个java虚拟机实例中只存在一个堆空间，存放一些对象信息，它是线程共享的
Java栈： java虚拟机直接对java栈进行两种操作，以帧为单位的压栈和出栈（非线程共享）
程序计数器（非线程共享）
本地方法栈（非线程共享）
2，JVM的垃圾回收（GC）
JVM的垃圾原理是这样的，它把对象分为年轻代（Young）、年老代（Tenured）、持久代（Perm），对不同生命周期的对象使用不同的垃圾回收算法。
年轻代(Young)
年轻代分为三个区，一个eden区，两个Survivor区。程序中生成的大部分新的对象都在Eden区中，当Eden区满时，还存活的对象将被复制到其中一个Survivor区，当此Survivor区的对象占用空间满了时，此区存活的对象又被复制到另外一个Survivor区，当这个Survivor区也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制到年老代。
年老代（Tenured）
年老代存放的是上面年轻代复制过来的对象，也就是在年轻代中还存活的对象，并且区满了复制过来的。一般来说，年老代中的对象生命周期都比较长。
持久代（Perm）
用于存放静态的类和方法，持久代对垃圾回收没有显著的影响。
Android中内存泄露监测
在了解了JVM的内存管理后，我们再回过头来看看，在android中应该怎样来监测内存，从而看在应用中是否存在内存分配和垃圾回收问题而造成内存泄露情况。
在android中，有一个相对来说还不错的工具，可以用来监测内存是否存在泄露情况：DDMS&Heap
选择DDMS视图，并打开Devices视图和Heap视图
点击选择要监控的进程，比如：上图中我选择的是system_process
选中Devices视图界面上的&update heap& 图标
点击Heap视图中的&Cause GC& 按钮（相当于向虚拟机发送了一次GC请求的操作）
在Heap视图中选择想要监控的Type，一般我们会观察dataobject的 total size的变化，正常情况下total size的值会稳定在一个有限的范围内，也就说程序中的代码良好，没有造成程序中的对象不被回收的情况。如果代码中存在没有释放对象引用的情况，那么data object的total size在每次GC之后都不会有明显的回落，随着操作次数的增加而total size也在不断的增加。（说明：选择好data object后，不断的操作应用，这样才可以看出total size的变化）。如果totalsize确实是在不断增加而没有回落，说明程序中有没有被释放的资源引用。那么我们应该怎么来定位呢？
Android中内存泄露定位
Mat(memory analyzer tools)是我们常用的用来定位内存泄露的工具，如果你使用ADT，并且安装了MAT的eclipse插件，你需要做的是进入DDMS视图的Devices视图
点击&dump HPROF file&按钮，然后使用MAT分析下载下来的文件。
关于MAT的使用可以参考：http://www.blogjava.net/rosen/archive//323522.html
这位兄弟写的比较详细。
转自：http://blog.csdn.net/xieqibao/article/details/6707519
android的内存优化看另一篇文章：
3、为什么会内存泄露(Memory Leak)?
android通过android虚拟机来管理内存，程序员只管申请内存创建对象，创建完不再需要关心怎么释放对象内存，一切由虚拟机帮你搞定，然而虚拟机回收对象是有条件的。这里简单叙述下java内存管理机制，java虚拟机维护着一张当前对象关系的object tree，当GC发生时，虚拟机会从GC Roots 开始去扫描当前的对象树，发现通过任何reference chain(引用链)无法访问某个对象的时候，该对象即被回收。名词GC Roots正是分析这一过程的起点，例如JVM自己确保了对象的可到达性(那么JVM就是GC Roots)，所以GC Roots就是这样在内存中保持对象可到达性的，一旦不可到达，即被回收。通常GC Roots是一个在current thread(当前线程)的call stack(调用栈)上的对象（例如方法参数和局部变量），或者是线程自身或者是system class loader(系统类加载器)加载的类以及native code(本地代码)保留的活动对象。所以GC Roots是分析对象为何还存活于内存中的利器。知道了什么样的对象GC才会回收后，再来学习下对象引用都包含哪些吧。
Java中包含4种对象引用：
强引用： 通常我们编写的代码都是Strong Ref，eg ：Person person = new Person(&sunny&);不管系统资源有多紧张，强引用的对象都绝对不会被回收，即使他以后不再用到。
软引用：只要有足够的内存，就一直保持对象。一般可用来实现缓存，通过java.lang.r.efSoftReference类实现。内存非常紧张的时候会被回收，其他时候不会被回收，所以在使用之前需要判空，从而判断当前时候已经被回收了。
弱引用：通过WeakReference类实现，eg : WeakReference p = new WeakReference(new Person(&Rain&));不管内存是否足够，系统垃圾回收时必定会回收。
虚引用：不能单独使用，主要是用于追踪对象被垃圾回收的状态。通过PhantomReference类和引用队列ReferenceQueue类联合使用实现。
4、为什么会发生OOM(Out Of Memory)？
OOM：即OutOfMemoery，顾名思义就是指内存溢出了。之前我们知道Android的应用程序所能申请的最大内存都是有限的，OOM是指APP向系统申请内存的请求超过了应用所能有的最大阀值的内存，系统无法再分配多余的空间，就会造成OOM error。在Android平台下，除了之前所说的持续发生了内存泄漏(Memory Leak)，累积到一定程度导致OOM的情况以外，也有一次性申请很多内存，比如说一次创建大的数组或者是载入大的文件如图片的时候。实际中很多情况就是出现在图片不当处理加载的时候。
5、常见的MemoryLeak分析
后来看到了更多的MemoryLeak相关的知识，有了更多的实践经验，事情的源头是我的Sate210 （S5pv210） 板子，我用三星代理商给的android2.3.4 和google下的android2.3.7 源码编译出来的system.img烧进去，发现启动很慢很慢，运行起来也很慢很慢。
让我怀疑是否是我没用起来我的Sate210 的512M DDR2 内存，因为我本来Sate210 的光盘system.img 自带镜像运行起来是速度很快的，非常快。检查了一番，虽然uboot我更新了支持ext4的新的uboot，但是应该是512M 内存都跑起来了的。后来用cat&&/proc/meminfo&&命令发现，原来是Sate210 的android源码是经过优化的，网上下的android源码包占用非常大的内存，没有1G byte 以上的内存根本用不了的。跑起来剩余8MB内存，你说能不慢吗？
来吧，现在来玩一下如何优化android内存吧。O(∩_∩)O~。
如果对linux，Android，wince 等嵌入式底层有兴趣的，请加这个QQ群吧，群号：
在线时间130 小时
威望3732分
芯币3809枚
TA的帖子TA的资源
五彩晶圆（中级）, 积分 3732, 距离下一级还需 2268 积分
五彩晶圆（中级）, 积分 3732, 距离下一级还需 2268 积分
安卓系统不用在意剩余内存的大小，其实很多人都是把使用其他系统的习惯带过来来了。android大多应用没有退出的设计其实是有道理的，这和系统对进程的调度机制有关系。如果你知道java，就能更清楚这机制了。其实和java的垃圾回收机制类似，系统有一个规则来回收内存。进行内存调度有个阀值，只有低于这个值系统才会按一个列表来关闭用户不需要的东西。当然这个值默认设置得很小，所以你会看到内存老在很少的数值徘徊。但事实上他并不影响速度。相反加快了下次启动应用的速度。这本来就是android标榜的优势之一，如果人为去关闭进程，没有太大必要。特别是使用自动关进程的软件。
　　到这里有人会说了，那为什么内存少的时候运行大型程序会慢呢？其实很简单，在内存剩余不多时打开大型程序，会触发系统自身的调进程调度策略，这是十分消耗系统资源的操作，特别是在一个程序频繁向系统申请内存的时候。这种情况下系统并不会关闭所有打开的进程，而是选择性关闭，频繁的调度自然会拖慢系统。所以，论坛上有个更改内存阀值的程序可以有一定改善。但改动也可能带来一些问题，取决于值的设定。
　 那么，进程管理软件有无必要呢？有的。就是在运行大型程序之前，你可以手动关闭一些进程释放内存，可以显著的提高运行速度。但一些小程序，完全可交由系统自己管理。
　 那么，如果不关程序是不是会更耗电。 说说android后台的原理，你就明白了。android的应用在被切换到后台时，它其实已经被暂停了，并不会消耗cpu资源，只保留了运行状态。所以为什么有的程序切出去重进会到主界面。但是，一个程序如果想要在后台处理些东西，如音乐播放，它就会开启一个服务。服务可在后台持续运行，所以在后台耗电的也只有带服务的应用了。这个在进程管理软件里能看到，标签是service。至于广播什么的我就不涉及了。所以没有带服务的应用在后台是完全不耗电的，没有必要关闭。这种设计本来就是一个非常好的设计，下次启动程序时，会更快，因为不需要读取界面资源，何必要关掉他们抹杀这个android的优点呢。
　　还有一个，为什么android一个应用看起来那么耗内存。大家知道，android上的应用是java，当然需要虚拟机，而android上的应用是带有独立虚拟机的，也就是每开一个应用就会打开一个独立的虚拟机。这样设计的原因是可以避免虚拟机崩溃导致整个系统崩溃，但代价就是需要更多内存。
　　以上这些设计确保了android的稳定性，正常情况下最多单个程序崩溃，但整个系统不会崩溃，也永远没有内存不足的提示出现。大家可能是被 windows毒害得太深了，总想保留更多的内存，但实际上这并不一定会提升速度，相反却丧失了程序启动快的这一系统特色，很没必要。
——这个说法是内存比较大的时候才好的，要不然，还没开其他应用，就已经几个M的内存剩余了，想跑的快都难。所以android 内存大跑的快，一旦内存小，O(∩_∩)O哈哈哈~卡死人。
如果对linux，Android，wince 等嵌入式底层有兴趣的，请加这个QQ群吧，群号：
在线时间130 小时
威望3732分
芯币3809枚
TA的帖子TA的资源
五彩晶圆（中级）, 积分 3732, 距离下一级还需 2268 积分
五彩晶圆（中级）, 积分 3732, 距离下一级还需 2268 积分
这个也是有点帮助的解释。
如果对linux，Android，wince 等嵌入式底层有兴趣的，请加这个QQ群吧，群号：
在线时间130 小时
威望3732分
芯币3809枚
TA的帖子TA的资源
五彩晶圆（中级）, 积分 3732, 距离下一级还需 2268 积分
五彩晶圆（中级）, 积分 3732, 距离下一级还需 2268 积分
android不同设备单个进程可用内存是不一样的，可以查看/system/build.prop文件。# This is a high density device with more memory, so larger vm heaps for it.
dalvik.vm.heapsize=24m上面heapsize参数表示单个进程可用的最大内存，单如果存在如下参数：dalvik.vm.heapgrowthlimit=16mlargeheaplimit参数表示单个进程内存被限定在16m,即程序运行过程中实际只能使用16m内存，不过有一个办法可以解决，编辑AndroidManifest.xml中的Application节点，增加属性largeheap=&true&参数.
如果对linux，Android，wince 等嵌入式底层有兴趣的，请加这个QQ群吧，群号：
在线时间130 小时
威望3732分
芯币3809枚
TA的帖子TA的资源
五彩晶圆（中级）, 积分 3732, 距离下一级还需 2268 积分
五彩晶圆（中级）, 积分 3732, 距离下一级还需 2268 积分
在 system/build.prop&&里参看。
dalvik.vm.heapsize
这个我感觉仅仅是一个小的方面。这个限制就是一旦超过这个内存，这个应用程序就不执行了，但是我还没运行太多程序，这个可用内存已经很少了，真是........太挫了。
如果对linux，Android，wince 等嵌入式底层有兴趣的，请加这个QQ群吧，群号：
在线时间130 小时
威望3732分
芯币3809枚
TA的帖子TA的资源
五彩晶圆（中级）, 积分 3732, 距离下一级还需 2268 积分
五彩晶圆（中级）, 积分 3732, 距离下一级还需 2268 积分
Android虚拟机(DVM)内存分配——内存溢出问题
大家都知道Android的上层应用是基于 Dalvik Virtual Machine的。Dalvik VM的特点是基于寄存器，相比SUN的JVM（基于堆栈，没有寄存器）来说，理论上完成同样的功能需要的指令条数少，但是指令集复杂。到了Android2.2，Dalvik终于实现了JIT（Just In Time）功能，前进了一大步。
近期我们遇到OutOfMemory的错误，通常是堆内存溢出。网上有些帖子说可以通过函数设置应用的HEAP SIZE来解决这个问题，其实是不对的。
VMRuntime.getRuntime().setMinimumHeapSize(NewSize);
堆（HEAP）是VM中占用内存最多的部分，通常是动态分配的。堆的大小不是一成不变的，通常有一个分配机制来控制它的大小。比如初始的HEAP是4M大，当4M的空间被占用超过75%的时候，重新分配堆为8M大；当8M被占用超过75%，分配堆为16M大。倒过来，当16M的堆利用不足30%的时候，缩减它的大小为8M大。重新设置堆的大小，尤其是压缩，一般会涉及到内存的拷贝，所以变更堆的大小对效率有不良影响。
上面只是个例子，不过可以看到三个参数：max heap size, min heap size, heap utilization（堆利用率）。
Max Heap Size，是堆内存的上限值，Android的缺省值是16M（某些机型是24M），对于普通应用这是不能改的。函数setMinimumHeapSize其实只是改变了堆的下限值，它可以防止过于频繁的堆内存分配，当设置最小堆内存大小超过上限值时仍然采用堆的上限值（16M），对于内存不足没什么作用。
setTargetHeapUtilization(float newTarget) 可以设定内存利用率的百分比，当实际的利用率偏离这个百分比的时候，虚拟机会在GC的时候调整堆内存大小，让实际占用率向个百分比靠拢。
//程序onCreate时调用
private final static floatTARGET_HEAP_UTILIZATION = 0.75f;
VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);
& & 手机应用开发资源是很有限的，堆内存的上限值只有16M。不过只要代码写的好，这个值对于目前的手机应用需求已经足够了。
& & 如果出现内存溢出问题，把精力放在代码优化上吧。
如果对linux，Android，wince 等嵌入式底层有兴趣的，请加这个QQ群吧，群号：
EEWORLD 官方微信
Powered byAndroid是如何管理App内存的--Android内存优化第二弹 - 简书
Android是如何管理App内存的--Android内存优化第二弹
我们普及了下关于GC的一些事, 对GC的一些个概念, 流程有个大概的了解. 在一文中, 我们有提到, Android中每个App默认情况下是运行在一个独立进程中的, 而这个独立进程正是从Zygote孵化出来的VM进程. 也就是说, 每个App是运行在独立的VM空间的. 那么Android是怎么管理这些App的内存的呢, 这些独立运行的VM中的内存管理又是怎样的呢?
今天我们就来聊下Android中的内存管理.
1, Dalvik & ART
Android在4.4之前一直使用的Dalvik虚拟机作为App的运行VM的, 4.4中引入了ART作为开发者备选, 5.0起正式将ART作为默认VM了.
我们首先来简单了解下二者:
1.1 Dalvik
如果只是想简单了解, 个人觉得基本就满足要求了.
如果大家想深入, 可以看下老罗的Android之旅中, 从代码层面上分析了Dalvik的启动, 运行机制等. 值得一看.
需要说明的是, Dalvik采用的是JIT技术, 在应用程序启动时, JIT通过进行连续的性能分析来优化程序代码的执行, 在程序运行的过程中, Dalvik在不断的进行将字节码编译成机器码的工作.
ART 取自 Android RunTime. Android用其取代Dalvik, 主要目的就是为了提升运行性能. 所以, ART相比Dalvik有几个关键的提升:
引入AOT(ahead-of-time)预编译技术
在安装apk的过程中, ART会使用dex2oat程序所有的字节码预编译成了机器码. 应用程序运行过程中无需进行实时的编译工作, 只需要进行直接调用. 故而提高了应用程序的运行效率.
由原来的两次GC暂停减少为一次.
以较少的GC时间回收最近分配的, 短命的对象.
提升GC工程学, 使并发GC更及时.
压缩GC, 以减少后台内存使用和内存碎片.
开发和调试
支持内存/方法执行的采样分析.
支持更多的调试技.
在Crash report中提供更多信息.
2, Android的内存管理方式
ART和Dalvik都是使用和来管理内存的. 这就意味着, 任何被分配的内存都会持续存在, 唯一的释放这块内存的方式就是释放对象引用(让对象GC Root不可达), 故而让GC程序来回收内存.
2.1 App的内存分配和回收
对于每个App进程来说, Heap内存被限制在一个虚拟的内存区间内. 且定义了逻辑上的使用的Heap Size, 这个Heap Size在系统限制的最大值之内是随着应用的使用情况而变化的.
Heap内存的逻辑大小和实际物理内存的大小是不相同的. 后面我们在使用Memory Monitor等内存分析工具分析内存时, 会看到一个叫做Proportional Set Size (PSS)的值, 这个值才是系统认为的你的App所占用的物理内存大小.
这个PSS值也就是实际物理内存大小, 统计包括了你的应用进程所占用的内存大小, 和共享内存中占用的内存大小(比例分配方式计算).
Android VM不会压缩Heap内存的逻辑大小, 故而无法通过碎片整理的方式来释放Heap空间, 而只能通过回收Heap尾部的空内存块来压缩逻辑内存大小.
这时, 我们的GC就出场了, GC之后, VM会遍历Heap找到不被使用的pages, 通过函数将其返回给内核, 从而释放这块被逻辑Heap使用的物理内存.
2.2 App内存限制
Android是一个多任务系统, 为了保证多任务的运行, Android给每个App可使用的Heap大小设定了一个限定值.
这个值是系统设置的prop值, 系统编译时内置的, 保存在system/build.prop中. 一般国内的手机厂商都会做修改, 根据手机配置不同而不同, 可以通过如下命令查看:
$ adb shell
shell@hwH60:/ $ cat /system/build.prop
以手头的Huawei 荣耀6为例, heap size相关的prop如下:
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=192m
dalvik.vm.heapsize=512m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=2m
dalvik.vm.heapmaxfree=8m
dalvik.vm.heapstartsize
-- App启动后, 系统分配给它的Heap初始大小. 随着App使用可增加.
dalvik.vm.heapgrowthlimit
-- 默认情况下, App可使用的Heap的最大值, 超过这个值就会产生OOM.
dalvik.vm.heapsize
-- 如果App的manifest文件中配置了largeHeap属性, 如下.则App可使用的Heap的最大值为此项设定值.
&application
android:largeHeap="true"&
&/application&
dalvik.vm.heaptargetutilization
-- 当前理想的堆内存利用率. GC后, Dalvik的Heap内存会进行相应的调整, 调整到当前存活的对象的大小和 / Heap大小 接近这个选项的值, 即这里的0.75. 注意, 这只是一个参考值.
dalvik.vm.heapminfree
-- 单次Heap内存调整的最小值.
dalvik.vm.heapmaxfree
-- 单次Heap内存调整的最大值.
也可以直接使用getprop查看单项prop:
$ adb shell getprop dalvik.vm.heapsize
2.3 切换App时的内存管理机制
Android的进程级别
Android 系统会尽可能长时间地保持应用进程, 但为了新建进程或运行更重要的进程, 最终需要清除旧进程来回收内存. 为了确定保留或终止哪些进程, 系统会根据进程中正在运行的组件以及这些组件的状态, 将每个进程设定了一个重要级别. 必要时, 系统会首先消除重要性最低的进程, 然后是重要性略低的进程, 依此类推, 以回收系统资源.
依据重要程度从大到小依次分为5级:
用户当前操作所必需的进程. 如果一个进程满足以下任一条件, 即视为前台进程：
托管用户正在交互的 Activity（已调用 Activity 的 onResume() 方法）
托管某个 Service，后者绑定到用户正在交互的 Activity
托管正在“前台”运行的 Service（服务已调用 startForeground()）
托管正执行一个生命周期回调的 * Service（onCreate()、onStart() 或 onDestroy()）
托管正执行其 onReceive() 方法的 BroadcastReceiver
只有在内在不足以支持它们同时继续运行这一万不得已的情况下，系统才会终止它们。 此时，设备往往已达到内存分页状态，因此需要终止一些前台进程来确保用户界面正常响应。
没有任何前台组件、但仍会影响用户在屏幕上所见内容的进程。 如果一个进程满足以下任一条件，即视为可见进程：
托管不在前台、但仍对用户可见的 Activity（已调用其 onPause() 方法）。例如，如果前台 Activity 启动了一个对话框，允许在其后显示上一 Activity，则有可能会发生这种情况
托管绑定到可见（或前台）Activity 的 Service可见进程被视为是极其重要的进程，除非为了维持所有前台进程同时运行而必须终止，否则系统不会终止这些进程。
正在运行已使用 startService() 方法启动的服务且不属于上述两个更高类别进程的进程。尽管服务进程与用户所见内容没有直接关联，但是它们通常在执行一些用户关心的操作（例如，在后台播放音乐或从网络下载数据）。因此，除非内存不足以维持所有前台进程和可见进程同时运行，否则系统会让服务进程保持运行状态。
包含目前对用户不可见的 Activity 的进程（已调用 Activity 的 onStop() 方法）。这些进程对用户体验没有直接影响，系统可能随时终止它们，以回收内存供前台进程、可见进程或服务进程使用。 通常会有很多后台进程在运行，因此它们会保存在 LRU （最近最少使用）列表中，以确保包含用户最近查看的 Activity 的进程最后一个被终止。如果某个 Activity 正确实现了生命周期方法，并保存了其当前状态，则终止其进程不会对用户体验产生明显影响，因为当用户导航回该 Activity 时，Activity 会恢复其所有可见状态。
不含任何活动应用组件的进程。保留这种进程的的唯一目的是用作缓存，以缩短下次在其中运行组件所需的启动时间。 为使总体系统资源在进程缓存和底层内核缓存之间保持平衡，系统往往会终止这些进程。
切换App的内存管理
当用户切换App时, 被切换到后台的App所使用的内存并未因此删除, 该App进程被缓存到一个LRU缓存中, 以便用户切换回来时, 能更快的启动App, 让多任务更流畅.
但是, 当系统内存不够用的时候, 就会根据LRU特性, 以及上面说到的进程级别(同时也会考虑该App进程占用的内存大小)来决定杀死哪些进程, 来回收内存, 以便执行当前任务.
所以, 如果我们为了不要让系统kill掉我们的App, 可以从进程级别, 内存消耗量等几个方面进行优化.
本文加上, 我们讲了两篇的理论知识, 相信大家对Android的内存管理有了个大体的了解, 后面将介绍一些内存分析工具以及使用, 结合实际来说明怎么分析内存问题.
转载请注明出处, 欢迎大家分享到朋友圈, 微博~
看看书, 写写字; 捣鼓捣鼓小技术.
个人博客: http://blog.lmj.wiki