嗨，好久不见！中秋节远离魔都，回了趟老家，看看山，玩玩水，权当旅游了，今归来。不知大家中秋过得如何，是否此刻感受雷同：根本无心工作学习，只想尽快为祖亲庆生。。。
回归正题，本文继续介绍MD系列控件的学习，鉴于媒体文章长度限制，关于文中提到的Nested机制，将推送至下篇文章中介绍，欢迎伙伴儿积极留言交流哈。
在MD系列的前几篇文章中，通过基础知识和实战案例配合讲解的形式介绍了CoordinatorLayout与AppBarLayout、Toolbar、CollapsingToolbarLayout的使用，并实现了几种MD风格下比较炫酷的交互效果。学会怎么用之后，我们再想想，为什么它们之间能够产生这样的交互行为呢？其实就是因为
的存在，这也是本文所要讲述的内容。至此，Android Material Design系列的学习已进行到第八篇，大家可以点击以下链接查看之前的文章：
Android TabLayout 分分钟打造一个滑动标签页
Android 一文告诉你到底是用Dialog，Snackbar，还是Toast
Android FloatingActionButton 重要的操作不要太多，一个就好
Android 初识AppBarLayout 和 CoordinatorLayout
Android CoordinatorLayout实战案例学习《一》
Android CoordinatorLayout 实战案例学习《二》
Android 详细分析AppBarLayout的五种ScrollFlags
关于Behavior
官网对于CoordinatorLayout.Behavior的介绍已经将它的作用说明得很清楚了，就是用来协调CoordinatorLayout的Child Views之间的交互行为：
Interaction behavior plugin for child views of CoordinatorLayout.
A Behavior implements one or more interactions that a user can take on a child view. These interactions may include drags, swipes, flings, or any other gestures.
之前学习CoordinatorLayout的使用案例时，用的都是系统的特定控件，比如design包中的FloatingActionButton、AppBarLayout等，而不是普通的控件，如ImageButton之类的，就是因为design包中的这些特定控件已经被系统默认定义了继承自CoordinatorLayout.Behavior的各种Behavior，比如FloatingActionButton.Behavior和
AppBarLayout.Behavior。而像系统的ToolBar控件就没有自己的Behavior，所以只能将其搁置到AppBarLayout容器里才能产生相应的交互效果。
看到这里就能清楚一点了，如果我们想实现控件之间任意的交互效果，完全可以通过自定义Behavior的方式达到。看到这里大家可能会有一个疑惑，就是CoordinatorLayout如何获取Child Views的Behavior的呢，为什么在布局中，有些滑动型控件定义了app:layout_behavior属性而系统类似FloatingActionButton的控件则不需要明确定义该属性呢？看完CoordinatorLayout.Behavior的构造函数就明白了。
CoordinatorLayout.Behavior有两个构造函数，注意看第二个带参数的构造函数的注释，里面提到，在这个构造函数中，Behavior会解析控件的特殊布局属性，也就是通过parseBehavior方法获取对应的Behavior，从而协调Child Views之间的交互行为，可以在CoordinatorLayout类中查看，具体源码如下：
parseBehavior方法告诉我们，给Child Views设置Behavior有两种方式：
app:layout_behavior布局属性
在布局中设置，值为自定义Behavior类的名字字符串（包含路径），类似在AndroidManifest.xml中定义四大组件的名字一样，有两种写法，包含包名的全路径和以”.”开头的省略项目包名的路径。
@CoordinatorLayout.DefaultBehavior类注解
在需要使用Behavior的控件源码定义中添加该注解，然后通过反射机制获取。这个方式就解决了我们前面产生的疑惑，系统的AppBarLayout、FloatingActionButton都采用了这种方式，所以无需在布局中重复设置。
看到这里，也告诉我们一点，在自定义Behavior时，一定要重写第二个带参数的构造函数，否则这个Behavior是不会起作用的。
根据CoordinatorLayout.Behavior提供的方法，这里将自定义Behavior分为两类来讲解，一种是dependent机制，一种是nested机制，对应着不同的使用场景。
dependent机制
这种机制描述的是两个Child Views之间的绑定依赖关系，对应需要实现的方法常见有两个：
和
具体含义在注释中已经很清楚了，layoutDependsOn()方法用于决定是否产生依赖行为，onDependentViewChanged()方法在依赖的控件发生大小或者位置变化时产生回调。dependent机制最常见的案例就是FloatingActionButton和SnackBar的交互行为，效果如下：
系统的FloatingActionButton已经默认定义了一个Behavior来协调交互，如果不用系统的FAB控件，比如改用GitHub上的一个库futuresimple/android-floating-action-button，再通过自定义一个Behavior，也能很简单的实现与SnackBar的协调效果：
很简单的一个自定义Behavior处理，然后再为对应的Child View设置该属性即可。由于这里我们用的是第三方库，采用远程依赖的形式引入的，无法修改源码，所以不方便使用注解的方式为其设置Behavior，所以在布局中为其设置，并且使用了省略包名的方式：
这样，采用dependent机制自定义Behavior，与使用系统FAB按钮一样，即可与SnackBar控件产生如上图所示的协调交互效果。
示例源码
我在GitHub上建立了一个Repository，用来存放整个Android Material Design系列控件的学习案例，会伴随着文章逐渐更新完善，欢迎大家补充交流，Star地址：
https://github.com/Mike-bel/MDStudySamples