流畅度问题——落叶归根
究其根源，所有反应在设备上的性能问题，基本围绕的就是三个点，流畅度问题，卡顿问题，以及内存问题，在简单点就是GPU，CPU以及内存问题，这几个问题属于关注的重心，也是各种问题最后回归的最终问题，所以接下来会根据这三个问题去展开介绍并且使用工具表现形式去解释，以及通过了解移动设备的底层机制来快速定位，快速了解瓶颈，话不多说，开始。
展示方式
1、先介绍官方解释，官方难懂或者不容易理解会进行解读；
2、测试过程中要被关注的场景；
3、延伸达到什么样的程度算不错的程度；
官方解释
定义流畅度，这里在 Perfdog 以及 Google 官网上的文档解释已经相对明确不少，但是还是会有点，难以理解，我们来看下关于 Perfdog 上面针对于其中定义流畅度其中的要点内容。
以下截图摘自 Perfdog 官方文档的中图
上图是什么意思？
从图中可以看出每个 VSync 之间都会有蓝色绿色的方块分辨代表每一帧中是谁，并且做了些什么样的事情，蓝色 B 为CPU，绿色 B 为GPU，黄块 A 代表绘制屏幕后面就这么称呼了。
他们的执行顺序代表的是在黄块 A 这个时间区间中，蓝 B 先处理，后面绿 B 再处理，这样，一帧的画面就显示在了屏幕中，这部分内容就是有关于渲染流程相关的内容了，暂不解释，后续讲到底层调度时会详细去讲，这部分也涉及到内存相关的内容，在这里只要先知道的是"CPU 先处理，GPU 后处理"即可。
而像上面的图中可以看到，他们在执行每一帧的画面时，有的蓝块 B 大，有的绿块 B 大会导致绘制的队列中超出当前帧的时间区间现象，这样的话就会出现所谓超时绘制，因为下一帧的黄块绘制时间被压缩了，这样绘制出来的画面是不稳定的，也就是出现了所谓的画面不流畅。
那稳定的画面绘制是怎样的呢？
那就是在黄块 A 固定给的时间区间中让蓝块 B，绿块 B 正常把活儿干完，并且不会超支时间，并且能维持一个较长时间比较稳定的状态也就不会出现所谓的不流畅现象了。
测试要关注场景
依赖依据
目前 Perfdog 的 FPS 与 Jank 评估流畅度已相对成熟，就可以拿现成的轮子去执行：
（摘自 Perfdog 的官方计算方式）
Google Jank 计算思路：考虑视觉惯性，以硬件 vsync 时间间隔，连续 1 次 vsync 没有新画面刷新，则认为是一次卡顿，也就是说下一次 vsync 时间点没有新画面刷新，则认为是一次 Jank。
计算依据：电影帧耗时——是按照 24 的帧率去计算
PerfDog Jank 计算方法：
同时满足两条件，则认为是一次卡顿 Jank.
①Display FrameTime>前三帧平均耗时 2 倍。
②Display FrameTime>两帧电影帧耗时 (1000ms/24*2≈83.33ms)。
同时满足两条件，则认为是一次严重卡顿 BigJank.
①Display FrameTime >前三帧平均耗时 2 倍。
②Display FrameTime >三帧电影帧耗时 (1000ms/24*3=125ms)。
特别解释：Jank 是记录一次卡顿的发生，如果采集过程中多次发生放在中低端机上就越容易出现帧率持续走低的情况，因为高端机的我 CPU 处理起来相对优越，中低端的 CPU 一旦处理过程中发生阻塞，就会容易出现帧率持续走低的情况，可以特别记录一下。
平时测试过程中，流畅度的关注场景以及应用主要反应在哪里？
1、性能数据是否达标
2、版本优化前后优化成果对比
3、竞品分析
是否达标问题
达标是在公司有现成的客户端性能标准的情况下，比如：TX 的 TDR3 客户端性能标准中会指出平均的 FPS 达到多少标准算合格，详细的可以去查看 TX 每年发送的白皮书中提到内容，属于公司指定的一套标准，测试过程中如果发现 FPS 以及 Jank 不达标，就说明产品就公司而言是不合格，需要去优化。
版本优化前后对比
在当前版本中执行过一次性能测试后，记录一次性能数据，经过一版的优化后，执行相同的测试场景再次观察性能指标，进行前后对比，来评估优化后的效果。
竞品分析
老生常谈的一个点，所做的产品大多都是有相同竞品，在持有相同硬件条件的情况下，同步去记录性能数据，做产品的横向对比，来查看产品与竞品上横向的差距，来决定是否继续接着优化。
以上就是目前使用该指标要重点关注的场景，也是平时用到最多场景。对于客户端性能来说。
那我们做到怎样的延伸算是比较好的？
就目前而言，如果我们本身属于非执行者，也就是性能数据不是测的，也应该能通过给到的性能数据评估出，整体的性能是否做到了优化，通过看性能数据指标而非看图也能脑子里想出大概曲线，那相对来说你就达到了一个比较好成长以及熟练度。
总结
综上所述，目前评估流畅度：
理解
黄块 A 的时间区间是硬件设备【也就是手机】比如现在的高刷屏，90hz 你去推算一下一帧的时间是多少，给你的这个时间就是黄块 A，你在硬件给你的这段时间里，项目每帧处理的数据要恰好让设备的蓝块 B，绿块 B 处理完，这样就能产生一个较为顺畅的画面，且机身也不会因此发热严重。超时的话，你应该也理解会带来什么样的影响。
延伸
FPS 与 Jank 一起去看去记录去评估流畅度；
该指标数据是作为迭代数据去对比，评估优化程度；
该指标是横向作为产品质量之一的一个指标；
持续关注后续每一篇游戏客户端性能文章
几个问题想交流下：
1.使用 perfdog 这类工具，也只能记录性能数据。如何确认某段性能曲线异常是问题呢？
这是我做客户端性能测试时的一个痛点。
2.类似 uwa GOT Online 的工具，虽说测试之后暴露出来的测试数据很多，但各项指标分别代表什么？怎样的算是有问题？
我也很头疼。
1）指标的学习成本不低。
2）即使明白了，也不见得就能看出问题所在。
3.和程序、TA、美术沟通，发现他们往往能够发现一些设计、实现不合理的地方，而我作为一个测试，基本上不太了解各种实现细节，所以这类问题也就不太可能发现。当然可以慢慢学，但学习成本似乎也不低。
所以，客户端的性能测试，做到什么程度才能真正的说，做好了？
JarvanRookie
回复
1、痛点需要有理论支撑，还有项目经验上的试错与实践来验证，我本人而言，使用 perfdog 这种简易性能信息来判断性能大头凭借最多的就是经验还有理论，理论上的知识有一些移动端的知识，引擎的知识以及业务开发的知识，还有就是接触的项目比较多，一点点摸出来的，所以在我看来没有速成，只有反复的试错，验证才能摸到门道，如果看性能曲线异常，实际上多对比的看一些表现正常的项目就能看出一些异常，什么是正常项目就是现在已上线的竞品，数据曲线很简单就那几个指标，但是牵扯的东西，有开发的内容，有手机本身硬件底层调度的机制；
CPU，IO 阻塞，你用 perfdog 可能你根本看不出哪里阻塞，但是可以通过看曲线的表现侧面去猜测会不会是渲染线程阻塞？占用高，也同样适用，另外的内存，开发中的加载卸载问题更是常见的内容，就是如此，多试多看；
2、成本不低，上面这个描述同样适用，学习路线比较重要，项目接触经验更重要，上面的简单性能，下面的深度性能都是如此，客户端性能测试，优化手段往往不是最难的，最难的是定位问题，深度性能有很多问题定位过程中有时候定位不到我见过的更多的甚至还会猜，所以指标不一定非常重要，分析方向才是最重要；
扩展：
1、学习开发知识，不用深入，知道现在的项目中用到的开发知识即可，如：内存，预加载，卸载，占用高，UI 框架，重绘制，解决方案，LOD ，对象池，多线程，异步加载，渲染：URP HDRP,等等这些都知道些，知道是什么，然后去套项目对你来说成长就不一样了，难，会很难，想学就不怕难了；
2、了解现在的手游，移动端测试，手机一定要了解，懂什么是分辨率，懂什么是发射器，懂功耗，懂 CPU，懂 GPU，等等，没事看看一些手机测评的视频，还有市面上手机上的一些视频，乱七八糟的看看，对你没坏处；
3、你在项目中的基本不了解都做了啥，可能跟你没完全深入项目有关，游测的处境我多少知道些，某讯的游测据我所知接触的东西都窄的很，深入全面的了解项目可能可遇不可求，机会甚少，但是需要自己多尝试；
什么样的情况算做好：
个人：
1、有快速定位性能大头的能力；
2、有丰富的项目经验，接触的不同类型的游戏比较多，性能测试场景每次都灵活制定且科学；
3、深度性能有最好，无也无妨，基本满足测试项的项目需求即可；
团队：
项目性能问题不可能完全排除，达到公司所谓的上线标准即可；