android60流畅

A. android流畅度评估及卡顿优化

Google定义：界面呈现是指从应用生成帧并将其显示在屏幕上的动作。要确保用户能够流畅地与应用互动，应用呈现每帧的时间不应超过16ms，以达到每秒60帧的呈现速度（为什么是60fps？）。
如果应用存在界面呈现缓慢的问题，系统会不得不跳过一些帧，这会导致用户感觉应用不流畅，我们将这种情况称为卡顿。

来源于： Google Android的为什么是60fps？

16ms意味着1000/60hz，相当于60fps。这是因为人眼与大脑之间的协作无法感知超过60fps的画面更新。12fps大概类似手动快速翻动书籍的帧率， 这明显是可以感知到不够顺滑的。24fps使得人眼感知的是连续线性的运动，这其实是归功于运动模糊的效果。 24fps是电影胶圈通常使用的帧率，因为这个帧率已经足够支撑大部分电影画面需要表达的内容，同时能够最大的减少费用支出。 但是低于30fps是 无法顺畅表现绚丽的画面内容的，此时就需要用到60fps来达到想要的效果，超过60fps就没有必要了。如果我们的应用没有在16ms内完成屏幕刷新的全部逻辑操作，就会发生卡顿。

首先要了解Android显示1帧图像，所经历的完整过程。

如图所示，屏幕显示1帧图像需要经历5个步骤：

常见的丢帧情况： 渲染期间可能出现的情况，渲染大于16ms和小于16ms的情况：

上图中应该绘制 4 帧数据 , 但是实际上只绘制了 3 帧 , 实际帧率少了一帧

判断APP是否出现卡顿，我们从通用应用和游戏两个纬度的代表公司标准来看，即Google的Android vitals性能指标和地球第一游戏大厂腾讯的PrefDog性能指标。

以Google Vitals的卡顿描述为准，即呈现速度缓慢和帧冻结两个维度判断：

PerfDog Jank计算方法：

帧率FPS高并不能反映流畅或不卡顿。比如：FPS为50帧，前200ms渲染一帧，后800ms渲染49帧，虽然帧率50，但依然觉得非常卡顿。同时帧率FPS低，并不代表卡顿，比如无卡顿时均匀FPS为15帧。所以平均帧率FPS与卡顿无任何直接关系)

当了解卡顿的标准以及渲染原理之后，可以得出结论，只有丢帧情况才能准确判断是否卡顿。

mpsys 是一种在设备上运行并转储需要关注的系统服务状态信息的 Android 工具。通过向 mpsys 传递 gfxinfo 命令，可以提供 logcat 格式的输出，其中包含与录制阶段发生的动画帧相关的性能信息。

借助 Android 6.0（API 级别 23），该命令可将在整个进程生命周期中收集的帧数据的聚合分析输出到 logcat。例如：

这些总体统计信息可以得到期间的FPS、Jank比例、各类渲染异常数量统计。

命令 adb shell mpsys gfxinfo <PACKAGE_NAME> framestats 可提供最近120个帧中，渲染各阶段带有纳秒时间戳的帧时间信息。

关键参数说明：

通过gfxinfo输出的帧信息，通过定时reset和打印帧信息，可以得到FPS(帧数/打印间隔时间)、丢帧比例（(janky_frames / total_frames_rendered)*100 %）、是否有帧冻结(帧耗时>700ms)。
根据第2部分的通用应用卡顿标准，可以通过丢帧比例和帧冻结数量，准确判断当前场景是否卡顿。并且通过定时截图，还可以根据截图定位卡顿的具体场景。

如上图所示，利用gfxinfo开发的检查卡顿的小工具，图中参数和卡顿说明如下：

根据上面对gfxinfo的帧信息解析，可以准确计算出每一帧的耗时。从而可以开发出满足腾讯PerfDog中关于普通卡顿和严重卡顿的判断。

依赖定时截图，即可准确定位卡顿场景。如下图所示（此处以PerfDog截图示例）：

通过第3部分的卡顿评估方法，我们可以定位到卡顿场景，但是如何定位到具体卡顿原因呢。

首先了解卡顿问题定位工具，然后再了解常见的卡顿原因，即可通过复现卡顿场景的同时，用工具去定位具体卡顿问题。

重点就是，充分利用gfxinfo输出的帧信息，对卡顿问题进行分类。

了解了高效定位卡顿的方法和卡顿问题定位工具，再熟悉一下常见的卡顿原因，可以更熟练的定位和优化卡顿。

SurfaceFlinger 负责 Surface 的合成，一旦 SurfaceFlinger 主线程调用超时，就会产生掉帧。
SurfaceFlinger 主线程耗时会也会导致 hwc service 和 crtc 不能及时完成，也会阻塞应用的 binder 调用，如 dequeueBuffer、queueBuffer 等。

后台进程活动太多，会导致系统非常繁忙，cpu io memory 等资源都会被占用，这时候很容易出现卡顿问题，这也是系统这边经常会碰到的问题。
mpsys cpuinfo 可以查看一段时间内 cpu 的使用情况：

当线程为 Runnable 状态的时候，调度器如果迟迟不能对齐进行调度，那么就会产生长时间的 Runnable 线程状态，导致错过 Vsync 而产生流畅性问题。

system_server 的 AMS 锁和 WMS 锁 , 在系统异常的情况下 , 会变得非常严重 , 如下图所示 , 许多系统的关键任务都被阻塞 , 等待锁的释放 , 这时候如果有 App 发来的 Binder 请求带锁 , 那么也会进入等待状态 , 这时候 App 就会产生性能问题 ; 如果此时做 Window 动画 , 那么 system_server 的这些锁也会导致窗口动画卡顿。

Android P 修改了 Layer 的计算方法 , 把这部分放到了 SurfaceFlinger 主线程去执行, 如果后台 Layer 过多，就会导致 SurfaceFlinger 在执行 rebuildLayerStacks 的时候耗时 , 导致 SurfaceFlinger 主线程执行时间过长。

主线程执行 Input Animation Measure Layout Draw decodeBitmap 等操作超时都会导致卡顿 。

Activity resume 的时候, 与 AMS 通信要持有 AMS 锁, 这时候如果碰到后台比较繁忙的时候, 等锁操作就会比较耗时, 导致部分场景因为这个卡顿, 比如多任务手势操作。

应用里面涉及到 WebView 的时候, 如果页面比较复杂, WebView 的性能就会比较差, 从而造成卡顿。

如果屏幕帧率和系统的 fps 不相符 , 那么有可能会导致画面不是那么顺畅. 比如使用 90 Hz 的屏幕搭配 60 fps 的动画。

由上面的分析可知对象分配、垃圾回收(GC)、线程调度以及Binder调用 是Android系统中常见的卡顿原因，因此卡顿优化主要以下几种方法，更多的要结合具体的应用来进行：

在计算机和通信领域，帧是一个包括“帧同步串行”的数字数据传输单元或数字数据包。
在视频领域，电影、电视、数字视频等可视为随时间连续变换的许多张画面，其中帧是指每一张画面。

B. 打穿越火线苹果的60帧和安卓的60帧哪个好一点

苹果的60帧更好一些。
首先，iPhone已经拥有规格较高的屏幕，就拿去年发布的iPhone 12来说，全系列标配OLED三星订制屏幕。虽然没有高刷新率加持，但无论是画面观感还是色彩还原程度，都已经达到业界顶尖水准，苹果用不着通过提高刷新率的方式来给自己加码。另一方面，iPhone拥有基于底层语言优化的iOS，再配合A系列芯片，得以突破算力瓶颈。所以即便iPhone没有高刷新率，但它的操作体验本就很流畅。对于苹果来说，与其花心思研究屏幕，倒不如在系统更新方面下功夫。
苹果公司（Apple Inc. ）是美国一家高科技公司。由史蒂夫·乔布斯、斯蒂夫·盖瑞·沃兹尼亚克和罗纳德·杰拉尔德·韦恩（Ron Wayne）等人于1976年4月1日创立，并命名为美国苹果电脑公司（Apple Computer Inc.），2007年1月9日更名为苹果公司，总部位于加利福尼亚州的库比蒂诺。

C. 如何提升安卓系统的流畅度

可进行如下操作：

安卓刷机
系统这一块绝对是有着举足轻重的地位，一款好的系统能让安卓手机脱胎换骨。而从Android 4.1开始，Android的流畅性可以说有了质的飞跃。Android 4.1的触控感觉非常好，这主要归功于Android 4.1的帧速度提高到了60fps，而且在触摸延迟上有更加优秀的表现。因此只要情况允许，建议所有Android手机都刷到4.1以上，这种体验绝对是以往使用4.0甚至2.3系统都不可想象的。当然，对于大部分Android手机来说，4.1还是遥不可及，只有通过第三方ROM才能达到品尝“果冻豆”的目的，这里就要特别注意第三方ROM的稳定性问题。
如果不能刷Android 4.1，那还可以选择一些第三方ROM例如原生系统AOKP或者CM系列。由于系统非常精简，这些第三方ROM也会带来流畅度的提升，当然要放弃的是官方ROM的各种自带软件和UI，这就要看用户的取舍了。

更换内核
Android手机的内核（Kernel）对手机流畅性也是有很大的影响，内核直接影响CPU的运行效率、频率变化。说到刷内核就不能不提超频，一些第三方内核支持CPU的超频，CPU频率提高了流畅度当然会有变化，当然这里也要特别注意温度和电压的控制。

已经有提及过，很多手机默认是标准模式甚至是省电模式，这对性能是有不少影响的，因此建议不是有特别需求还是调至性能模式（位置：系统设置，因不同手机而异）。

关闭动画特效

这是一个Android 4.0才开始有的设置选项，Android 4.0有两项（窗口动画缩放以及过渡动画缩放），Android 4.1增加了动画程序时长调整。有人说Android的动画比较卡，没有iPhone顺滑，有这选项可好，你说动画不顺嘛，我关掉还不行吗？关闭了这些以后会感觉反应迅速了很多，但是牺牲了一定的视觉感受（位置：设置→开发人员选项）。

不保留活动
这个选项即把Android相对iPhone的其中一个很大的优势舍弃了，也就是我们常说的“多任务”，Android现在的高端机动不动就四核、2G RAM，如果只跑一个软件，可想而知流畅度会非常高，但是这里并不建议使用这种方法提升流畅度，没有多任务的Android更像一只三脚猫，如果只是体验一下那种感觉也无妨（位置：设置→开发人员选项）。

借助第三方软件优化
实际上很多Android卡顿的罪魁祸首就是系统的启动器，现在一些品牌的手机启动器做得越来越炫丽，也越来越复杂，当然代价就是占用RAM和ROM更多，如果不是对这方面特别有要求，完全可以替换一些第三方的启动器，例如Apex、NOVA等，它们带来的流畅度提升也是非常明显的（这里使用NOVA作介绍）。

卸载系统自带程序

现在越来越多官方系统自带很多恼人的程序，而且不能卸载，这些软件往往都会开机自启动，对系统流畅度影响比较大，但是要删除这些自带软件需要获取root权限。通用一些第三方ROM也会有自带垃圾软件问题，而大部分第三方ROM都自带root，所以这个相对好解决。这里删除程序也要特别注意，不要错删一些系统软件，否则后果很严重（这里使用的是“力卓工具箱”）。
建议：卸载一些不常用的桌面插件、系统强制安装的第三方软件等

管理开机自启动项
这方面在之前的省电专题中也有提到过，减少开机自启动的软件，除了能节省电量之外，当然还能提升手机的反应速度，当然这里也不能一下把所有软件都关闭，关闭一些不需要自启动的第三方软件就可以达到目的了，如果不小心把系统本身的程序禁用了就会比较麻烦（这里使用的是“力卓工具箱”）。

END

D. 针对Android的性能优化集中哪些方面

一、概要：

本文主要以Android的渲染机制、UI优化、多线程的处理、缓存处理、电量优化以及代码规范等几方面来简述Android的性能优化

二、渲染机制的优化：

大多数用户感知到的卡顿等性能问题的最主要根源都是因为渲染性能。

Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染， 如果每次渲染都成功，这样就能够达到流畅的画面所需要的60fps，为了能够实现60fps，这意味着程序的大多数操作都必须在16ms内完成。

*关于JobScheler的更多知识可以参考http://hukai.me/android-training-course-in-chinese/background-jobs/scheling/index.html

七、代码规范

1）for loop中不要声明临时变量，不到万不得已不要在里面写try catch。

2）明白垃圾回收机制，避免频繁GC，内存泄漏，OOM(有机会专门说)

3）合理使用数据类型，StringBuilder代替String，少用枚举enum，少用父类声明(List,Map)

4）如果你有频繁的new线程，那最好通过线程池去execute它们，减少线程创建开销。

5）你要知道单例的好处，并正确的使用它。

6）多用常量，少用显式的"action_key"，并维护一个常量类，别重复声明这些常量。

7）如果可以，至少要弄懂设计模式中的策略模式，组合模式，装饰模式，工厂模式，观察者模式，这些能帮助你合理的解耦，即使需求频繁变更，你也不用害怕牵一发而动全身。需求变更不可怕，可怕的是没有在写代码之前做合理的设计。

8）View中设置缓存属性.setDrawingCache为true.

9）cursor的使用。不过要注意管理好cursor,不要每次打开关闭cursor.因为打开关闭Cursor非常耗时。Cursor.require用于刷cursor.

10）采用SurfaceView在子线程刷新UI,避免手势的处理和绘制在同一UI线程（普通View都这样做）

11）采用JNI，将耗时间的处理放到c/c++层来处理

12）有些能用文件操作的，尽量采用文件操作，文件操作的速度比数据库的操作要快10倍左右

13）懒加载和缓存机制。访问网络的耗时操作启动一个新线程来做，而不要再UI线程来做

14）如果方法用不到成员变量，可以把方法申明为static，性能会提高到15%到20%

15）避免使用getter/setter存取field，可以把field申明为public，直接访问

16）私有内部类要访问外部类的field或方法时,其成员变量不要用private，因为在编译时会生成setter/getter,影响性能。可以把外部类的field或方法声明为包访问权限

17）合理利用浮点数，浮点数比整型慢两倍

18）针对ListView的性能优化，ListView的背景色与cacheColorHint设置相同颜色，可以提高滑动时的渲染性能。ListView中getView是性能是关键，这里要尽可能的优化。

getView方法中要重用view；getView方法中不能做复杂的逻辑计算，特别是数据库操作，否则会严重影响滑动时的性能

19）不用new关键词创建类的实例，用new关键词创建类的实例时，构造函数链中的所有构造函数都会被自动调用。但如果一个对象实现了Cloneable接口，我们可以调用它的clone()方法。

clone()方法不会调用任何类构造函数。在使用设计模式（Design Pattern）的场合，如果用Factory模式创建对象，则改用clone()方法创建新的对象实例非常简单。例如，下面是Factory模式的一个典型实现：

20）public static Credit getNewCredit() {
return new Credit();
}
改进后的代码使用clone()方法，如下所示：
private static Credit BaseCredit = new Credit();
public static Credit getNewCredit() {
return (Credit) BaseCredit.clone();
}
上面的思路对于数组处理同样很有用。

21）乘法和除法

考虑下面的代码：

22）ViewPager同时缓存page数最好为最小值3，如果过多，那么第一次显示时，ViewPager所初始化的pager就会很多，这样pager累积渲染耗时就会增多，看起来就卡。

23）每个pager应该只在显示时才加载网络或数据库(UserVisibleHint=true)，最好不要预加载数据，以免造成浪费

24）提高下载速度：要控制好同时下载的最大任务数，同时给InputStream再包一层缓冲流会更快(如BufferedInputStream)

25）提供加载速度：让服务端提供不同分辨率的图片才是最好的解决方案。还有合理使用内存缓存，使用开源的框架

引用：Android性能优化的浅谈