探析Android中的四类性能优化

作者：Yj家的孺子牛

流畅性优化

主线程模型

了解 Android 的流畅性优化之前，我们需要先了解Android的线程结构。在 Android 中，有一个主线程模型，其中所有的绘制以及交互都是在主线程中进行的，所以，当我们编写的某类代码是需要在主线程中运行的，那么这类代码必然会影响到我们的绘制等，继而影响到流畅性问题。

下图之中，展示了我们哪类代码操作代码是会影响到主线程。

System Events(系统事件)

例如需要关闭、开启某个页面，这些都是需要通知我们的系统的来完成的，这些就是系统事件。它会触发到主线程的耗时操作。
Input Events(输入事件)

输入事件并非指单纯的在输入框输入信息的事件，而是在手机上进行操作。因为手机本身可以被抽象的指代为一个输入输出的设备。在触摸屏上任意的点击都是一个输入事件，它都是在主线程中完成的
Application(应用事件)

我们APP的启动都是要经过应用事件，而各种生命周期的初始化相关的回调、初始化也是要经过它。例如各类启动的 SDK 都是放在 Application 类中初始化的，这都是要在主线程中进行的。
Services(服务事件)

这一点大家也许有点疑惑，后台服务为什么会是在主线程的呢？我们不是一般新开一个线程在后台执行耗时任务的么？上述的两点其实是不矛盾的，只是我们平时的理解也许有误，认为 Services 作为后台任务就是在子线程才对。但事实上， Services 是运行在主线程中的，即使它是在后台执行的，而我们需要执行耗时任务的时候，再在 Services 中创建子线程来执行这个耗时任务。
Alarm(定时事件)

定时事件中，由于它默认子线程是不安全的，主线程才是安全的，所以是需要到主线程去执行的。

而 UI绘制 虽然是在主线程中的，但是我们的代码是无法去控制它的，这是系统进行控制的。我们只能输入需要绘制什么，但是不能影响其绘制的流程。

界面更新以及卡顿

界面更新的VSync

知晓主线程模型后，我们来看一下 界面是如何刷新 的

下面的一图是介绍 Android 中的 VSync 机制，VSync 我们可以简单的理解为是一种屏幕刷新的信号，它会每隔一段时间就会刷新一次屏幕。

**垂直同步（VSync）：**当屏幕从缓冲区扫描完一帧到屏幕上之后，开始扫描下一帧之前，发出的一个同步信号，该信号用来切换前缓冲区和后缓冲区。

如下图，UI Draw 会在 16ms 就执行一次，所以我们的需要让我们的绘制流程在 16ms 内执行完才不会出现卡顿问题。

所以说，如果我们不影响界面的更新，让每次绘制流程都可以保持在16ms以下，那么就不会出现卡顿问题了。

三类主要的卡顿以及其原因

输入事件无法即时响应

这类卡顿主要表现为我们滑动屏幕的时候，屏幕根本无法响应。这是由于我们在主线程中执行了一段非常耗时的、与事件无关的代码，而由于这段代码还在执行，所以输入事件根本没法执行，也没法绘制出我们的滑动效果了。

输入事件立刻响应，但其耗时较长

这类卡顿中，输入事件是立即响应的了，但是由于我们又在输入事件的分发中做了很多计算逻辑等耗时的操作，所以还是会出现卡顿。其表现出来的效果是，滑动的时候一卡一卡的，这是由于输入事件的执行超过了16ms了，导致了丢帧的问题。

UI Draw 之外需要在主线程中执行的任务耗时长

我们知道，主线程中不单只有 UI 的绘制任务，还有其他的例如 Application 任务也是需要放置在主线程中执行的。这些任务如果不做处理，也一股脑的放置在主线程中执行，那么也会导致其占用时间过长，使得 APP 出现丢帧的问题。

解决卡顿问题

我们现已经知道了三大类卡顿的原因，其归结来说的原因就是主线程中出现了不必要的耗时操作，导致最后主线程的UI绘制出现阻塞或者溢出。那么我们解决卡顿、做流畅性优化的方法也是很明确了，那就是让主线程尽量只做交互(Input Event)以及刷新(UI Draw)。当然很多需要在主线程中的代码是无法避免的，但是我们尽量使其缩小，让所有的耗时代码都在子线程中运行，这样子使得其减少丢帧，能够更加的连贯顺滑。

没有VSync会怎么样？

上述讲到了 VSync 的作用以及卡顿的原因和处理，我们知道 VSync 信号可以用于同步刷新页面。那若是没有 VSync 信号，我们的页面会出现什么样的问题？

其实会出现画面撕裂。画面撕裂是什么呢？如下图中红色框中的图面，与上边出现了撕裂，这种就是画面撕裂。其出现的原因是上一帧的页面还在绘制中，下一帧页面就继续占用资源绘制了，所以会出现几帧的页面同时绘制在一个页面中，出现了画面撕裂感。

那为何映入 VSync 信号之后就不会有画面撕裂问题了呢？

在显示一张图片的时候，其流程为：GPU进⾏渲染—>帧缓存区⾥ —>显示控制器—>读取帧缓存区信息(位图) —> 数模转化(数字信号处—>模拟型号) —>(逐⾏扫描)显示。正常的情况下，显示器完全显示完一帧后，帧缓存区更新一帧，这样便不会有撕裂问题，但事实并非如此。当显卡输出帧的速度比显示器快，显示器的处理速度跟不上显卡，在显示器处理显卡丢过来的第1帧的时候，第2帧就又到了（帧缓存区已更新），导致同一个画面同时出现1、2两帧，撕裂就产生了

在没有 VSync 信号的时候，一旦GPU渲染完后就会交由屏幕去将其绘制出来，那么 CPU 和 GPU 处理的事件有长有短，一旦两帧出现绘制冲突，就会出现画面撕裂问题了。

所以说，解决画面撕裂的核心是决定好数据的交换时机(绘制时机)由谁来控制。在绘制中，不应该是 CPU 处理写入之后就立即绘制，而应该是由屏幕渲染完一帧之后才去绘制绘制下一帧。然而屏幕不是控制器，它无法控制什么时候进行绘制，但是它可以传递 VSync 信号给 Android 系统，借助 VSync 信号，Android 就可以让 CPU 在新的一帧开始的时候立即处理显示问题了。

VSYNC 信号是由屏幕（显示设备）产生的，并且以 60fps 的固定频率发送给 Android 系统，Android 系统中的 SurfaceFlinger 接收发送的 VSYNC 信号。VSYNC 信号表明可对屏幕进行刷新而不会产生撕裂。

图片中未对 VSync 信号进行处理，导致出现卡顿问题。

资源优化

资源是什么？

资源指的是：Android 手机的软件和硬件资源，通俗意义上应用依赖于移动端的有限资源和系统规定的数值。例如：功耗、存储、流量、系统参数、CPU、内存等。

我们对上述的资源进行优化的时候，其并非无关联的、相互隔离的，例如流量消耗大，那么功耗消耗也会大，内存和存储的消耗也会大。但是我们需要优化某一个点的时候，是需要聚焦于其中这一点进行优化的。

当然，我们使用的设备也是在不断地优化的，但是并非说等着硬件的优化，我们的软件能跑就行。对于资源优化，我们追求的是利用最小的资源达到最好的效果，这是很有挑战性，对自我提升也很高的事情。

Android 能做哪些资源优化

上图中展示了对于当下技术特征的满意度，我们会发现上述的点其实都不算高。无论是内存/存储、电量或者是流量等等方面都是需要我们继续优化的点。而右图指的是如果后台的进程如果很多的话，使得内存占用很多，导致前台的APP也会收到内存的限制变得卡顿。

上图中对音量的优化其实收益也是很大的。例如当下的自媒体平台抖音，它就是在端侧进行了音量优化，取得了很大的收益。因为每一个人拍视频的音量和背景嘈杂度都是不一样的，所以我们需要在上传视频到平台的时候进行音量优化，对各种音量进行优化、拟合到同一水平，这样子可以使得用户在打开不同视频的时候，视频的音量不会影响到用户的体验。