前言
Android开发中卡顿问题一直是个比较棘手又重要的问题，严重影响用户体验；卡顿是人的一种视觉感受，比如我们滑动界面时，如果滑动不流畅我们就会有卡顿的感觉，这种感觉我们需要有一个量化指标，在编程时如果开发的程序超过了这个指标我们认为其是卡顿的
开发app的性能目标就是保持60fps，这意味着每一帧你只有16ms≈1000/60的时间来处理所有的任务；Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需要的60fps
什么是卡顿呢?
安卓APP卡顿问题，就是UI渲染过慢;如果计算跟绘制，让界面的帧率在1秒内达到60fps，APP视觉效果当然达到自然流畅；可如果在16ms内不能完成界面的渲染，占了下n个16ms的时间，相当于丢了n帧，丢帧的产生就会造成应用卡顿现象的出现，严重影响了用户体验感，这是开发者必须要重视的问题
APP中主要表现在页面的刷新，滑动时的流畅度;例如玩游戏的时候卡，或者听歌的时候画面滞帧，也就是通常人们所说的“卡”；开发者中有一个卡顿16ms原则，每一帧渲染时间不能超过16ms，应达到60帧每秒，如果UI渲染过慢，就会发生丢帧，丢帧的出现就会产生画面的不连贯性，就是卡顿
什么是过度绘制？
Overdraw(过度绘制)描述的是屏幕上的某个像素在同一帧的时间内被绘制了N次;但是我们只能看到最上层的UI，这就会导致多层次的UI界面除最上层外对用户都是不可见的，这样就会浪费大量的CPU以及GPU资源，浪费可耻
这就像我们在纸上固定区域不断图画，但是有最上层最接近你，其他层有个鬼用？
解决过度绘制
● 我们在写RecyclerView的时候，如果RecyclerView的父布局、RecyclerView、item三者的背景只要其中一个设置就可以了，没有设置背景就不会渲染，否则就会有过度绘制的情况
● 父布局套子布局也是尽量只设置其中一个背景，除非没办法都需要背景
● 子view一般绘制后是会覆盖父view，所以一般选择把背景设置在子view
● 视图的层级结构能减少就减少，层级越多绘制速度越慢
● 尽量少设置view的透明度，如果一个view设置了alpha，那他需要知道下面的view是什么内容，再绘制自己，就是过度绘制。如果是文字有透明度，可以在色号里就设置好
如何查看绘制维度
● 开发工具有Hierarchy View、Systrace、Track等
● 真机在开发者选项中有：调试GPU绘制、硬件层更新、GPU视图更新等等
界面优化
在编写Android布局时总会遇到这样或者那样的痛点，比如：
● 有些布局的在很多页面都用到了，而且样式都一样，每次用到都要复制粘贴一大段，有没有办法可以复用呢？
● 解决了问题之后，发现复用的布局外面总要额外套上一层布局，要知道布局嵌套是会影响性能的呐
● 有些布局只有用到时才会显示，但是必须提前写好，虽然设置了为invisible或gone，还是多多少少会占用内存的
首先第一点也是最重要的一点，在刚开始写布局的时候一定要提前想好和规划好，尽可能的减少层级的嵌套
往往越复杂的布局越臃肿，越容易被忽视进而出现性能问题，所以我们写布局就要知道一些技巧来展示布局
● 如果图片和文字在一起且文字不动态变的话，可以直接使用带文字的图片
● 移除没用的布局和控件，假设添加个背景，尽可能在已经布局上放，减少只有背景功能的控件
● 减少透明度的使用，假设：#55FFFFFF 和 #888888 颜色类似，建议使用后者，因为前者有Alpha，view需要至少绘制两次
● 去掉多余的不可见颜色背景、图片等，只保留最上层用户可见即可
● 减少布局层次结构，避免多层嵌套推荐使用RelativeLayout、ConstraintLayout等父类布局
● 基本控件LinearLayout 性能比RelativeLayout高一些，要提前根据UI想好哪个布局更合适，要有的方式，对症下药
● 自定义View尽可能只更新渲染局部区域，杜绝不断全部重绘
● 推荐使用IDE自带的Lint或者阿里代码检查插件，对于标黄警告等提示重视起来，能改的就改
除了以上，我们就要解决过度绘制，我们还可以使用抽象布局，它们分别是include、merge和ViewStub三个标签，现在我们就来认识认识它们吧
● Include应该是最常用的了，其翻译是“包含”、“包括”，最佳使用就是把相同代码抽离出来成一个独立的xml文件，当你在某个布局需要使用的时候直接include进来，这样一搞，很好地起到复用布局的效果。不仅可以极大地减少代码量，想要修改的话直接改这一个xml就行了
● 它的两个主要属性：layout：必填属性， id属性
我们还可以重写宽高、边距和可见性（visibility）这些布局属性。但是一定要注意，单单重写android:layout_height或者android:layout_width是不行，必须两个同时重写才起作用
引起应用卡顿的原因
UI造成的卡顿
● 过度绘制:就是在同一帧情况下对同一块像素区域进行重复绘制。这样会加重GPU跟CPU的渲染压力，导致渲染时间过长
● 布局嵌套过多；布局嵌套过多过于复杂也会导致CPU跟GPU的渲染，计算，绘制压力
动画执行次数过多
● 执行耗时操作;文件读写，数据操作，较大数据初始化等较为耗时的操作阻塞线程
● 频繁GC;执行GC的时候，所有操作都需要暂停，等到GC结束后，才能继续执行操作。这样就可能会阻塞CPU跟GPU的渲染，计算跟绘制
UI优化
● 多余Bg移除
● ui重叠区域优化 cancas.clipRect
● 减少ui层级
● 耗时方法分析与优化
● 多样式布局采用单一rv处理
卡顿优化
Android 应用启动慢，使用时经常卡顿，是非常影响用户体验的，应该尽量避免出现。卡顿的场景有很多，按场景可以分为4类：UI 绘制、应用启动、页面跳转、事件响应，如图：
这4种卡顿场景的根本原因
界面绘制
● 主要原因是绘制的层级深、页面复杂、刷新不合理，由于这些原因导致卡顿的场景更多出现在 UI 和启动后的初始界面以及跳转到页面的绘制上。
数据处理
● 导致这种卡顿场景的原因是数据处理量太大，一般分为三种情况，一是数据在处理 UI 线程，二是数据处理占用 CPU 高，导致主线程拿不到时间片，三是内存增加导致 GC 频繁，从而引起卡顿。=
引起卡顿的原因很多，但不管怎么样的原因和场景，最终都是通过设备屏幕上显示来达到用户，归根到底就是显示有问题
影响绘制的根本原因
● 绘制任务太重，绘制一帧内容耗时太长
● 主线程太忙，根据系统传递过来的 VSYNC 信号来时还没准备好数据导致丢帧
● 绘制耗时太长，可利用工具帮助我们定位问题（这里推荐使用友盟+u-apm应用性能监控平台）
● 主线程太忙则需要注意了，主线程关键职责是处理用户交互，在屏幕上绘制像素，并进行加载显示相关的数据，所以特别需要避免任何主线程的事情，这样应用程序才能保持对用户操作的即时响应。总结起来，主线程主要做以下几个方面工作：
● UI 生命周期控制
● 系统事件处理
● 消息处理
● 界面布局
● 界面绘制
● 界面刷新
除此之外，应该尽量避免将其他处理放在主线程中，特别复杂的数据计算和网络请求等
尾述
技术是无止境的，你需要对自己提交的每一行代码、使用的每一个工具负责，不断挖掘其底层原理，才能使自己的技术升华到更高的层面
Android 架构师之路还很漫长，与君共勉
PS:有问题欢迎指正,可以在评论区留下你的建议和感受；
欢迎大家点赞评论，觉得内容可以的话，可以转发分享一下
