持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第23天，点击查看活动详情
性能优化系列文章
探析Android中的四类性能优化 - 掘金 (juejin.cn)
前置知识
- 有Android开发基础
- 了解Android运行原理
前言
在上一篇文章 初识性能优化 中我们提到我们需要从流畅性优化、资源优化、稳定性优化 和 系统级优化 这四个层面来对Android中的软件做优化。但是我们只是简单的对其进行介绍，以及举了一些流畅性优化的实战例子。下面，我们就对这四类优化点展开进行讲解(文章参数理论和原因，无实战 demo 展示)。
流畅性优化
主线程模型
了解 Android 的流畅性优化之前，我们需要先了解Android的线程结构。在 Android 中，有一个主线程模型，其中所有的绘制以及交互都是在主线程中进行的，所以，当我们编写的某类代码是需要在主线程中运行的，那么这类代码必然会影响到我们的绘制等，继而影响到流畅性问题。
下图之中，展示了我们哪类代码操作代码是会影响到主线程。
-
System Events(系统事件)
例如需要关闭、开启某个页面，这些都是需要通知我们的系统的来完成的，这些就是系统事件。它会触发到主线程的耗时操作。
-
Input Events(输入事件)
输入事件并非指单纯的在输入框输入信息的事件，而是在手机上进行操作。因为手机本身可以被抽象的指代为一个输入输出的设备。在触摸屏上任意的点击都是一个输入事件，它都是在主线程中完成的，具体的流程可以查阅 View体系(上)
-
Application(应用事件)
我们APP的启动都是要经过应用事件，而各种生命周期的初始化相关的回调、初始化也是要经过它。例如各类启动的 SDK 都是放在
Application类中初始化的，这都是要在主线程中进行的。 -
Services(服务事件)
这一点大家也许有点疑惑，后台服务为什么会是在主线程的呢？我们不是一般新开一个线程在后台执行耗时任务的么？上述的两点其实是不矛盾的，只是我们平时的理解也许有误，认为
Services作为后台任务就是在子线程才对。但事实上，Services是运行在主线程中的，即使它是在后台执行的，而我们需要执行耗时任务的时候，再在Services中创建子线程来执行这个耗时任务 。 -
Alarm(定时事件)
定时事件中，由于它默认子线程是不安全的，主线程才是安全的，所以是需要到主线程去执行的。
而 UI绘制 虽然是在主线程中的，但是我们的代码是无法去控制它的，这是系统进行控制的。我们只能输入需要绘制什么，但是不能影响其绘制的流程。
界面更新以及卡顿
界面更新的VSync
知晓主线程模型后，我们来看一下 界面是如何刷新 的
下面的一图是介绍 Android 中的 VSync 机制，VSync 我们可以简单的理解为是一种屏幕刷新的信号，它会每隔一段时间就会刷新一次屏幕。(Vsync 是什么、View体系(下) 或 Android图形显示系统 可查看更多信息)
**垂直同步（VSync）：**当屏幕从缓冲区扫描完一帧到屏幕上之后，开始扫描下一帧之前，发出的一个同步信号，该信号用来切换前缓冲区和后缓冲区。
而在 Android 中，VSync 信号的回调一般会在主线程中每隔16ms执行一次，而我们通过频率计算公式来计算一下： ，当 时候，我们可以得出 这个就是我们常用的 。
在我们的视觉感知中， 通常可以让人眼感知到线性动作了，而人能感知到不卡顿的最低帧数则为 。在 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也会收到内存的限制变得卡顿。
上图中对音量的优化其实收益也是很大的。例如当下的自媒体平台抖音，它就是在端侧进行了音量优化，取得了很大的收益。因为每一个人拍视频的音量和背景嘈杂度都是不一样的，所以我们需要在上传视频到平台的时候进行音量优化，对各种音量进行优化、拟合到同一水平，这样子可以使得用户在打开不同视频的时候，视频的音量不会影响到用户的体验。
而对于亮度的优化，可以使得我们的功耗降低，节省手机有限的电量。上面左图可以看出，深色模式对电量的影响是很显著的。而同时在优化亮度的时候，我们也可以找出功耗与体验的平衡点，使得功耗低的时候，我们的体验感也是最好的。这一点可以在右图中看出。
稳定性优化
对于稳定性优化，我们主要讲的点是 ANR，而其他的崩溃等则是需要尽可能的抹去，这里暂不做分析。ANR 是应用长时间处于阻塞状态的时候，系统会触发 ANR ，然后系统会询问是否需要强制退出或者继续等待。
ANR 存在的的原因是我们不能因为一个程序出现问题就使得整个手机无法使用。所以需要 ANR 来将错误的程序退出。而我们对其优化则需要尽可能的减少这种情况的出现，使得用户被打断，这是一种很不好的体验。
诊断 ANR 时需要考虑以下几种常见模式：
- 应用在主线程上非常缓慢地执行涉及 I/O 的操作。
- 应用在主线程上进行长时间的计算。
- 主线程在对另一个进程进行同步 binder 调用，而后者需要很长时间才能返回。
- 主线程处于阻塞状态，为发生在另一个线程上的长操作等待同步的块。
- 主线程在进程中或通过 binder 调用与另一个线程之间发生死锁。主线程不只是在等待长操作执行完毕，而且处于死锁状态。
系统级优化
对于 Android 系统，Google 本身也对其系统做了很多重大的优化，这些优化使得 Android 系统很多的问题得以解决，很多使用体验变得更好。而这些优化的点，我们可以作为今后的思路，让我们对 APP 的优化有更广阔的思考，让我们能发掘出更多的优化点和对其有更加深刻的思考
对于业务开发中，我们很多时候都是使用到 Application 和 FrameWork 层，但是需要真正做好性能优化，我们需要了解到很多的 核心库 Kernel 层的原理，这对我们自身来说，也是正向的收益。
本篇四大性能优化的详解就讲到这里，如果对你有帮助欢迎star！
参考
屏幕撕裂及掉帧原因与解决方案_Daniel_Coder的博客-CSDN博客_屏幕撕裂
Android 显示刷新机制、VSYNC和三重缓存机制_卜大爷的博客-CSDN博客_android vsync
Service 运行在主线程_Frank_de_Boer的博客-CSDN博客_service是否在主线程中执行
View体系(下)|青训营笔记 - 掘金 (juejin.cn)
View体系(上)|青训营笔记 - 掘金 (juejin.cn)
Android图形显示系统（一）_良秋的博客-CSDN博客_android显示系统
