前言

 卡顿是在用户使用过程中很直观的不良感受，主要分为由代码、内存不足等问题引起的常规卡顿和ANR异常，我们可以利用线上和线下相结合的方式全覆盖监测卡顿点，还要特别针对一些不易监测到的难点进行优化。

---

1 手动监测

 手动监测方案可以查看Android性能优化之启动优化工具（TraceView、Systrace、Profiler），核心思想就是通过计算方法耗时、查看CPU的使用情况等去找到卡顿的地方并解决问题。

---

2 自动监测

2.1 StrictMode

 如果开发者在UI线程中进行了网络操作或者IO操作，而这些操作可能会影响到App的性能，甚至出现ANR对话框。Android提供了一种运行时检测机制，主要用于检测两大问题：
一、线程策略
自定义的耗时调用，detectCustomSlowCalls()
磁盘读取操作，detectDiskReads
网络请求，detectNetwork
二、虚拟机策略
Activity泄露，detectActivityLeaks()
Sqlite对象泄露。detectLeakedSqliteObjects
检测实例数量，setClassIntancceLimit()

2.2 StrictMode实战

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        initStrictMode(true)
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        writeToExternalStorageInMainThread()//模拟Closable对象未关闭
    }
    fun writeToExternalStorageInMainThread() {
        val externalStorage: File = Environment.getExternalStorageDirectory()
        val destFile = File(externalStorage, "hello.txt")
        try {
            val output: OutputStream = FileOutputStream(destFile, true)
            output.write("I am testing io".toByteArray())
            output.flush()
            output.close()
        } catch (e: FileNotFoundException) {
            e.printStackTrace()
        } catch (e: IOException) {
            e.printStackTrace()
        }
    }

    private fun initStrictMode(isDebug: Boolean) {
        if (isDebug) {
            StrictMode.setThreadPolicy(
                StrictMode.ThreadPolicy.Builder()
                    .detectCustomSlowCalls()//API 11
                    .detectDiskReads()
                    .detectDiskWrites()
                    .detectNetwork() //or .detectAll()
                    .penaltyLog()//在Logcat 中发音违规异常信息  or .penalDialog()
                    .build()
            )
            StrictMode.setVmPolicy(
                StrictMode.VmPolicy.Builder()
                    .detectLeakedSqlLiteObjects()
                    .setClassInstanceLimit(ExplainAction::class.java, 1)
                    .detectActivityLeaks()
                    .detectLeakedClosableObjects()//监测Closable对象
                    .penaltyLog()
                    .build()
            )
        }
    }
}
#

 我们可以通过使用StrictMode进行实例监测、或者内存泄露监测等等，这些问题都是可能引起卡顿的问题点。上面运行代码之后可以在Logcat里看到错误的堆栈信息：

错误日志

---

3 Looper

 利用UI线程中，事件发生时Looper.loop会执行dispatchMessage的原理，如果UI线程发生卡顿，即dispatchMessage发生了卡顿。因此我们可在分发消息前和分发消息后时间间隔与我们设置的阈值对比，实现卡顿自动化监测。

public static void loop() {
    final Looper me = myLooper();
    final MessageQueue queue = me.mQueue;
    for (;;) {
        Message msg = queue.next(); 
        //可替换成自己的Printer
        Printer logging = me.mLogging;
        //1.消息分发前打印日志
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }
        //2.消息分发
        msg.target.dispatchMessage(msg);
        //3.消息分发后打印日志
        if (logging != null) {
            logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
        }
        }
        msg.recycleUnchecked();
    }
}

 记录事件发生前后的事件，并与阈值进行对比。

package com.example.myapplication

import android.os.Looper
import android.util.Log

class LogMonitor{
    companion object{
        var thresholdTime = 100;
        private var isStart = true
        private var mStartTime = 0L;
        private var mEndTime = 0L;
        fun recordTime(){
            if (isStart){
                mStartTime = System.currentTimeMillis();
                isStart = false
            }else{
                mEndTime = System.currentTimeMillis()
                isStart = true
                if (isBlock(mEndTime)){
                    Log.d("LogMonotor","发生卡顿了。。。")
                }
            }
        }

        private fun isBlock(endTime:Long):Boolean{
            return endTime- mStartTime> thresholdTime
        }
    }
}

 在Application的Oncreate中实现对Printer的替换。

class MyApplication: Application() {
    override fun onCreate() {
        super.onCreate()
        mainLooper.setMessageLogging {
            LogMonitor.recordTime()
        }
    }
}

 我们还可以使用第三方库AndroidPerformanceMonitor进行卡顿监测。AndroidPerformanceMonitor就是利用了以上所述相同的原理。
 我们可以利用此方法频繁采集堆栈信息，并将超过阈值的堆栈存入文件中上传给服务器，在上传前对文件进行Hash排重处理。文件过大是首先可将文件拆分，然后使用Hash除余将相同的的堆栈放入一个文件进行排重，最后合并文件上传。

---

总结

 造成卡顿的主要原因有以下几点：
1.过于复杂的布局
原因：UI布局层次太深, 或是自定义控件的onDraw中有复杂运算, CPU的相关运算就可能大于16ms, 导致卡顿。
解决方案：可通过Android Studio的Layout Inspector去查看层级，并改善层级深度，在开发中建议使用ConstrainLayout改善减少层级。

2.过度绘制
原因：像素被多次绘制。
解决方案：可在开发者模式中，打开显示边界布局，查看绘制颜色。

1.原色 – 没有被过度绘制 – 这部分的像素点只在屏幕上没有绘制。
2.蓝色 – 1次过度绘制– 这部分的像素点只在屏幕上绘制了一次。
3.绿色 – 2次过度绘制 – 这部分的像素点只在屏幕上绘制了二次。
4.粉色 – 3次过度绘制 – 这部分的像素点只在屏幕上绘制了三次。
5.红色 – 4次过度绘制 – 这部分的像素点只在屏幕上绘制了四次及以上。

2.1clipRect、clipRect
 使用canvas.clipRect后，绘制区域之外的绘制指令都不会被执行，那些部分内容在矩形区域内的组件，仍然会得到绘制。
 canvas.quickreject()来判断是否没和某个矩形相交，从而跳过那些非矩形区域内的绘制操作
3. 耗时事件
原因：在UI线程中执行耗时事件，会导致UI线程loop卡顿。
解决方案：如果UI线程发生卡顿，即dispatchMessage发生了卡顿。我们可在dispatchMessage的原理分发消息前和分发消息后时间间隔与我们设置的阈值对比。
4. 频繁GC
原因：短时间内创建大量对象进入新生区，导致频繁的GC。gc会大量占用ui线程和cpu资源，会导致app整体卡顿
解决方案：使用Profiler查看CPU抖动位置，跟踪内存分配情况找到对象重复创建的对象。
5. 内存不足
原因：低内存会导致磁盘 IO 变多, 如果频繁进行磁盘 IO , 由于磁盘IO 很慢, 那么主线程会有很多进程处于等 IO 的状态。
解决方案：使用 SharedPerforence 时用 Apply而不是commit等等。
6 帧率与刷新率不匹配
原因：屏幕帧率和系统的 fps 不相符 , 那么有可能会导致画面不是那么顺畅. 比如使用 90 Hz 的屏幕搭配 60 fps 的动画
解决方案：使用以下代码获取屏幕刷新率，根据屏幕刷新率进行动画计算。

Display display = getWindowManager().getDefaultDisplay();
float refreshRate = display.getRefreshRate();

 除以上问题外，造成卡顿的原因还有GPU频繁渲染、频繁调用 buildDrawingCache、使用CPU渲染而不是使用GPU、WebView 性能不足等等问题都会造成卡顿。