安卓系统的结构和内存管理优化 浅谈Android系统的基本体系结构与内存管理优化

Android运行环境一览
Android基于linux内核，面向移动终端的操作系统。主要包括以下几个方面：

Application Framework：
这一层为应用开发者提供了丰富的应用编程接口，如 Activity Manager，Content Provider，Notification Manager，以及各种窗口 Widget 资源等。所有的APP都是运行在这一层之上。
Dalvik 虚拟机：
Dalvik VM采用寄存器架构，而不是JVM的栈架构，更适于移动设备。java源代码经过编译成为.class字节码文件，然后由谷歌提供的 dx工具将其转化为Dalvik可识别的.dex文件。
Linux kernel：
每个APP应用程序由一个独立的Dalvik VM来解释执行，而一个Dalvik VM实例对应一个linux内核进程。
所以说，每个APP之间完全隔离，资源独立。使得每个APP更加安全，但也不利于进程间通信

Android官方介绍

**Android 系统架构

Application framework
大部分开发者十分关心这一层。你必须要了解开发者会接触到的所有API接口，大部分接口都与硬件抽象层(HAL层)接口一一对应，而且它们会告诉你如何实现你自己的驱动。

Binder IPC
Binder进程间通信机制帮助Application framework层能够跨进程并且调用系统级服务。从根本上讲，它帮助高级别的framework的API接口与Android系统服务进行交互。

系统服务
大部分Application framework api具备的功能都要依靠与某种系统服务进行通信从而操作底层硬件。系统服务根据不同的功能分成了若干模块组件，例如Window Manager, Search Service, or Notification Manager。系统服务主要包含两大块：系统和媒体。前者对应的服务包含如Window Manager 或 Notification Manager，后者对应的服务都与播放或记录媒体有关。
硬件抽象层Hardware abstraction layer (HAL)
硬件抽象层可以作为一个标准接口让Android系统调用设备驱动层而不用管这些驱动和硬件时如何实现的。
![硬件驱动层相关组件]
Linux Kernel
大多数情况下，你自己开发设备驱动和开发linux设备驱动时一样的。Android挑选了一个特定的linux内核版本，这个版本包含了如wakelocks(一个内存管理系统)，Binder IPC驱动和其他一些特征，这些特征对于像Android一样的移动嵌入式平台都非常重要。你也可以根据自己的需求选择合适的kernel版本，只要它能支持一些必要的属性如Binder IPC驱动等。但是，我们仍然推荐你使用最新版本的Android内核。具体可参考内核编译
相关知识点：
应用程序进程间隔离机制：
Android系统包括四层架构：从底层往上依次是Linux kernel层、C/C++函数库与Android运行时环境(Dalvik VM等)层、Android Framwork框架层、应用程序层。其中，Android运行时环境层类似Java里的JRE层，主要用来运行java程序，不过此处的虚拟机是Dalvik虚拟机。每一个Android应用程序都运行在单独的Davlik进程里，Dalvik虚拟机针对同时高效运行多个虚拟机而优化，在这一层实现了应用程序的进程间隔离。

Dalvik虚拟机与JVM区别：

JVM直接从.class或Jar包中加载字节码解释运行，Dalvik通过DX工具将.class文件编译为.dex文件（Dalvik Executable）来运行。
JVM采用栈结构，而Dalvik采用寄存器结构，更适于移动设备。
为何Android要采用Dalvik虚拟机而不是JVM呢？

大多数虚拟机（包括JVM）都是基于栈的，而Dalvik虚拟机则是基于寄存器的，性能更好，不过也导致硬件通用性略差；
运行专有.dex文件。DX工具对.class文件编译时，去除里面的冗余信息，并把所有.class文件整合到一个文件中，提高了性能。同时DX工具还会对.dex文件进行性能优化。

内存管理及优化
一、Android内存基础
物理内存与进程内存
物理内存即移动设备上的RAM，当启动一个Android程序时，会启动一个Dalvik VM进程，系统会给它分配固定的内存空间（16M,32M不定），这块内存空间会映射到RAM上某个区域。然后这个Android程序就会运行在这块空间上。Java里会将这块空间分成Stack栈内存和Heap堆内存。stack里存放对象的引用，heap里存放实际对象数据。
在程序运行中会创建对象，如果未合理管理内存，比如不及时回收无效空间就会造成内存泄露，严重的话可能导致使用内存超过系统分配内存，即内存溢出OOM，导致程序卡顿甚至直接退出。

内存泄露（Memory Leak）
Java内存泄漏指的是进程中某些对象（垃圾对象）已经没有使用价值了，但是它们却可以直接或间接地引用到gc roots导致无法被GC回收。Dalvik VM具备的GC机制（垃圾回收机制）会在内存占用过多时自动回收，严重时会造成内存溢出OOM。

内存溢出OOM
当应用程序申请的java heap空间超过Dalvik VM HeapGrowthLimit时，溢出。
注意：OOM并不代表内存不足，只要申请的heap超过Dalvik VM HeapGrowthLimit时，即使内存充足也会溢出。效果是能让较多进程常驻内存。

如果RAM不足时系统会做什么？
Android的Memory Killer会杀死优先级较低的进程，让高优先级进程获取更多内存。

Android系统默认内存回收机制

进程优先级：Foreground进程、Visible进程、Service进程、Background进程、Empty进程;
如果用户按Home键返回桌面，那么该app成为Background进程；如果按Back返回，则成为Empty进程
ActivityManagerService直接管理所有进程的内存资源分配。所有进程要申请或释放内存都需要通过ActivityManagerService对象。
垃圾回收不定期执行。当内存不够时就会遍历heap空间，把垃圾对象删除。
堆内存越大，则GC的时间更长

二、优化
Bitmap优化
Bitmap非常消耗内存，而且在Android中，读取bitmap时， 一般分配给虚拟机的图片堆栈只有8M，所以经常造成OOM问题。所以有必要针对Bitmap的使用作出优化：

• 图片显示：加载合适尺寸的图片，比如显示缩略图的地方不要加载大图。
• 图片回收：使用完bitmap，及时使用Bitmap.recycle()回收。
• 问题：Android不是自身具备垃圾回收机制吗？此处为何要手动回收。
• Bitmap对象不是new生成的，而是通过BitmapFactory生产的。而且通过源码可发现是通过调用JNI生成Bitmap对象（nativeDecodeStream()等方法）。所以，加载bitmap到内存里包括两部分，Dalvik内存和Linux kernel内存。前者会被虚拟机自动回收。而后者必须通过recycle()方法，内部调用nativeRecycle()让linux kernel回收。
• 捕获OOM异常：程序中设定如果发生OOM的应急处理方式。
• 图片缓存：内存缓存、硬盘缓存等
• 图片压缩：直接使用ImageView显示Bitmap时会占很多资源，尤其当图片较大时容易发生OOM。可以使用BitMapFactory.Options对图片进行压缩。
• 图片像素：android默认颜色模式为ARGB_8888，显示质量最高，占用内存最大。若要求不高时可采用RGB_565等模式。图片大小：图片长度*宽度*单位像素所占据字节数
• ARGB_4444：每个像素占用2byte内存
• ARGB_8888：每个像素占用4byte内存 （默认）
• RGB_565：每个像素占用2byte内存

对象引用类型

强引用 strong：Object object=new Object()。当内存不足时，Java虚拟机宁愿抛出OOM内存溢出异常，也不会轻易回收强引用对象来解决内存不足问题；
软引用 soft：只有当内存达到某个阈值时才会去回收，常用于缓存；
弱引用 weak ：只要被GC线程扫描到了就进行回收；
虚引用
如果想要避免OOM发生，则使用软引用对象，即当内存快不足时进行回收；如果想尽快回收某些占用内存较大的对象，例如bitmap，可以使用弱引用，能被快速回收。不过如果要对bitmap作缓存就不要使用弱引用，因为很快就会被GC回收，导致缓存失败。
池 pool

对象池：如果某个对象在创建时，需要较大的资源开销，那么可以将其放入对象池，即将对象保存起来，下次需要时直接取出使用，而不用再次创建对象。当然，维护对象池也需要一定开销，故要衡量。
线程池：与对象池差不多，将线程对象放在池中供反复使用，减少反复创建线程的开销。