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

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

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


技术管理篇5一技术演变史(2)_第1张图片
图1-安卓UI组件关系图(注:图来自于网络)

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

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


技术管理篇5一技术演变史(2)_第2张图片
图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的访问。下面我们来详细说说。


技术管理篇5一技术演变史(2)_第3张图片
图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上可能没有这么严重,但是,手机上会特别突出。安卓其实也提供了不少工具让我们排查这类问题,大家可以继续去研究。

你可能感兴趣的:(技术管理篇5一技术演变史(2))