[源码]从CoordinatorLayout到集合中通信

本文深入探讨CoordinatorLayout的设计理念,包括其使用Mediator模式解决子元素间通信问题,以及利用Decor模式减少不必要的继承。同时,文章还详细介绍了其依赖管理机制及事件处理流程,帮助读者更好地理解这一组件的工作原理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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的思路。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值