CoordinatorLayout是个挺古老的东西了,然而我才听说,愧为程序员。看一下源码,缓解一下。
一个ViewGroup,也没啥设计思路可说的,无非是:使用Mediator模式解决了集合中子元素的随意通信问题(DependOn),用Decor模式解决了无谓继承的问题(代理给出了不少View的onXXX方法)。这种高层次的思路了。
合理设计
- 做依赖,一定都形成DAG,有一个DirectedAcyclicGraph类,专门干这个的。在design包中
DirectedAcyclicGraph
细节
- 所有touch事件按序优先传给Behavior,这里是所有的View。View的接收的顺序不再是传统事件传递的链路,而是:
- isChildrenDrawingOrderEnabled == true时,getChildDrawingOrder
- view的添加顺序
- PreDraw时会触发ViewChanged,这其实很偷巧。因为所有变化都会导致Draw,那么preDraw就可以非常简单的hook掉所有变化
- DirectedAcyclicGraph使用邻接表表示图
- DFS遍历相当于树的后序遍历,根最后打印
思考
那是不是所有这类问题都可以用贴一个(多个)Behavior在子元素上来做呢,比如说嵌套的Fragment?在我看来,并不是。
ViewGroup能够做这件事,是因为:
- 所有子View的状态变化,是可以自动反映到一个hook上(PreDraw)。任何需要手动触发的多点hook都容易搞出问题来,而且对子元素的实现提出了非常高的要求
- 子View的接口非常丰富,而更多的情况下,特别是Fragment这种,很难有合理的对外接口给出来,导致使用困难。当然CoordinatorLayout的各种例子中,也是通过类型强转做了一些事情
也就是说,当且仅当子元素无需手动触发一个事件且子元素通信非常统一的情况下,才适合直接套用CoordinatorLayout的思路。