Android 自定义View迁移Compose实战指南
核心迁移四步法（附实战案例）
第一步：分类拆解------先分组件/布局，再定迁移策略
核心准则
判断自定义View核心价值，拆分组件型逻辑 （有语义、可复用、带交互）和布局型逻辑 （只管摆放、尺寸计算）；组件型封装为独立@Composable，布局型直接用Compose Modifier实现，绝不复刻onMeasure/onLayout。
实战案例（HeaderView/ScopeImageView）
- 组件型：ScopeImageView（禁用态+按下交互+图标展示）、HeaderView（标题+点击反馈+多类型UI）→ 封装为独立
@Composable； - 布局型：HeaderView中onMeasure的padding计算、子View位置约束→ 甩给
Modifier.padding/align/weight，组件内不写任何布局计算逻辑。
实操要点
口诀：组件管展示交互，布局全靠Modifier
第二步：去芜存菁------三问法清理历史冗余代码
核心准则
迁移不是"复刻代码"，是"重构核心能力"，用三问法筛选代码，非核心逻辑直接删除，不背历史技术债：
- 能一句话说清这段代码的存在价值吗？
- 从零设计这个组件，你还会加这段代码吗？
- Compose有更优雅的原生方案替代吗？
实战案例（HeaderView代码清理）
| 原生View冗余代码 | 清理原因 | Compose替代/处理方式 |
|---|---|---|
| onMeasure中的默认padding判断 | 布局逻辑，非组件核心 | 调用方通过Modifier.padding控制，组件内不处理 |
| onTouchEvent的日志打印 | 非UI核心，调试性代码 | 直接删除，需打印则在外部回调中实现 |
| mPadding/mCurrentType等临时变量 | 为布局判断服务，无复用性 | 直接删除，状态由外部传参替代 |
| ViewUtil.setDesc无障碍逻辑 | Compose有原生更优解 | 用semantics { contentDescription = ... }替代 |
实操要点
口诀：留UI核心能力（交互/展示），删所有补丁/临时/非核心逻辑
第三步：状态归位------业务状态外移，内部状态极简
核心准则
Compose组件只做"状态展示器" ，严格区分三类状态，绝不内聚业务状态，状态修改走单向流（组件通知外部→外部修改状态→组件刷新）：
- 业务状态（如ScopeImageView的enabled、HeaderView的显示类型）→ 外部传参（ViewModel/UIState），组件只读不写；
- 内部状态（如按下背景isPressed、临时动画状态）→ 组件内用
remember存储，仅服务于组件自身UI； - 配置状态（如标题颜色、图标资源）→ 外部传参，支持自定义。
实战案例（ScopeImageView状态设计）
kotlin
// ✅ 正确：业务状态外移，内部状态极简
@Composable
fun ScopeImageView(
iconRes: Int,
enabled: Boolean, // 业务状态：外部传参
onClick: () -> Unit = {} // 状态修改：通知外部
) {
// 内部状态：仅服务于按下背景，组件内存储
val interactionSource = remember { MutableInteractionSource() }
val isPressed by interactionSource.collectIsPressedAsState()
Box(
modifier = Modifier
.alpha(if (enabled) 1f else 0.3f) // 展示业务状态
.clickable(interactionSource = interactionSource, enabled = enabled, onClick = onClick)
) {
if (isPressed && enabled) Box(Modifier.fillMaxSize().background(Color(0x14000000), CircleShape))
Icon(painter = painterResource(iconRes), contentDescription = null)
}
}实操要点
口诀：业务状态归外部，内部状态只留必要，修改全走回调
第四步：组件拆分------Slot API实现低耦合、高扩展
核心准则
复杂自定义View（如多类型的HeaderView）拒绝"when判断一锅炖"，拆分为固定骨架+可变插槽 ，用Slot API（@Composable () -> Unit参数）实现组合式开发，兼顾"快捷预设"和"灵活自定义"。
拆分两步走
- 抽固定骨架：提取所有类型的公共UI（如HeaderView的72dp高容器、标题基础样式、底部间距），封装为基础骨架组件；
- 做可变插槽：将不同类型的差异化UI（如右侧图标/箭头/子按钮）做成插槽参数，由调用方按需传入，组件内不做类型判断。
实战案例（HeaderView Slot API改造）
kotlin
// 1. 固定骨架：提取所有类型的公共部分
@Composable
private fun HeaderSkeleton(
titleContent: @Composable () -> Unit,
trailingContent: @Composable () -> Unit = {}, // 可变右侧插槽
modifier: Modifier = Modifier
) {
Column(modifier.fillMaxWidth()) {
Row(
modifier = Modifier.fillMaxWidth().height(72.dp),
verticalAlignment = Alignment.CenterVertically,
horizontalArrangement = Arrangement.SpaceBetween
) {
titleContent() // 标题插槽
trailingContent() // 右侧可变插槽
}
Spacer(Modifier.height(24.dp))
}
}
// 2. 快捷预设：封装5种常用类型，直接调用
@Composable
fun HeaderView(title: String) { // 仅标题
HeaderSkeleton(titleContent = { Text(title, style = titleTextStyle) })
}
@Composable
fun HeaderView(title: String, iconRes: Int, enabled: Boolean, onIconClick: () -> Unit) { // 标题+图标
HeaderSkeleton(
titleContent = { Text(title, style = titleTextStyle) },
trailingContent = { ScopeImageView(iconRes, enabled, onIconClick) }
)
}
// 其他类型同理，无需修改骨架，直接组合插槽
// 3. 灵活自定义：调用方按需组合，支持无限扩展
@Composable
fun CustomHeaderView(title: String, leftIconRes: Int, nextIconRes: Int) {
HeaderSkeleton(
titleContent = { Row { Icon(painterResource(leftIconRes), null); Text(title) } },
trailingContent = { Icon(painterResource(nextIconRes), null) }
)
}实操要点
口诀：先拆固定与可变，插槽承载差异化，预设+自定义兼顾
高频避坑指南（直击迁移痛点）
- ❌ 踩坑：复刻原生View的onMeasure/onLayout → ✅ 解决：布局逻辑全甩给Modifier，组件只关注展示；
- ❌ 踩坑：组件内用
mutableStateOf存储业务状态 → ✅ 解决：业务状态外移，组件仅通过参数接收； - ❌ 踩坑：忠实复刻原生View的所有代码（包括bug/补丁）→ ✅ 解决：用三问法清理，只保留核心UI能力；
- ❌ 踩坑：用大量when判断实现多类型UI → ✅ 解决：用Slot API组合，拒绝硬编码判断；
- ❌ 踩坑：忽略交互状态的封装 → ✅ 解决：用Compose原生
InteractionSource处理按下/选中，替代原生onTouchEvent。
核心心法总结
自定义View迁移Compose，核心不是"语法转换"，而是"思维转换" ：
从View的"命令式操作、状态内聚、逻辑混放"，转向Compose的"声明式描述、状态分离、组件化组合"；
牢记四步核心：分类拆解→去芜存菁→状态归位→组件拆分，让迁移后的Compose组件低耦合、高复用、易扩展。