技术管理篇5一技术演变史(2)

昨天我们聊了UI绘制的设计模式，通过消息机制，优雅的隔离了操作系统和各个软件实现之间的耦合。今天我们继续聊一下组件设计模式，怎么让我们更进一步摆脱大部分绘制的工作，专注在业务本身。

让我们以安卓的组件体系为例，下图是安卓UI组件体系的逻辑图。

图1-安卓UI组件关系图(注：图来自于网络)

篇幅有限，我们只集中聊整体的架构，其中的细节，大家可以去查看源代码继续研究。我们可以看到，按照面向对象的思路出发，每个界面上的绘制单元我们可以抽象成一个View类，View类描绘了每个UI组件基本的方法和属性，最基本的方法有三个，一个是要能绘制自己的OnDraw方法，一个是要能计算占位大小的onMeasure方法，最后一个是接收UI事件消息的方法。ViewGroup是组合控件的抽象类，他描述了组件之间的父子关系。

通过这样的方式，我们就可以把UI展现抽象成一个View的树状结构，在安卓当中，这个树顶就是ContentView，如下图所示。

图2-安卓UI结构图(注：图来自于网络)

ContentView中就会有多个子View，子View还可能再有多个子View，就形成了树状结构。通过这种方式，我们就可以把上一篇中讲到的UI主线程复杂逻辑隐藏掉。我们可以在安卓Window抽象类中来实现UI主线程Loop（这里简化了很多细节），当设定ContentView后，UI主线程Loop就会遍历ContentView的树，依次调用View的计算占位大小的方法，View再调用自己的子View，从而完成整个ContentView的Layout布局计算，布局计算完成后，再依次调用子View的绘制方法完成整个UI的绘制。当有UI事件发生的时候，UI主线程Loop会根据子View的占位和显示层级来判断哪个View来接收这个消息，View接收到消息后，会根据情况选择是否向父View传递消息。

我们可以看到，通过这个过程，就将复杂的UI主线程彻底隐藏起来。我们跟UI的交互，也变成了跟各个控件View的交互，使得事情变得简单起来，我们只需要专注业务代码的编写就好。当然，还是有一个漏洞无法隐藏，就是业务线程代码是不能跨线程直接访问View的，我们来看看安卓是怎么解决的。

如下图，安卓通过Handler、MessageQueen机制来实现跨线程对View的访问。下面我们来详细说说。

图3-安卓Handler机制(注：图来自网络)

图中的Looper就是我们所说的UI主线程Loop，他负责和操作系统打交道，完成UI绘制和事件分发。这里请允许我简化来说，涉及到安卓和底层Linux的协作机制，我们先略过。这个Looper会一直监听MessageQueen，接收其他业务线程对UI的操作消息。那其他业务线程是如何把消息发送到Queen里呢，这就通过Handler来完成。Handler如何Looper联系起来的呢，答案是ThreadLocal。

我们来串一下整个过程，首先，我们在UI主线程里创建Handler对象，切记要在主线程里创建，因为这时候，Handler会在当前线程的ThreadLocal里获取Looper对象。如果在业务线程中创建Handler对象，就没法和Looper对象建立关联了。

然后，当我们在业务线程里，对View进行操作的时候，我们可以给Handler发送消息就可以。此时的Handler在创建的时候就拿到了UI主线程Looper，他就可以往MessageQueen中放入消息了。

到此，安卓整个UI组件机制我们就说完了，当然，其间很多细节我们略过了，有兴趣的朋友可以再去详细研究。其实不光在安卓中，其他的语言，比如.Net、Java、IOS等，都有类似的实现。平时大多数的控件就足够我们使用，如果有特殊的需求，我们还可以自己继承View，对组件做扩展。组件化的封装也带来可视化设计的可能，拖拽的方式极大了提升了界面编写的效率。你看好的设计模式就是如此优雅，历久弥新，始终在继承和演化中。

另外，我们也可以看到，UI的嵌套层次越少，绘制效率就越高。尤其是不同的Layout组合使用的时候，某个子View的大小改变，因为需要重新排版Layout，可能会导致整个父View的重新绘制，如果层次过于复杂，这就会造成整个界面的卡顿现象。当然，在性能足够的PC上可能没有这么严重，但是，手机上会特别突出。安卓其实也提供了不少工具让我们排查这类问题，大家可以继续去研究。