本文首发于微信公众号「Android开发之旅」，欢迎关注

Android绘制原理

手机渲染主要依赖于两个硬件：CPU和GPU，其中CPU主要负责计算显示内容，其中包括视图创建、布局计算、图片解码和文本绘制等。GPU主要负责栅格化（UI元素绘制到屏幕上），比如将Button、Bitmap拆分成不同的像素进行显示，最后完成绘制。

手机上显示的文字就是先通过CPU换算成纹理后在交给GPU进行渲染。而图片的显示首先通过CPU进行计算，然后再加载到内存中，传给GPU进行渲染。

我们都知道Android系统每隔16ms就会发出Vsync信号（具体是由RootViewImpl类发起）触发UI渲染，即要求每一帧都要在16ms内渲染完成，所以不管你的布局逻辑多么的复杂，你都要在16ms内绘制完成，否则就会出现界面卡顿的现象。

我们市面上绝大部分Android手机的屏幕刷新频率基本都是60Hz，因为60Hz每秒是人眼和大脑之间合作的极限，就像动画每秒24帧一样。

优化工具选择

Systrace

这个我们在启动优化中讲过具体的使用，这里呢，我们主要关注他的Frames一行，显示绿色圆点表示正常，显示黄色或者红色表示出现了丢帧，出现丢帧的情况的时候我们需要去查看Alerts栏。

Layout Inspector

这个是Android Studio自带的检测工具，在Tools栏目下。它可以帮助我们查看视图的层次结构。

Android性能优化之布局优化实战 - 图1

从图中我们可以看到左侧一览显示布局的层级。

ChoreoGrapher

choreoGrapher可以帮助我们获取应用的FPS，即上文中的60Hz，并且可以线上使用，具备实时性。但是有一点需要注意的是必须API 16后使用。如下代码：

  1. private var mStartFrameTime: Long = 0
  2.     private var mFrameCount = 0
  3.     private val MONITOR_INTERVAL = 160L //单次计算FPS使用160毫秒
  4.     private val MONITOR_INTERVAL_NANOS = MONITOR_INTERVAL * 1000L * 1000L
  5.     private val MAX_INTERVAL = 1000L //设置计算fps的单位时间间隔1000ms,即fps/s;
  7.     override fun onCreate(savedInstanceState: Bundle?) {
  8.         setTheme(R.style.AppTheme)
  9.         super.onCreate(savedInstanceState)
  11.         setContentView(R.layout.activity_main)
  13.         getFPS()
  14.     }
  17.     @TargetApi(Build.VERSION_CODES.JELLY_BEAN)
  18.     private fun getFPS() {
  19.         if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN) {
  20.             return
  21.         }
  22.         Choreographer.getInstance().postFrameCallback(object : Choreographer.FrameCallback {
  23.             override fun doFrame(frameTimeNanos: Long) {
  24.                 if (mStartFrameTime == 0L) {
  25.                     mStartFrameTime = frameTimeNanos
  26.                 }
  27.                 val interval = frameTimeNanos - mStartFrameTime
  28.                 if (interval > MONITOR_INTERVAL_NANOS) {
  29.                     val fps = (mFrameCount.toLong() * 1000L * 1000L).toDouble() / interval * MAX_INTERVAL
  30.                     Log.i("fps", fps.toString())
  31.                     mFrameCount = 0
  32.                     mStartFrameTime = 0
  33.                 } else {
  34.                     ++mFrameCount
  35.                 }
  37.                 Choreographer.getInstance().postFrameCallback(this)
  38.             }
  39.         })
  42.     }

执行代码后输出：

  1. fps: 60.0158955700371
  2. fps: 60.00346688030940
  3. fps: 60.01226146521353
  4. fps: 59.98537016806971
  5. fps: 60.00205735054243

每次打印的数据都在60左右，说明页面刷新没有出现卡顿。

布局加载原理

我们经常写的XML布局文件是如何被加载的呢？又是如何显示出来的？下面就带着大家顺着源码往下看，这里就不截图了，读者朋友们看完本章后自己可以去熟悉下这块代码。

首先要从setContentView方法开始说起了，其中调用了getDeleate().setContentView(resid)方法，接着调用了 LayoutInflater.from(this.mContext).inflate(resId, contentParent)来填充布局，这个API我们大家应该都很熟悉了吧。紧接着调用getLayout方法，在getlayout方法中通过loadXmlResourceParser加载并解析XML布局文件，后面调用createViewFromTag方法，根据标签创建相对应为view，具体view的创建则是由Factory或者Factory2来完成的，首先先判断了Factory2为否为null，不为null，则用其创建view，否则就判断Factory是否为null，不为null，则由其创建。如果两个都为null，则不创建view，紧接着判断了mPrivateFactory是否为null，这里需要说明的是mPrivateFactory是一个隐藏的API只有framework才能调用，如果都没创建，那么view则由后续逻辑通过onCreateView或者createView通过反射来创建。具体流程图如下：

Android性能优化之布局优化实战 - 图2

从上面的分析中我们可以看出加载布局是有瓶颈的。其中有两个瓶颈分别是在布局文件解析的时候是一个IO过程，这肯定是比较耗时的。再一个就是最后创建View的时候是通过反射的方式进行的。既然是反射性能肯定也是有影响的，后面我们也是围绕这两点进行布局加载的优化。

获取界面布局耗时

我们做优化的前提就是得知道哪里是比较耗时的，所以检测耗时的UI还是蛮重要的。只有知道问题在哪了才能针对性的解决它。这里讲到检测耗时，读过我启动优化一文的读者肯定能想到至少两种方式，一种是手动埋点，另外一种就是AOP的方式。手动埋点呢就是在setContentView方法的前后执行的地方手动打点。

  1. override fun onCreate(savedInstanceState: Bundle?) {
  2.         super.onCreate(savedInstanceState)
  3.         LaunchRecord.startRecord()
  4.         setContentView(R.layout.activity_main)
  5.         LaunchRecord.endRecord("setContentView")
  7.     }

打印：

  1. ===setContentView===170

这种方式呢不够优雅而且对代码有侵入性。

下面我们看下AOP的方式，操作和启动优化一文中的一样。

  1. @Around("call(* android.app.Activity.setContentView(..))")
  2.     public void getSetContentViewTime(ProceedingJoinPoint joinPoint) {
  3.         Signature signature = joinPoint.getSignature();
  4.         String name = signature.toShortString();
  5.         long time = System.currentTimeMillis();
  6.         try {
  7.             joinPoint.proceed();
  8.         } catch (Throwable throwable) {
  9.             throwable.printStackTrace();
  10.         }
  11.         Log.d("ContentViewTime", name + " cost " + (System.currentTimeMillis() - time));
  12.     }

控制台打印：

  1. ContentViewTime: MainActivity.setContentView(..) cost 74

以上两种方法都是获取全部布局被加载完成后的时间，那么如果想获取单个控件的加载耗时如何做呢？这里给大家介绍LayoutInflaterCompat.setFactory2方式（大家以后看到带有Compat字段的都是兼容的API），其使用必须在super.onCreate之前调用。

  1. public class MainActivity extends AppCompatActivity {
  3.     @Override
  4.     protected void onCreate(@Nullable Bundle savedInstanceState) {
  6.         LayoutInflaterCompat.setFactory2(getLayoutInflater(), new LayoutInflater.Factory2() {
  7.             @Override
  8.             public View onCreateView(View parent, String name, Context context, AttributeSet attrs) {
  10.                 long start = System.currentTimeMillis();
  11.                 View view = getDelegate().createView(parent, name, context, attrs);
  12.                 long cost = System.currentTimeMillis() - start;
  13.                 Log.d("onCreateView", "==" + name + "==cost==" + cost);
  14.                 return view;
  15.             }
  17.             @Override
  18.             public View onCreateView(String name, Context context, AttributeSet attrs) {
  19.                 return null;
  20.             }
  21.         });
  23.         super.onCreate(savedInstanceState);
  24.         setContentView(R.layout.activity_main);
  25.     }
  26. }

控制台打印：

  1. onCreateView: ==LinearLayout=cost==16
  2. onCreateView: ==ViewStub=cost==0
  3. onCreateView: ==FrameLayout=cost==0
  4. onCreateView: ==android.support.v7.widget.ActionBarOverlayLayout=cost==0
  5. onCreateView: ==android.support.v7.widget.ContentFrameLayout=cost==0
  6. onCreateView: ==android.support.v7.widget.ActionBarContainer=cost==0
  7. onCreateView: ==android.support.v7.widget.Toolbar=cost==0
  8. onCreateView: ==android.support.v7.widget.ActionBarContextView=cost==0
  9. onCreateView: ==android.support.constraint.ConstraintLayout=cost==0
  10. onCreateView: ==TextView=cost==3
  11. onCreateView: ==ImageView=cost==24

LayoutInflaterCompat.setFactory2的API不仅仅是可以统计View创建的时间，其实我们还可以用来替换系统控件的操作，比如某一天产品经理提了一个需求要我们将应用的TextView统一改成某种样式，我们就可以使用这种方式来做。如：

  1. LayoutInflaterCompat.setFactory2(getLayoutInflater(), new LayoutInflater.Factory2() {
  2.             @Override
  3.             public View onCreateView(View parent, String name, Context context, AttributeSet attrs) {
  5.                if(TextUtils.equals("TextView",name)){
  6.                    //替换为我们自己的TextView
  8.                }
  10.                return null;//返回自定义View
  11.             }
  13.             @Override
  14.             public View onCreateView(String name, Context context, AttributeSet attrs) {
  15.                 return null;
  16.             }
  17.         });

只要我们在基类Activity的onCreate中定义这个方法，就可以实现相关效果。

布局加载优化

基于布局加载的两个性能问题，谷歌给我们提供了一个类AsyncLayoutInflater，它可以从侧面解决布局加载耗时的问题，AsyncLayoutInflater是在工作线程中加载布局，加载好后会回调到主线程，这样可以节省主线程的时间。这个类没有包含在SDK中，需要我们在gradle中配置，如：

  1. implementation 'com.android.support:asynclayoutinflater:28.0.0-alpha1'

使用：

  1. public class MainActivity extends AppCompatActivity {
  3.     @Override
  4.     protected void onCreate(@Nullable Bundle savedInstanceState) {
  6.         new AsyncLayoutInflater(MainActivity.this).inflate(R.layout.activity_main, null,
  7.                 new AsyncLayoutInflater.OnInflateFinishedListener() {
  8.             @Override
  9.             public void onInflateFinished(@NonNull View view, int i, @Nullable ViewGroup viewGroup) {
  10.                 setContentView(view); //view以及加载完成
  11.                 //可以在这里findViewById相关操作
  12.             }
  13.         });
  15.         super.onCreate(savedInstanceState);
  16.       //  setContentView(R.layout.activity_main); //这里就不用设置布局文件了
  17.     }
  18. }

我们在inflate的时候就将布局文件设置给AsyncLayoutInflater，所以下面我们就不需要在setContentView了。

上面说的AsyncLayoutInflater是从侧面解决布局加载耗时问题，那么我们如何从根本上解决这个问题呢？主要问题就是我们书写的XML文件需要加载解析和绘制，那如果我们不使用XML文件写布局文件，问题是不是就解决？在Android中，还有另外一种方式来写布局文件，那就是Java代码，通过Java代码来写布局，本质上是解决了性能问题，但是不便于开发，没有实时预览，而且可维护性太差。那么如果能有一种解决方式就是，我们开发人员还是正常写 XML文件，但是在加载的时候加载的是Java代码，那这样是不是很完美了。

所以下面给大家介绍一个新的框架：X2C，这是掌阅开源的一个框架，它保留了XML的优点，同时解决了性能问题，开发人员写XML文件，加载的时候只加载Java代码。

X2C的原理就是通过APT编译期时将XML翻译为Java代码。使用也很简单，首先gradle配置：

  1. annotationProcessor 'com.zhangyue.we:x2c-apt:1.1.2'
  2.     implementation 'com.zhangyue.we:x2c-lib:1.0.6'

Java代码使用：

  1. @Xml(layouts = "activity_main")
  2. public class MainActivity extends AppCompatActivity {
  4.     @Override
  5.     protected void onCreate(@Nullable Bundle savedInstanceState) {
  6.         super.onCreate(savedInstanceState);
  7.       //  setContentView(R.layout.activity_main); //这里就不用设置布局文件了
  8.     }
  9. }

编译之后会在build/generated/source/apt/debug/ 下面生成相关的文件。如我们的activity_main的布局文件会被翻译为：

  1. Resources res = ctx.getResources();
  3.         ConstraintLayout constraintLayout0 = new ConstraintLayout(ctx);
  5.         TextView textView1 = new TextView(ctx);
  6.         ConstraintLayout.LayoutParams layoutParam1 = new ConstraintLayout.LayoutParams(ViewGroup.LayoutParams.WRAP_CONTENT,ViewGroup.LayoutParams.WRAP_CONTENT);
  7.         textView1.setId(R.id.mTextView);
  8.         layoutParam1.topMargin= (int)(TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP,100,res.getDisplayMetrics())) ;
  9.         textView1.setText("Hello World!");
  10.         layoutParam1.leftToLeft = 0 ;
  11.         layoutParam1.rightToRight = 0 ;
  12.         layoutParam1.topToTop = 0 ;
  13.         layoutParam1.validate();
  14.         textView1.setLayoutParams(layoutParam1);
  15.         constraintLayout0.addView(textView1);
  17.         ImageView imageView2 = new ImageView(ctx);
  18.         ConstraintLayout.LayoutParams layoutParam2 = new ConstraintLayout.LayoutParams(ViewGroup.LayoutParams.WRAP_CONTENT,ViewGroup.LayoutParams.WRAP_CONTENT);
  19.         layoutParam2.topMargin= (int)(TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP,20,res.getDisplayMetrics())) ;
  20.         imageView2.setImageResource(R.mipmap.ic_launcher);
  21.         layoutParam2.leftToLeft = 0 ;
  22.         layoutParam2.rightToRight = 0 ;
  23.         layoutParam2.topToBottom = R.id.mTextView ;
  24.         layoutParam2.validate();
  25.         imageView2.setLayoutParams(layoutParam2);
  26.         constraintLayout0.addView(imageView2);

运行APP，效果也是一样的。

X2C虽好，但也有一些问题，就是部分属性Java不支持，而且失去了系统的兼容性（AppCompat）。所以如果要带到线上使用，那么就要兼容不同的版本，所以需要定制化修改源码。

视图绘制优化

我们知道视图的绘制通常经历三个阶段，测量，确定view的大小。布局，确定view的具体位置包括view和viewGroup等。绘制，将view绘制完成。不管是测量、布局还是绘制，每一个阶段都是比较耗时的，都是自上而下的遍历每一个view，在某些场景下还会触发多次，比如嵌套使用RelativeLayout布局。

所以为了减少三个阶段的耗时，我们需要减少view树的层级，不要嵌套使用RelativeLayout布局，不在嵌套使用的LinearLayout中使用weight属性。适当的使用merge标签，它可以减少一个view层级，但是必须使用在根view上。

这里推荐大家使用ConstraintLayout布局，ConstraintLayout几乎实现了完全扁平化的布局，而且在构建复杂布局上面性能更高，同时他还具备了RelativeLayout和LinearLayout的特性，使用很方便。

同时我们在书写布局的时候还要注意避免过度绘制。Android手机在开发者选项中有个功能叫：调试GPU过度绘制。打开后手机界面会有一层蒙版，其中蓝色表示可以接受，红色表色出现过度绘制了。那我们如何避免过度绘制呢？首先是去掉多余的背景色，减少复杂shape的使用，避免层级叠加，在用自定义view的时候使用ClipRect屏蔽被遮盖view的绘制。

还有其他的一些优化视图绘制，比如使用Viewstub，它是一个高效的占位符，可以用来延迟加载view布局。还有就是我们在onDraw中避免创建较大的对象和做耗时的操作等等。

总结

以上就是相关布局优化相关的操作，也是从耗时到优化各个阶段的说明和操作。读者朋友们在看完本章节后，自己动手实践下，只有实际实践了才能发现问题，加深自己印象。