性能优化之卡顿分析

顾名思义，何谓卡顿？

原理：

快速翻阅书籍的频率是12fps, 这明显感觉是不够顺滑。 24fps是电影界面切换的频率，24fps使得人眼感知的是连续线性的运动，这其实是归功于运动模糊的效果。24fps是电影胶圈通常使用的帧率，因为这个帧率已经足够支撑大部分电影画面需要表达的内容，同时能够最大的减少费用支出。但是低于30fps是无法顺畅表现绚丽的画面内容的，此时就需要用到60fps来达到想要的效果，当然超过60fps是没有必要的。

Android系统早期有两个缓冲区，我们就用A，B来表示。当a缓存出来的数据，被系统展示的时候，B就去缓存数据；当B缓存出来了下一帧，系统就展示B的数据，这时候A就去缓存数据。那么，这就需要我们在规定的时间16.666ms将数据缓存完成。

那么，问题来了。如果我们因为种种原因，无法在16.666ms完成任务，表现在用户面前的，就是我们常说的卡顿现象。

导致卡顿的可能点：

首先我们分析分析有哪些点会导致卡顿？

1.重复绘制，通过开发者选项排查

2.层次复杂，嵌套多层。通过include,viewstub，merge属性来应对。

include
比如标题栏actionBar，可以抽取出来。该布局几乎大多数activity都会用到

ViewStub
这个标签最大的优点是当你需要时才会加载，使用他并不会影响UI初始化时的性能。各种不常用的布局想进度条、显示错误消息等可以使用这个标签，以减少内存使用量，加快渲染速度。

merge
这个标签在UI的结构优化中起着非常重要的作用，它可以删减多余的层级，优化UI。但是就有一点不好，无法预览布局效果

 

3.主线程耗时操作，一般情况表现为卡顿，严重的会引发ANR。

4.频繁GC，比如ondraw中高频使用的对象，快速创建又快速销毁。

 

导致ANR的几个原因：

1.输入事件(按键和触摸事件)5s内没被处理: Input event dispatching timed out

2.BroadcastReceiver的事件(onRecieve方法)在规定时间内没处理完(前台广播为10s，后台广播为60s)：Timeout of broadcast BroadcastRecord

3.service 前台20s后台200s未完成启动 Timeout executing service

4.ContentProvider的publish在10s内没进行完：timeout publishing content providers

 系统是如何实现anr机制的：

1.在进行相关操作调用hander.sendMessageAtTime()发送一个ANR的消息，延时时间为ANR发生的时间(如前台Service是当前时间20s之后)。

2.进行相关的操作

3.操作结束后向remove掉该条message。如果相关的操作在规定时间没有执行完成，该条message将被handler取出并执行，就发生了ANR。

 

如何降低ANR的概率：
有一些操作是很危险的，非常容易发生ANR，在写代码时候一定要避免：

1.主线程读取数据：在Android中主线程去读取数据是非常不好的，Android是不允许主线程从网络读数据的，但系统允许主线程从数据库或者其他地方获取数据，但这种操作ANR风险很大，也会造成掉帧等，影响用户体验
      （1）. 避免在主线程query provider，首先这会比较耗时，另外这个操作provider那一方的进程如果挂掉了或者正在启动，我们应用的query就会很长时间不会返回，我们应该在其他线程中执行数据库query、provider的query等获取数据的操作。
     （2）. sharePreference的调用：针对sharePreference的优化点有很多，

                第一，首先sharePreference的commit()方法是同步的，apply()方法一般是异步执行的。所以在主线程不要用其commit()，用apply()替换。

                第二，其次sharePreference的写是全量写而非增量写，所以尽量都修改完同一apply，避免改一点apply一次，因为在Activity 进入stop状态的时候主线程会等待写入完成，提交多次就很容易卡。

                第三，存储文本也不宜过大，这样会很慢。另外，如果写入的是json或者xml，由于需要加和删转义符号，速度会比较慢。

2.不要在broadcastReciever的onRecieve()方法中干活，这一点很容易被忽略，尤其应用在后台的时候。为避免这种情况，一种解决方案是直接开的异步线程执行，但此时应用可能在后台，系统优先级较低，进程很容易被系统杀死，所以可以选择开个IntentService去执行相应操作，即使是后台Service也会提高进程优先级，降低被杀可能性。

3.各个组件的生命周期函数都不应该有太耗时的操作，即使对于后台Service或者ContentProvider来讲，应用在后台运行时候其onCreate()时候不会有用户输入引起事件无响应ANR，但其执行时间过长也会引起Service的ANR和ContentProvider的ANR。

4.尽量避免主线程的被锁的情况，在一些同步的操作主线程有可能被锁，需要等待其他线程释放相应锁才能继续执行，这样会有一定的ANR风险，对于这种情况有时也可以用异步线程来执行相应的逻辑。另外， 我们要避免死锁的发生(主线程被死锁基本就等于要发生ANR了)。