切记,所有的优化都遵循一条准则:
空间换时间,时间换空间。
一、前言
我们为什么会觉得卡顿、不流畅?
卡顿等性能问题的最主要根源都是因为渲染性能,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