夜雨聆风本文基于 AndroidX CoordinatorLayout 源码，剖析 Behavior 从 XML 定义到内存对象的完整解析链路。
引言
在 Android 开发中，CoordinatorLayout 堪称最神奇的布局之一。它之所以强大，核心就在于 Behavior 机制——通过将交互行为解耦到独立的 Behavior 类中，实现了子视图之间的协调联动。但你是否思考过：当我们写下 app:layout_behavior=".MyBehavior"这行代码时，背后究竟发生了什么？Behavior 是在什么时候、通过什么方式被创建出来的？
本文将带你从源码角度，完整追踪 Behavior 的解析与实例化全过程。Behavior 的解析并非一蹴而就，而是沿着一条精心设计的调用链逐步完成。这条链路的核心节点如下：
onMeasure()
→ prepareChildren()
→ getResolvedLayoutParams()
→ 解析 @DefaultBehavior 注解 或 AttachedBehavior 接口
→ LayoutParams 构造函数
→ parseBehavior()
→ 类名补全规则
→ 反射构造器缓存
→ 创建 Behavior 实例
→ Behavior.onAttachedToLayoutParams()onMeasure 中的 prepareChildren
当CoordinatorLayout布局需要测量时，系统会调用onMeasure这个方法，而它做的第一件事就是调用 prepareChildren：
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
prepareChildren(); // 入口点！
ensurePreDrawListener();
// ... 后续测量逻辑
}prepareChildren方法承担着重要的初始化工作——它不仅构建子视图的依赖关系图，还会确保每个子视图的 Behavior 已经被正确解析：
private void prepareChildren() {
mDependencySortedChildren.clear();
mChildDag.clear();
for (int i = 0, count = getChildCount(); i < count; i++) {
final View view = getChildAt(i);
// 关键调用：获取已解析的 LayoutParams
final LayoutParams lp = getResolvedLayoutParams(view);
// 查找锚点视图
lp.findAnchorView(this, view);
// 构建依赖关系图
mChildDag.addNode(view);
// ... 添加依赖边
}
// ... 排序等操作
}这里最关键的一行是 getResolvedLayoutParams(view)，它是 Behavior 解析的真正入口。继续看getResolvedLayoutParams 的解析逻辑：
LayoutParams getResolvedLayoutParams(View child) {
final LayoutParams result = (LayoutParams) child.getLayoutParams();
// 如果 Behavior 尚未解析
if (!result.mBehaviorResolved) {
// 检查是否实现了 AttachedBehavior 接口（推荐方式）
if (child instanceof AttachedBehavior) {
Behavior attachedBehavior = ((AttachedBehavior) child).getBehavior();
if (attachedBehavior == null) {
Log.e(TAG, "Attached behavior class is null");
}
result.setBehavior(attachedBehavior);
result.mBehaviorResolved = true;
} else {
// 检查 @DefaultBehavior 注解（已废弃，仅作兼容）
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().getDeclaredConstructor().newInstance());
} catch (Exception e) {
Log.e(TAG, "Default behavior class " + defaultBehavior.value().getName()
+ " could not be instantiated.", e);
}
}
result.mBehaviorResolved = true;
}
}
return result;
}这个方法揭示了 Behavior 的两种"备用"获取方式：
1. AttachedBehavior 接口（推荐）：View 自己提供一个 Behavior 2. @DefaultBehavior 注解（已废弃）：通过注解指定默认 Behavior
需要注意的是，这里处理的仅仅是"默认"行为。如果我们是通过 XML 的 layout_behavior属性指定的 Behavior，此时 mBehaviorResolved已经是 true 了——因为它在 LayoutParams 构造时就已经解析完成。
LayoutParams 的构造函数
真正解析 XML 中 layout_behavior的地方，是在 LayoutParams 的构造方法中：
LayoutParams(@NonNull Context context, @Nullable AttributeSet attrs) {
super(context, attrs);
TypedArray a = context.obtainStyledAttributes(attrs,
R.styleable.CoordinatorLayout_Layout);
// 解析基本属性
this.gravity = a.getInteger(
R.styleable.CoordinatorLayout_Layout_android_layout_gravity,
Gravity.NO_GRAVITY);
mAnchorId = a.getResourceId(R.styleable.CoordinatorLayout_Layout_layout_anchor,
View.NO_ID);
// 关键：检查是否有 layout_behavior 属性
mBehaviorResolved = a.hasValue(
R.styleable.CoordinatorLayout_Layout_layout_behavior);
if (mBehaviorResolved) {
// 核心：解析 behavior 字符串并创建 Behavior 实例
mBehavior = parseBehavior(context, attrs, a.getString(
R.styleable.CoordinatorLayout_Layout_layout_behavior));
}
a.recycle();
if (mBehavior != null) {
// 通知 Behavior 已被附加
mBehavior.onAttachedToLayoutParams(this);
}
}这里有两个关键点：
1. mBehaviorResolved标记了是否通过 XML 指定了 Behavior2. parseBehavior方法完成了从字符串到对象的转换
parseBehavior是整个 Behavior 解析机制中最精彩的部分，它处理了类名补全、反射缓存等复杂逻辑：
static Behavior parseBehavior(Context context, AttributeSet attrs, String name) {
if (TextUtils.isEmpty(name)) {
return null;
}
// 第一步：类名补全（处理简写形式）
final String fullName;
if (name.startsWith(".")) {
// 相对包名：在当前应用包名后追加
// 例如：".MyBehavior" -> "com.example.app.MyBehavior"
fullName = context.getPackageName() + name;
} else if (name.indexOf('.') >= 0) {
// 完整包名：直接使用
// 例如："com.example.MyBehavior"
fullName = name;
} else {
// 无包名：使用默认的 Behavior 包名
// 例如："MyBehavior" -> "androidx.coordinatorlayout.widget.MyBehavior"
fullName = !TextUtils.isEmpty(WIDGET_PACKAGE_NAME)
? (WIDGET_PACKAGE_NAME + '.' + name)
: name;
}
try {
// 第二步：使用 ThreadLocal 缓存 Constructor，避免重复反射
Map<String, Constructor<Behavior>> constructors = sConstructors.get();
if (constructors == null) {
constructors = new HashMap<>();
sConstructors.set(constructors);
}
// 从缓存中获取 Constructor
Constructor<Behavior> c = constructors.get(fullName);
if (c == null) {
// 反射获取 Behavior 类
final Class<Behavior> clazz =
(Class<Behavior>) Class.forName(fullName, false, context.getClassLoader());
// 获取带有 (Context, AttributeSet) 参数的构造函数
c = clazz.getConstructor(CONSTRUCTOR_PARAMS);
c.setAccessible(true);
// 存入缓存
constructors.put(fullName, c);
}
// 第三步：创建 Behavior 实例，传入 context 和 attrs
return c.newInstance(context, attrs);
} catch (Exception e) {
throw new RuntimeException("Could not inflate Behavior subclass " + fullName, e);
}
}为了更清晰地理解类名补全规则，这里用一个表格总结：
com.example.MyBehavior | com.example.MyBehavior | |
.MyBehavior | 应用包名.MyBehavior | |
MyBehavior | androidx.coordinatorlayout.widget.MyBehavior |
这种设计使得开发者可以用最简洁的方式指定常见 Behavior，同时保留使用自定义包名的灵活性。
注意到 sConstructors是一个 ThreadLocal<Map<String, Constructor<Behavior>>>，这意味着每个线程都有自己独立的构造器缓存。这种设计考虑到了：
1. 避免重复反射：同一个 Behavior 类只需反射一次 2. 线程安全：每个线程独立缓存，无需同步 3. 内存友好：线程销毁时缓存自动回收
生命周期回调：onAttachedToLayoutParams
当 Behavior 实例创建完成后，还有一个重要的步骤——调用 onAttachedToLayoutParams方法：
if (mBehavior != null) {
// 通知 Behavior 已被附加到 LayoutParams
mBehavior.onAttachedToLayoutParams(this);
}这给了 Behavior 一个初始化的机会，比如从 AttributeSet 中解析自定义属性：
public static class MyBehavior extends CoordinatorLayout.Behavior<View> {
private int customParam;
public MyBehavior(Context context, AttributeSet attrs) {
super(context, attrs);
if (attrs != null) {
TypedArray a = context.obtainStyledAttributes(attrs, R.styleable.MyBehavior);
customParam = a.getInt(R.styleable.MyBehavior_customParam, 0);
a.recycle();
}
}
@Override
public void onAttachedToLayoutParams(@NonNull CoordinatorLayout.LayoutParams params) {
super.onAttachedToLayoutParams(params);
// 初始化操作
}
}完整的解析流程图
示例：不同配置方式的源码表现
为了更清楚地理解，来看三种不同配置方式在源码层面的表现：
方式一：XML 中指定 layout_behavior
<androidx.recyclerview.widget.RecyclerView
android:layout_width="match_parent"
android:layout_height="match_parent"
app:layout_behavior=".MyCustomBehavior" />源码路径：LayoutParams 构造函数 → parseBehavior → 设置 mBehavior
方式二：实现 AttachedBehavior 接口
public class MyCustomView extends View implements CoordinatorLayout.AttachedBehavior {
@NonNull
@Override
public CoordinatorLayout.Behavior getBehavior() {
return new MyCustomBehavior();
}
}源码路径：getResolvedLayoutParams → child instanceof AttachedBehavior → getBehavior()
除了上面是我们自定义的View，常用的系统定义的View，比如AppBarLayout也是采用这种方式的：
方式三：使用 @DefaultBehavior 注解（已废弃）
@DefaultBehavior(MyCustomBehavior.class)
public class MyCustomView extends View {
}源码路径：getResolvedLayoutParams → 查找注解 → 反射实例化
总结
通过源码追踪，可以得出以下结论：
1. 解析时机：Behavior 的解析发生在两个阶段——XML 布局填充时的 LayoutParams 构造函数，以及测量前的 getResolvedLayoutParams 方法。 2. 优先级规则： • XML 中显式指定的 layout_behavior优先级最高• 其次是通过 AttachedBehavior接口提供的 Behavior• 最后才是通过 @DefaultBehavior注解指定的 Behavior3. 生命周期：Behavior 创建后会立即收到 onAttachedToLayoutParams回调，可以在此进行初始化。
理解了 Behavior 的解析机制，就能更好地掌握 CoordinatorLayout 的工作原理，在遇到问题时也能快速定位——是 Behavior 没配置上？还是类名写错了？还是构造函数出了问题？希望这篇文章能帮助你更好的了解 CoordinatorLayout 。
