切记，所有的优化都遵循一条准则：

        空间换时间，时间换空间。

一、前言

        我们为什么会觉得卡顿、不流畅？

        卡顿等性能问题的最主要根源都是因为渲染性能，Android系统很有可能无法及时完成那些复杂的界面渲染操作。Android系统每隔16ms发出信号，触发对UI进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需要的60fps，为了能够实现60fps，这意味着程序的大多数操作都必须在16ms内完成。

        

        如果你的某个操作花费时间是24ms，系统在得到VSYNC信号的时候就无法进行正常渲染，这样就发生了丢帧现象。那么用户在32ms内看到的会是同一帧画面，在视觉上就会感到卡顿、不流畅。

        

        然而造成Android系统卡顿的原因有很多，主要包括以下三大类：

流程执行异常、系统负载异常、编译引起卡顿性能问题，所以今天分析一下系统负载异常中的低内存引起卡顿。

二、理论分析

        我们都知道内存是一个重要的系统公共资源，系统内任何进程的正常运行都需要消耗一定的内存资源。一般来讲设备的RAM硬件物理内存的大小是固定且有限的，而系统内运行的所有进程都需要共享这些有限内存资源。如何用有限的内存资源去满足系统各个应用进程无限的需求，这就涉及到一个系统内存管理的逻辑。这是一个复杂的问题，几乎贯穿了整个Android系统的各个层级。从Linux内核到Art虚拟机，再到Framework框架，甚至到APP应用，都会有各自的内存管理的策略。

        所以合理的内存的分配与管理无论对系统和应用来讲都至关重要。因为内存问题既能引发稳定性问题，也能引发卡顿性能问题。下面我们分别来分析一下：

2.1内存引起的稳定性问题：

        因为系统总的内存资源是有限的，为了防止单个应用进程无限制的占用内存资源，Android系统设计了很多机制来遏制这种情况的产生。比如在虚拟机层面，谷歌设计对每个应用进程占用的DalvikHeap的内存大小做出了限制，超过一定的阈值，就会触发OutOfMemeory（OOM）的异常，导致应用进程崩溃。此外Android系统还引入了lmkd低内存守护机制，当系统总的可用内存低于一定的阈值，就会按照进程优先级，将占用内存比较大的应用进程杀掉。

        32位的应用虚拟内存的寻址空间最大为4G，当应用进程的虚拟内存占用超过4G时，就无法继续为其分配内存，产生OOM类型的报错，出现应用崩溃或黑屏等问题。

        另外Android系统基于Linux内核，也绩承了Linux系统对应用进程的相关限制。如果应用进程中开启的线程过多（每创建一个空线程也会有一定的内存开销），超过/proc/sys/kernel/threads-max中定义的上限，也会报出OOM异常导致应用进程崩溃；再比如应用进程中打开的文件句柄过多，超过/proc/pid/limits节点中的定义上限，也会报出OOM异常导致应用进程崩溃。如下图所示：

2