背景
在当下挪动互联网后半场，手机曾经是人手必备的设施。App是离用户最近的利用，界面又是最直观影响用户体验的要害局部，其晦涩度间接影响用户对产品的评估和留存。
技术是服务于人的，如果技术无奈给你带来良好的体验，那技术自身的存在就具备争议。
所以界面性能是至关重要的，不可漠视。
实际过程
布局代码是最根底的，但也是最重要的。
首先咱们看个简略小案例
不同深浅的色彩来示意适度绘制：
没色彩：没有适度绘制，即一个像素点绘制了 1 次，显示利用原本的色彩；
蓝色：1倍适度绘制，即一个像素点绘制了 2 次；
绿色：2倍适度绘制，即一个像素点绘制了 3 次；
浅红色：3倍适度绘制，即一个像素点绘制了 4 次；
深红色：4倍适度绘制及以上，即一个像素点绘制了 5 次及以上；
如何渲染界面
CPU(中央处理器) :咱们常常听到，是计算机的外围器件，多缓存多分支,实用于简单的逻辑运算,次要负责Measure，Layout，Record，Execute的计算操作
GPU(图像处理器):咱们通常说的显卡外围就是它了。用于构造繁多的数据处理（善于图形计算），次要负责Rasterization(栅格化)操作
谷歌官网对于晦涩度的优化也是高度重视的，有界面渲染三外围Vsync、Triple Buffer和Choreographer。
为何是16ms/为何每秒60帧
android零碎每隔16ms绘制一帧UI且要在16ms内实现，（ 1秒 / 0.016帧每秒 = 62.5帧/秒 ）差不多每秒更新60次。这是因为咱们大脑和眼睛个别看24Fps的画面就曾经是间断的静止了，看60Fps的画面更看不出端倪，然而60帧能够表白出更加绚丽多彩的内容。
一旦没及时绘制，就会呈现掉帧问题，也就是常说的卡顿。这是因为绘制的货色太多的话，CPU、GPU解决不及时。
当然了，设施性能越好，解决能力越强，卡顿会越少，玩游戏的电脑配置高也是出于这方面思考。
那么Android是如何把图像绘制到界面上的呢？
这就用到了下面的CPU/GPU。
GPU负责栅格化操作（Resterization），栅格化是绘制那些Button，Shape，Path，String，Bitmap等组件最根底的操作。它把那些组件拆分到不同的像素上进行显示。这是一个很“费时”的操作（相比人类工夫只是眨眼的功夫），GPU的引入就是为了放慢栅格化的操作。
CPU负责把UI组件计算成Polygons，Texture纹理，而后交给GPU进行栅格化渲染。流程如下：
为了可能使得App晦涩，咱们须要在每一帧16ms以内解决完所有的CPU与GPU计算，绘制，渲染等等操作。
有趣味更深层学习的，能够去看看界面渲染容器DisplayList
什么是适度绘制
Overdraw(适度绘制)形容的是屏幕上的某个像素在同一帧的工夫内被绘制了N次。然而咱们只能看到最上层的UI，这就会导致多层次的UI界面除最上层外对用户都是不可见的，这样就会节约大量的CPU以及GPU资源，节约可耻。
这就像咱们在纸上固定区域一直图画，然而有最上层最靠近你，其余层有个鬼用？
如何查看绘制维度
开发工具有Hierarchy View、Systrace、Track等
真机在开发者选项中有：调试GPU绘制、硬件层更新、GPU视图更新等等
界面优化
在编写Android布局时总会遇到这样或者那样的痛点，比方：
- 1.有些布局的在很多页面都用到了，而且款式都一样，每次用到都要复制粘贴一大段，有没有方法能够复用呢？
- 2.解决了1中的问题之后，发现复用的布局里面总要额定套上一层布局，要晓得布局嵌套是会影响性能的呐；
- 3.有些布局只有用到时才会显示，然而必须提前写好，尽管设置了为invisible或gone，还是多多少少会占用内存的。
首先第一点也是最重要的一点，在刚开始写布局的时候肯定要提前想好和布局好，尽可能的缩小层级的嵌套。往往越简单的布局越臃肿，越容易被忽视进而呈现性能问题，所以咱们写布局就要晓得一些技巧来展现布局
- 1. 如果图片和文字在一起且文字不动静变的话，能够间接应用带文字的图片。
- 2. 移除没用的布局和控件，假如增加个背景，尽可能在曾经布局上放，缩小只有背景性能的控件。
- 3. 缩小透明度的应用，假如：#55FFFFFF 和 #888888 色彩相似，倡议应用后者，因为前者有Alpha，view须要至多绘制两次。
- 4. 去掉多余的不可见色彩背景、图片等，只保留最上层用户可见即可
- 5. 缩小布局层次结构，防止多层嵌套举荐应用RelativeLayout、ConstraintLayout等父类布局
- 6. 根本控件LinearLayout 性能比RelativeLayout高一些，要提前依据UI想好哪个布局更适合，要有的形式，隔靴搔痒。
- 7. 自定义View尽可能只更新渲染部分区域，杜绝一直全部重绘。
- 8. 举荐应用IDE自带的Lint或者阿里代码查看插件，对于标黄正告等提醒器重起来，能改的就改。
除了以上，咱们就要解决适度绘制，咱们还能够应用形象布局，它们别离是include、merge和ViewStub三个标签，当初咱们就来意识意识它们吧。
Include应该是最罕用的了，其翻译是“蕴含”、“包含”，最佳应用就是把雷同代码抽离进去成一个独立的xml文件，当你在某个布局须要应用的时候间接include进来，这样一搞，很好地起到复用布局的成果。不仅能够极大地缩小代码量，想要批改的话间接改这一个xml就行了。
它的两个次要属性：layout：必填属性， id属性；
咱们还能够重写宽高、边距和可见性（visibility）这些布局属性。然而肯定要留神，单单重写android:layout\_height或者android:layout\_width是不行，必须两个同时重写才起作用。
这些也能玩不不少花色。
Merge介绍
凡事都有利有弊include标签除了下面的长处，也有个问题就是布局嵌套。他必须有一个根布局，这也导致了最终布局嵌套层级可能多一层。
这时候又引出个新的标签标签，这次先说他的局限性：就是你须要提前明确要放到什么父布局中，而后提前设置好merge外面的控件地位。
长处也显著：他是打消多余层级的，标签必须作为根节点呈现。不占用空间，他只是将子view“搬运”到你想嵌套的地位。
ViewStub
写布局的时候咱们常常会遇到有些成果不用始终显示，须要动静的来设置invisible或gone，这无形中影响了页面加载速度。
Android提供的计划就是ViewStub，他是一个不可见的大小为0的视图，具备懒加载性能，存在于视图中，但只有设置setVisibility()和inflate()办法调用后才会渲染填充视图，能为初始化加载xml布局扩散压力，就像负载平衡。
应用案例：进度条，加载网络失败，显示谬误音讯等等
它有以下三个重要属性：
android:layout：ViewStub须要填充的视图名称，为“R.layout.xx”的模式；
android:inflateId：重写被填充的视图的父布局id。
与include标签不同，ViewStub的android:id属性是设置ViewStub自身id的，而不是重写布局id，这一点可不要搞错了。另外，ViewStub还提供了OnInflateListener接口，用于监听布局是否曾经加载了。
然而留神 viewStub.inflate();办法不能屡次调用，否则抛出异样：
java.lang.IllegalStateException: ViewStubmusthaveanon-nullViewGroupviewParent
起因是ViewStub源码调用了removeViewInLayout()办法把本人从布局移除了。到这里咱们就明确了，ViewStub在填充布局胜利之后就会自我销毁，再次调用inflate()办法就会抛出IllegalStateException异样了。此时如果想要再次显示布局，能够调用setVisibility()办法。
还有一个大坑：viewStub.getVisibility()的值始终为0，所以用他来判断是否显示没作用。不要急，其实是setVisibility()办法实际上在设置外部视图的可见性，而不是ViewStub自身。
硬件加速原理
置信常常看到有的文章说开启硬件加速解决卡的问题，但硬件加速是什么呢？
硬件加速的次要原理是通多底层逻辑，将CPU不善于的图形计算转换成GPU专用指令，让更善于图形计算的GPU来实现渲染。
硬件加速过程中蕴含两个步骤 ：
构建阶段 ： 遍历所有视图，将须要绘制的操作缓存下来，交给独自的Render线程应用GPU进行硬件加速渲染。(这一阶段在主线程中应用CPU构建)
绘制阶段 ： 调用OpenGL（即应用GPU）对构建好的视图进行绘制渲染，绘制的内容保留在Graphic Buffer 并交由 SurfaceFlinger 显示。(Android 5.0+ 应用Render Thread线程，专门负责 UI 渲染和动画显示。)
以上证得硬件加速具备不错的长处，但它不是万能的。
咱们平时用的时候可能是间接在Application中用，一锅端，这并不谨严，因为硬件加速还没法做到反对所有的绘制操作（比方简单的自定义View），这样的话就会造成肯定的影响：
1. 像素错位等视觉问题
2. 不同设施版本API兼容问题
解决这些问题官网给了解决方案：应用四种级别管制是否硬件加速。
1. Application
2. Activity-为独自页面设置
3. Window级别
4. 独自的view级别敞开减速（View目前不反对动静启动硬件加速）