在上篇文章中，我们简单介绍了一下Behavior，今天对他的原理做进一步分析。主要介绍behavior如何自定义，behavior的构造，onPreDraw，fab为何随snackbar变化的相关的知识。
自定义behavior
先看个例子，上篇文章主要是重点分析了下，为什么snackbar出现和消失的时候，fab会做出相应变化，那我们能否修改这种变化呢？
比如我想要snackbar出现的时候，fab往上移动100，snackbar消失的时候fab再往上移动100，能否实现呢？
当然可以，代码也很简单，自定义一个MyBehavior，注意必须加入一个MyBehavior的构造器，带有Context和AttributeSet参数，原因后文会说。
public class MyBehavior extends CoordinatorLayout.Behavior {
//此构造函数必须加入
public MyBehavior(Context context, AttributeSet attrs) {
super(context,attrs);
}
//child就是绑定此behavior的view，dependency是发送变化的view
@Override
public boolean layoutDependsOn(CoordinatorLayout parent, View child, View dependency) {
return dependency instanceof Snackbar.SnackbarLayout;
}
@Override
public boolean onDependentViewChanged(CoordinatorLayout parent, View child, View dependency) {
//此处child 就是fab，dependency是被依赖的view
if (dependency instanceof Snackbar.SnackbarLayout) {
//SnackbarLayout 变化了，A该如何变化在这里写
child.setTranslationY(child.getTranslationY() - 100);
return true;
}
return false;
}
@Override
public void onDependentViewRemoved(CoordinatorLayout parent, View child, View dependency) {
if (dependency instanceof Snackbar.SnackbarLayout) {
//SnackbarLayout 变化了，fab该如何变化在这里写
child.setTranslationY(child.getTranslationY() - 100);
}
}
}
然后在xml内配置behavior,其实就是加入了一行代码 app:layout_behavior="com.fish.a2.MyBehavior"
看效果
所以说自定义Behavior也是很简单的事情
原理分析
behavior到底是什么
从上边的代码看来，behavior像是view的一个属性，其实他是view的LayoutParam的一个属性，就像宽高一样。当然不是任何一个view的LayoutParam都有这个属性的，只有LayoutParam为android.support.design.widget.CoordinatorLayout.LayoutParams才有这个属性，说白了，就是只有CoordinatorLayout的子view的LayoutParam可以设置behavior。我们看看CoordinatorLayout.LayoutParams的代码,可以发现Behavior变量的确在里面。
public static class LayoutParams extends ViewGroup.MarginLayoutParams {
Behavior mBehavior;
boolean mBehaviorResolved = false;
...
final Rect mLastChildRect = new Rect();
}
再来看看app:layout_behavior="com.fish.a2.MyBehavior"这行代码是怎么导致LayoutParams内的mBehavior被赋值的
我们知道infate的时候，会根据xml去构造LayoutParams，所以我们看CoordinatorLayout.LayoutParams的构造函数
LayoutParams(Context context, AttributeSet attrs) {
super(context, attrs);
final TypedArray a = context.obtainStyledAttributes(attrs,
R.styleable.CoordinatorLayout_LayoutParams);
...
mBehaviorResolved = a.hasValue(
R.styleable.CoordinatorLayout_LayoutParams_layout_behavior);
if (mBehaviorResolved) {
mBehavior = parseBehavior(context, attrs, a.getString(
R.styleable.CoordinatorLayout_LayoutParams_layout_behavior));
}
a.recycle();
}
当我们构造fab的LayoutParams时，走到L7，查一下是否存在layout_behavior值，如果存在，那就parseBehavior并且赋值给mBehavior。parseBehavior就是把字符串com.fish.a2.MyBehavior变成一个对象，用反射的方法。主要代码如下所示
// 这里是指定的Behavior构造器的参数类型
static final Class[] CONSTRUCTOR_PARAMS = new Class[] {
Context.class,
AttributeSet.class
};
...
static Behavior parseBehavior(Context context, AttributeSet attrs, String name) {
...
try {
Map> constructors = sConstructors.get();
if (constructors == null) {
constructors = new HashMap<>();
sConstructors.set(constructors);
}
Constructor c = constructors.get(fullName);
if (c == null) {
final Class clazz = (Class) Class.forName(fullName, true,
context.getClassLoader());
//获取特定参数的构造器
c = clazz.getConstructor(CONSTRUCTOR_PARAMS);
c.setAccessible(true);
constructors.put(fullName, c);
}
return c.newInstance(context, attrs);
} catch (Exception e) {
throw new RuntimeException("Could not inflate Behavior subclass " + fullName, e);
}
}
主要L23，这里是用特定参数的构造器来c.newInstance的，CONSTRUCTOR_PARAMS就是一个Context，一个AttributeSet，为什么我们开头的时候说自定义Behavior必须带一个这种类型的构造器的，现在应该有答案了。
那么现在问题来了，在上一篇文章中，我们根本就没有设置layout_behavior，那这个LayoutParams里面的mBehavior是在哪里复制的呢？
我们再来看看, FloatingActionButton有个注解，CoordinatorLayout.DefaultBehavior(FloatingActionButton.Behavior.class)，在这里指定了默认的Behavior
@CoordinatorLayout.DefaultBehavior(FloatingActionButton.Behavior.class)
public class FloatingActionButton extends VisibilityAwareImageButton
在CoordinatorLayout的onMeasure的时候会调用prepareChildren，进而调用getResolvedLayoutParams，在getResolvedLayoutParams里会把注解里的默认Behavior赋值给mBehavior,主要代码如下
LayoutParams getResolvedLayoutParams(View child) {
final LayoutParams result = (LayoutParams) child.getLayoutParams();
//如果xml内写了behavior，此时result.mBehaviorResolved就为true，不会进去
if (!result.mBehaviorResolved) {
Class childClass = child.getClass();
DefaultBehavior defaultBehavior = null;
while (childClass != null &&
(defaultBehavior = childClass.getAnnotation(DefaultBehavior.class)) == null) {
childClass = childClass.getSuperclass();
}
if (defaultBehavior != null) {
try {
result.setBehavior(defaultBehavior.value().newInstance());
} catch (Exception e) {
Log.e(TAG, "Default behavior class " + defaultBehavior.value().getName() +
" could not be instantiated. Did you forget a default constructor?", e);
}
}
result.mBehaviorResolved = true;
}
return result;
}
所以到了现在，我们知道设置一个view的behavior有2种方式，xml内指定，或者注解里指定，xml优先级高。xml内指定的话，是在inflate的时候对mBehavior赋值的，在注解里指定的话，是在onMeasure内赋值的，稍有不同。
behavior如何发挥作用
前面说了如何给view配置behavior，那配了behavior又有什么用呢？为何behavior能够监测到另一个view的变化情况，这都是CoordinatorLayout的功劳。
onMeasure
我们再来看看onMeasure的代码，主要看prepareChildren和ensurePreDrawListener
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
prepareChildren();
ensurePreDrawListener();
。。。
先看prepareChildren
private void prepareChildren() {
//清空mDependencySortedChildren
mDependencySortedChildren.clear();
for (int i = 0, count = getChildCount(); i < count; i++) {
final View child = getChildAt(i);
final LayoutParams lp = getResolvedLayoutParams(child);
lp.findAnchorView(this, child);
//加入child
mDependencySortedChildren.add(child);
}
// We need to use a selection sort here to make sure that every item is compared
// against each other
//排序
selectionSort(mDependencySortedChildren, mLayoutDependencyComparator);
}
prepareChildren内做了什么，主要是搞出来一个mDependencySortedChildren,根据依赖关系对child进行排序。首先L3把mDependencySortedChildren clear，然后遍历子view，全部加入到mDependencySortedChildren内，最后对mDependencySortedChildren进行排序。注意每次measure都会调用prepareChildren来搞出一个mDependencySortedChildren。
我们在看看排序的代码（用的冒泡），看mLayoutDependencyComparator就行了,看下边代码可以知道，被依赖的view放前面，比如我们fab依赖于snackbar，那么snackbar必然放在fab的前边。这么排序有什么用？其实是提高一点效率，后文会说的。
final Comparator mLayoutDependencyComparator = new Comparator() {
@Override
public int compare(View lhs, View rhs) {
if (lhs == rhs) {
return 0;
} else if (((LayoutParams) lhs.getLayoutParams()).dependsOn(
CoordinatorLayout.this, lhs, rhs)) {
return 1;
} else if (((LayoutParams) rhs.getLayoutParams()).dependsOn(
CoordinatorLayout.this, rhs, lhs)) {
return -1;
} else {
return 0;
}
}
};
再看ensurePreDrawListener
在prepareChildren确定mDependencySortedChildren之后，会执行ensurePreDrawListener，在这里写判断下CoordinatorLayout的子view是否存在依赖关系，如果存在的话就hasDependencies为true，后边会加入PreDrawListener。
void ensurePreDrawListener() {
//判断是否存在依赖关系
boolean hasDependencies = false;
final int childCount = getChildCount();
for (int i = 0; i < childCount; i++) {
final View child = getChildAt(i);
if (hasDependencies(child)) {
hasDependencies = true;
break;
}
}
if (hasDependencies != mNeedsPreDrawListener) {
if (hasDependencies) {
//加入PreDrawListener
addPreDrawListener();
} else {
removePreDrawListener();
}
}
}
PreDrawListener是什么？看下边代码，简单，就是在onPreDraw的时候调用dispatchOnDependentViewChanged。
void addPreDrawListener() {
if (mIsAttachedToWindow) {
// Add the listener
if (mOnPreDrawListener == null) {
mOnPreDrawListener = new OnPreDrawListener();
}
final ViewTreeObserver vto = getViewTreeObserver();
vto.addOnPreDrawListener(mOnPreDrawListener);
}
// Record that we need the listener regardless of whether or not we're attached.
// We'll add the real listener when we become attached.
mNeedsPreDrawListener = true;
}
class OnPreDrawListener implements ViewTreeObserver.OnPreDrawListener {
@Override
public boolean onPreDraw() {
dispatchOnDependentViewChanged(false);
return true;
}
}
onPreDraw这个回调和onGlobalLayout类似的，他们的对象是ViewTreeObserver，而不是某个view。在即将绘制的时候，会调用mTreeObserver.dispatchOnPreDraw()，然后分发到各个OnPreDrawListener，在回调onPreDraw的。简单的说，就是在重绘之前，会调用onPreDraw。我们在onPreDraw里面调用了dispatchOnDependentViewChanged，这个函数是CoordinatorLayout非常重要的函数。Behavior的主要行为都是写在这里面的。我们先总结下ensurePreDrawListener做了什么，判断子view是否有依赖行为，如果有的话注册一个onPreDraw监听
dispatchOnDependentViewChanged
这里传进来的fromNestedScroll为false，遍历mDependencySortedChildren，查一下每个view的rect是否发生了变化，如果发生了变化（假设变化的view为A），就遍历后边的view，判断后边view是否依赖于A（L33），如果依赖就做出相应变化（L36）。看到L33和L36，终于舒了口气，和Behavior里的行为扯上了关系。
void dispatchOnDependentViewChanged(final boolean fromNestedScroll) {
final int layoutDirection = ViewCompat.getLayoutDirection(this);
final int childCount = mDependencySortedChildren.size();
for (int i = 0; i < childCount; i++) {
final View child = mDependencySortedChildren.get(i);
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
// Check child views before for anchor
for (int j = 0; j < i; j++) {
final View checkChild = mDependencySortedChildren.get(j);
if (lp.mAnchorDirectChild == checkChild) {
offsetChildToAnchor(child, layoutDirection);
}
}
// Did it change? if not continue
final Rect oldRect = mTempRect1;
final Rect newRect = mTempRect2;
getLastChildRect(child, oldRect);
getChildRect(child, true, newRect);
if (oldRect.equals(newRect)) {
continue;
}
recordLastChildRect(child, newRect);
// Update any behavior-dependent views for the change
for (int j = i + 1; j < childCount; j++) {
final View checkChild = mDependencySortedChildren.get(j);
final LayoutParams checkLp = (LayoutParams) checkChild.getLayoutParams();
final Behavior b = checkLp.getBehavior();
//这里调用了behavior的layoutDependsOn
if (b != null && b.layoutDependsOn(this, checkChild, child)) {
。。。
//这里调用了behavior的onDependentViewChanged
final boolean handled = b.onDependentViewChanged(this, checkChild, child);
...
}
}
}
}
这里再说几点，怎么知道哪些view发生了变化，代码如下，就是看oldRect和 newRect 是否一致，getChildRect就是获取view的当前rect，而getLastChildRect是获取view的旧的rect，这个比较奇怪，居然知道旧的rect。
final Rect oldRect = mTempRect1;
final Rect newRect = mTempRect2;
getLastChildRect(child, oldRect);
getChildRect(child, true, newRect);
if (oldRect.equals(newRect)) {
continue;
}
recordLastChildRect(child, newRect);
看看getLastChildRect的代码，原来CoordinatorLayout的LayoutParams里面存储了mLastChildRect。看上边的L8可以知道，会记录newRect到LayoutParams里。
void getLastChildRect(View child, Rect out) {
final LayoutParams lp = (LayoutParams) child.getLayoutParams();
out.set(lp.getLastChildRect());
}
还有个问题，比如我们知道子view A发生了变化，可能有B依赖于A，C依赖于A，怎么去找B,C呢，看上边L28，只要遍历A后边的代码就可以了，为什么？看看前文的mDependencySortedChildren的排序规则就知道了，B,C绝对是在A的后边。可以省去找前面的view，这就是mDependencySortedChildren排序的作用。
再后边代码就是,先判断下b.layoutDependsOn是否返回true，然后执行b.onDependentViewChanged
if (b != null && b.layoutDependsOn(this, checkChild, child)) {
。。。
//这里调用了behavior的onDependentViewChanged
final boolean handled = b.onDependentViewChanged(this, checkChild, child);
...
}
}
好了，behavior的原理基本分析完了。有点绕，但不复杂。
我个人认为，这个实现过程还可以优化一下，比如上文第一个for循环，是遍历了所有的子view，实际上只要遍历被依赖的子view 就好了。而第二个for循环，是遍历了child（rect变化的view）之后的所有子view，其实也没这个必要，因为依赖关系是早就定好的，可以建一个数组存储哪些view依赖了child，这样只要遍历这个数组就可以了。
如果是我来写，我会给每个view设计一个依赖者数组，比如Aview的依赖者数组内有B,C，就代表B依赖于A，C依赖于A。 那第一个for循环遍历依赖者数组非空的view即可，而第二个for循环遍历依赖者数组就好。
还有一点，view的rect发生变化肯定在onLayout之后就知道了，如果在onLayout里把发生变化的view记录下来，那么第一个for循环就可以更简单了，也没必要在LayoutParam里面设计一个mLastChildRect了。
以上是我的个人想法，如有不对，欢迎指正，可能代码google认为反正CoordinatorLayout的子view很小，所以没必要搞那么复杂。
onDependentViewRemoved
我们开篇自定布局的时候还写了onDependentViewRemoved,那这个onDependentViewRemoved是在哪里被调用的呢？
ViewGroup内有个mOnHierarchyChangeListener，view结构发生变化时会触发OnHierarchyChangeListener回调。
protected OnHierarchyChangeListener mOnHierarchyChangeListener;
public interface OnHierarchyChangeListener {
/**
* Called when a new child is added to a parent view.
*
* @param parent the view in which a child was added
* @param child the new child view added in the hierarchy
*/
void onChildViewAdded(View parent, View child);
/**
* Called when a child is removed from a parent view.
*
* @param parent the view from which the child was removed
* @param child the child removed from the hierarchy
*/
void onChildViewRemoved(View parent, View child);
}
再看CoordinatorLayout内自己定义了一个HierarchyChangeListener，在onChildViewRemoved的时候会调用dispatchDependentViewRemoved，这个HierarchyChangeListener在构造函数内set。所以有view被remove调的时候回回调到
dispatchDependentViewRemoved。
private class HierarchyChangeListener implements OnHierarchyChangeListener {
@Override
public void onChildViewAdded(View parent, View child) {
if (mOnHierarchyChangeListener != null) {
mOnHierarchyChangeListener.onChildViewAdded(parent, child);
}
}
@Override
public void onChildViewRemoved(View parent, View child) {
dispatchDependentViewRemoved(child);
if (mOnHierarchyChangeListener != null) {
mOnHierarchyChangeListener.onChildViewRemoved(parent, child);
}
}
}
dispatchDependentViewRemoved的代码也很简单，会根据需要触发onDependentViewRemoved
void dispatchDependentViewRemoved(View view) {
final int childCount = mDependencySortedChildren.size();
boolean viewSeen = false;
for (int i = 0; i < childCount; i++) {
final View child = mDependencySortedChildren.get(i);
if (child == view) {
// We've seen our view, which means that any Views after this could be dependent
viewSeen = true;
continue;
}
if (viewSeen) {
CoordinatorLayout.LayoutParams lp = (CoordinatorLayout.LayoutParams)
child.getLayoutParams();
CoordinatorLayout.Behavior b = lp.getBehavior();
if (b != null && lp.dependsOn(this, child, view)) {
b.onDependentViewRemoved(this, child, view);
}
}
}
}
上述代码都是为了监听某个view被remove而加的，那为什么增加一个view的时候没这么麻烦，删除一个view就这么麻烦呢。因为增加了一个view，那这个view，必然在mDependencySortedChildren内，而删除了一个view，这个view在mDependencySortedChildren就找不到了，所以加了这一堆代码
泛型类Behavior
要知道Behavior其实是个泛型类
public static abstract class Behavior
所以自定义Behavior可以这么写,这样更优雅，免去了强转
public static class Behavior extends CoordinatorLayout.Behavior {
// We only support the FAB <> Snackbar shift movement on Honeycomb and above. This is
// because we can use view translation properties which greatly simplifies the code.
private static final boolean SNACKBAR_BEHAVIOR_ENABLED = Build.VERSION.SDK_INT >= 11;
private ValueAnimatorCompat mFabTranslationYAnimator;
private float mFabTranslationY;
private Rect mTmpRect;
@Override
public boolean layoutDependsOn(CoordinatorLayout parent,
FloatingActionButton child, View dependency) {
// We're dependent on all SnackbarLayouts (if enabled)
return SNACKBAR_BEHAVIOR_ENABLED && dependency instanceof Snackbar.SnackbarLayout;
}
@Override
public boolean onDependentViewChanged(CoordinatorLayout parent, FloatingActionButton child,
View dependency) {
if (dependency instanceof Snackbar.SnackbarLayout) {
updateFabTranslationForSnackbar(parent, child, dependency);
} else if (dependency instanceof AppBarLayout) {
// If we're depending on an AppBarLayout we will show/hide it automatically
// if the FAB is anchored to the AppBarLayout
updateFabVisibility(parent, (AppBarLayout) dependency, child);
}
return false;
}
@Override
public void onDependentViewRemoved(CoordinatorLayout parent, FloatingActionButton child,
View dependency) {
if (dependency instanceof Snackbar.SnackbarLayout) {
updateFabTranslationForSnackbar(parent, child, dependency);
}
}
总结
1、view的behavior有2种方式，xml内指定，或者注解里指定，xml优先级高。xml内指定的话，是在inflate的时候对mBehavior赋值的，在注解里指定的话，是在onMeasure内赋值的，稍有不同。
2、behavior能够检测到view的尺寸变化以及view被remove
3、CoordinatorLayout内的mDependencySortedChildren里，被依赖的view放前面，比如我们fab依赖于snackbar，那么snackbar必然放在fab的前边。