Android context-mode 实战：ActionMode/CAB 批量操作完整指南

在不同技术圈子里搜 context-mode，出来的东西五花八门，有人拿它指代码编辑器里的上下文感知模式，也有人用它描述模型对话的上下文窗口。但如果你在做 Android 客户端，context-mode 大概率指同一个东西——上下文操作模式（Contextual Action Mode）。这套交互大家每天都在用：长按邮件列表里的几封邮件，顶部原来的标题栏临时变成一个操作栏，显示“已选 3 封”，下面排列归档、删除、标记已读；相册里长按选照片批量分享也是一回事。这个临时的顶部操作栏就是 Contextual Action Bar，业内直接叫 CAB。这篇文章我按“原理 → 菜单配置 → 两种接入方式 → 高频坑位 → 实操经验”的顺序把 context-mode 讲透，适合正准备上批量列表操作、又不想继续用老式长按 ContextMenu 的开发同学。

1. context-mode 到底解决什么问题

1.1 为什么不该继续用长按 ContextMenu

很多项目做列表条目操作，第一反应是给 item 注册registerForContextMenu，长按弹出一个浮层菜单。这个方案对小体量 App 没有硬伤，但只要需求稍微长大一点就露馅：用户只能对“当前这一条”操作，没法多选；菜单点完就消失，没有任何状态残留；连续处理几十条消息时，手指要在弹窗和列表之间反复横跳，体验非常割裂。

context-mode 解决的就是这个割裂感。它把“选中”和“操作”拆成两个阶段：进入模式后，顶部 CAB 常驻显示当前选中数量，用户可以在列表里继续点选、取消、全选，操作按钮始终在同一个位置等你。数据操作完成，点完成按钮或按返回键退出模式，一次性收尾。这套交互的本质是给用户一个“批量处理缓冲区”，而不是给每条数据一个临时入口。

两者最常见的部署方式是共存的：单条点击用普通跳转，长按进 context-mode 做批量。同一个 View 上别同时注册 ContextMenu 和 ActionMode，这个问题我会在第 4 章单独讲，因为它是排查时最高频的误伤现场。

1.2 ActionMode 的系统运行机制

context-mode 在代码层面的载体叫做ActionMode。它不是某个自定义控件，而是系统级的临时操作状态。进入这个状态后，系统把当前 Activity 的标题栏（或 Toolbar）区域切换成 CAB，并调用你传入的 Callback 完成一次“创建 → 准备 → 响应 → 销毁”的生命周期。

整个生命周期只需要理解四个回调：onCreateActionMode负责填充菜单并决定是否真的进入模式，返回 false 就不会显示 CAB；onPrepareActionMode在模式创建后以及每次invalidateMenu()时被调用，适合做动态刷新；onActionItemClicked处理菜单点击；onDestroyActionMode负责清理选中状态。系统会在用户点 CAB 左上角的完成按钮、按返回键、或者代码调用mode.finish()时自动走进最后的清理回调。

理解这个生命周期对排查问题很有用。比如你发现标题里的“已选 N 项”不更新，多半不是 title 设置失败，而是没触发invalidateMenu()，onPrepareActionMode根本没再走。这套“创建一次、反复刷新、统一销毁”的模型，和 RecyclerView 的 Adapter 刷新逻辑很像，想通一个就能少踩一半坑。

1.3 两条接入路线怎么选

实现 context-mode 通常有两条路。第一条是走AbsListView系列的CHOICE_MODE_MULTIPLE_MODAL，也就是给 ListView、GridView 直接开多选模态，配合MultiChoiceModeListener使用。系统会替你维护每条 item 的勾选状态，代码量最小，适合老项目快速改造，但绑定的是 ListView 家族，数据刷新和视图回收机制都比较老。

第二条是通用方案：ReyclerView 上自己维护选中集合，手动调startActionMode(callback)进入模式。RecyclerView 没有内置的 choice mode，所有状态都要自己存、自己画、自己清，代码量明显更多，但换取的是完全可控：你可以自定义进入模式的触发方式，选中集合用什么数据结构，item 高亮怎么画，删除后怎么精确刷新局部 UI。现在的绝大多数新项目都在用第二条路。

我个人的选择标准很简单：列表页是静态数据、团队又赶工期，用 ListView 方案当天上线；列表页承担复杂交互、需要局部刷新和稳定 id 的，直接上 RecyclerView 通用方案，前期的状态管理多写几十行，后面扩展全选、反选、拖拽排序才不返工。

2. 动手前先布置好菜单与选中反馈

2.1 菜单文件里最容易踩的命名空间坑

先看一份标准的 ActionMode 菜单资源。注意看showAsAction用的是哪个命名空间：

<menu xmlns:android="http://schemas.android.com/apk/res/android"> <item android:id="@+id/action_delete" android:title="删除" android:icon="@drawable/ic_delete" android:showAsAction="always" /> <item android:id="@+id/action_share" android:title="分享" android:icon="@drawable/ic_share" android:showAsAction="always" /> </menu>

这里必须用android:showAsAction，不是app:showAsAction。原因在于系统 ActionMode 的菜单走的是框架层 MenuInflater，它不认识 AppCompat 的app:命名空间。很多人把 AppCompat 菜单模板直接拿过来用，app:showAsAction写了一大串，结果 CAB 里一个 item 都看不到，全被塞进溢出菜单，或者直接不渲染。

如果你用的是 AppCompatActivity，更稳妥的做法是走startSupportActionMode，搭配androidx.appcompat.view.ActionMode.Callback，这种情况下菜单解析交给 AppCompat，app:showAsAction才能生效。所以先确认自己的接入方式再决定菜单写法：系统框架方式用android:，AppCompat 方式用app:，别混。

2.2 已选数量要用 Plurals 而不是拼字符串

CAB 最核心的动态信息就是右上角的选中数量。中文场景很多人直接写mode.title = "$count 项已选"，功能没错，但多语言和单复数适配会出问题。Android 官方推荐的方式是定义 Plurals 资源：

<plurals name="selected_count"> <item quantity="one">已选 %d 项</item> <item quantity="other">已选 %d 项</item> </plurals>

代码里通过resources.getQuantityString(R.plurals.selected_count, count, count)取出字符串设置到标题。为什么特意强调这个？因为英语等语言会有 1 item / N items 的区别，而且无障碍朗读时也会按复数规则读，直接在代码里"$count selected"拼英文等于放弃系统帮你做的本地化能力。

刷新标题之后，如果onPrepareActionMode里要根据选中数量去控制某些菜单项显隐，别忘了调mode.invalidateMenu()。这是onPrepare被重新触发的唯一入口，不调它，菜单项状态永远停留在模式刚创建那一刻。

2.3 选中项的视觉反馈要做成可选中的样子

用户长按进入 context-mode 后，item 的外观必须立刻告诉大脑“我现在处于可选择状态”。ListView 家族因为有 choice mode 的setItemChecked机制，系统会自动维护选中态，你只要给列表项的背景设置一个带state_activated的 selector 即可。

RecyclerView 就没有这份福气，选中态完全手动。我的做法是给 item 根布局设置一个带state_selected的 selector 背景，然后在onBindViewHolder里按选中集合给holder.itemView.isSelected赋值。这样 item 被选中时背景自然变化，不需要手动改 background 颜色，也不会因为复用导致高亮串位：

<selector xmlns:android="http://schemas.android.com/apk/res/android"> <item android:drawable="@color/selected_bg" android:state_selected="true" /> <item android:drawable="@color/normal_bg" /> </selector>

另外一个小细节：不要把选中态塞进 textColor 或者单个 icon 上，色块背景的辨识度远比图标变色高，尤其在老机型低分辨率屏幕上。CAB 顶部本身已经给了“已选 N 项”的文字提示，item 背景是第二层确认，两层反馈叠起来用户才不会迷糊。

3. 两种接入方式的完整实操记录

3.1 方式一：ListView 多选模态，最少的代码跑起来

如果项目里还在用 ListView 或 GridView，接入 context-mode 真的就是几行的事。先把列表切到多选模态，再挂一个MultiChoiceModeListener：

listView.choiceMode = ListView.CHOICE_MODE_MULTIPLE_MODAL listView.setMultiChoiceModeListener(object : AbsListView.MultiChoiceModeListener { override fun onItemCheckedStateChanged( mode: ActionMode?, position: Int, id: Long, checked: Boolean ) { val count = listView.checkedItemCount mode?.title = resources.getQuantityString(R.plurals.selected_count, count, count) mode?.invalidateMenu() } override fun onCreateActionMode(mode: ActionMode?, menu: Menu): Boolean { mode?.menuInflater?.inflate(R.menu.menu_contextual, menu) return true } override fun onPrepareActionMode(mode: ActionMode?, menu: Menu): Boolean { val count = listView.checkedItemCount menu.findItem(R.id.action_share)?.isVisible = count == 1 return true } override fun onActionItemClicked(mode: ActionMode?, item: MenuItem): Boolean { return when (item.itemId) { R.id.action_select_all -> { for (i in 0 until listView.count) { listView.setItemChecked(i, true) } true } R.id.action_delete -> { deleteCheckedItems(listView) mode?.finish() true } else -> false } } override fun onDestroyActionMode(mode: ActionMode?) { // ListView 的 choice mode 会自动清掉勾选状态，这里通常不需要手动清 } })

这套方案里最省心的是系统帮你管理了所有 item 的 checked 状态。获取选中的位置可以用listView.checkedItemPositions，它是个SparseBooleanArray，遍历keyAt(i)就能拿到被勾选 item 的位置。删除前先按位置收集数据对象，再调用数据层删除接口，最后adapter.notifyDataSetChanged()刷新。

onActionItemClicked的返回值尤其关键：它返回 false 时，系统会认为事件没被消费，直接帮你把整个 ActionMode finish 掉。我见过好几次“点删除按钮，CAB 秒关，数据没删”的情况，就是这里忘了 return true。

3.2 方式二：RecyclerView + startActionMode 通用方案

RecyclerView 没有 choice mode，一切自己来。先给 Adapter 加一个选中集合，这里我强烈建议用MutableSet<Long>存 item 的唯一 id 而不是 position，原因是 RecyclerView 的 item 会复用、插入和删除时 position 会漂移，用 id 才能在滚动和刷新后依然稳定。Adapter 里做两件事：

class ItemAdapter : RecyclerView.Adapter<ItemAdapter.VH>() { val selectedIds = mutableSetOf<Long>() @Suppress("ClickableViewAccessibility") override fun onBindViewHolder(holder: VH, position: Int) { val item = items[position] holder.itemView.isSelected = selectedIds.contains(item.id) holder.itemView.setOnClickListener { if (actionMode != null) { if (!selectedIds.remove(item.id)) { selectedIds.add(item.id) } notifyItemChanged(position) actionMode?.invalidateMenu() } } holder.itemView.setOnLongClickListener { if (actionMode == null) { selectedIds.clear() selectedIds.add(item.id) actionMode = requireActivity().startSupportActionMode(actionModeCallback) notifyItemChanged(position) } true } } }

进入模式的 Callback 几乎和 ListView 版本一样，区别只是读取selectedIds.size来更新标题和菜单显隐。点击 item 的逻辑要注意：进入模式后，点击应该变成“切换选中态”，而不是再触发普通跳转，所以回调里要用actionMode != null作为分支条件。退出模式后，onDestroyActionMode里清空selectedIds并刷新列表，否则页面残留一片高亮。

这套方案的自由度体现在：你可以任意定制进入模式的手势、菜单按钮的增减、以及 item 的选中视觉。代价是每个状态分支都要自己理清，特别是点击和长按的冲突、ActionMode 和 Fragment 生命周期的叠加，所以需要一个清晰的全局状态管理。

3.3 动作闭环：删除、分享、全选的完整处理

很多教程只讲到 CAB 弹出来，却不讲菜单点了之后怎么办，导致很多人以为 ActionMode 只是“一个会动的标题栏”。我上面代码里其实已经把闭环串起来了，这里单独展开讲删除要处理的三件事：

第一，收集目标要快照。不要直接在遍历的时候从selectedIds里删除数据，先val ids = selectedIds.toList()复制一份，再交给数据层删除，避免并发修改异常。第二，删除完成后立刻刷新 Adapter，这时候最省事的是notifyDataSetChanged()，但只要你用了稳定 id，就可以用notifyItemRemoved配合逐一删除，滚动位置不跳动，体验好得多。第三，刷新完判断列表是否为空，为空时除了退出 ActionMode，最好顺手展示空态视图，否则用户面对一个空白页面会怀疑是不是没删干净。

分享操作上，单张图片用Intent.ACTION_SEND，多张图片要组合ACTION_SEND_MULTIPLE，把选中项拼成ArrayList<Uri>塞进EXTRA_STREAM，再包一层Intent.createChooser。如果分享按钮在选中数量大于 1 时才显示，记得在onPrepareActionMode里结合selectedIds.size控制isVisible，这属于那种不做没人提、做了才觉得高级的细节。

全选和取消全选也放一起说：设计上不要在菜单里放两个按钮，就放一个action_select_all，在onPrepareActionMode里根据“是否全部选中”动态切换标题，要么显示“全选”，要么显示“取消全选”。用户在一个按钮上完成两种操作，菜单栏保持干净，这是 Material 规范里推荐的做法。

4. 高频问题排查与避坑记录

4.1 症状速查表

我把实际排查中见过的典型问题整理成一张表，按“症状 → 原因 → 处理”排列，遇到问题先对号入座：

4.2 进程重建与旋转屏幕的处理逻辑

旋转屏幕是最容易被忽略的坑。系统会销毁并重建 Activity，但 ActionMode 是挂在窗口上的临时状态，不会跟着保存。用户辛辛苦苦选了 8 条消息，转个屏全部白选，这种体验基本等于劝退。

我的处理方式是：在 Activity 的onSaveInstanceState里把selectedIds转成ArrayList<Long>存进去；重建后如果有保存的选中集合，先把它回填到 Adapter，再重新startSupportActionMode，进 Callback 后把标题一次设对。这里有个小技巧：不要试图在onCreate里立刻启动 ActionMode，等onPostCreate窗口真正可用再启动，否则部分机型上 CAB 还没贴到窗口上就开始跑动画，会出现一顿一顿的观感。

如果项目最低版本高于 API 23，也可以用startActionMode(callback, ActionMode.TYPE_FLOATING)启动悬浮式 ActionMode，它不依赖顶部 ActionBar，弹窗式呈现，旋转屏幕时系统会稍微“宽容”一些。但悬浮式在手机和平板的观感差异很大，大屏上容易像一块随意飘浮的补丁，我一般只在需要强制置顶对话框类的场景用它。

4.3 与 Fragment 和 Toolbar 的组合拳

新项目基本都是单 Activity 多 Fragment，ActionMode 的启动入口要统一放在 Activity 侧。在 Fragment 里直接写activity?.startActionMode(callback)偶尔能跑，但一旦 AB 主题换成 AppCompat 就有概率把 CAB 渲染得没头没尾，正确姿势是统一走requireActivity().startSupportActionMode(actionModeCallback)，Callback 类型用androidx.appcompat.view.ActionMode.Callback。

如果布局里用的是独立Toolbar而不是系统 ActionBar，默认情况下 CAB 弹出时会顶开 Toolbar 或者遮住一部分内容，导致明显的布局跳变。解决办法是在主题里加上android:windowActionModeOverlay="true"，让 CAB 悬浮在 Toolbar 上层，而不是把 Toolbar 挤下去。这个属性加在 Theme 的item里，一行代码，解决的是“CAB 出现时整个页面猛地向上一跳”的尴尬，属于那种不加之前每天难受、加了之后再也没人提的老问题。

5. 最后：几条压箱底的经验

5.1 数据层面的习惯：永远用 id 说话

我在第 3 章就反复强调过这件事，因为它真的值得反复强调：context-mode 的所有状态管理，只要涉及列表数据，就一律用稳定 id 标记选中项。无论你的 Adapter 是哪种列表、用了什么 DiffUtil，position只有在“静态且不增删”的列表里才算数。一旦列表支持删除、插入、排序、过滤搜索，position 瞬间变成无用信息，轻则高亮错乱，重则删错用户数据。给 Adapter 加上setHasStableIds(true)并正确覆写getItemId()，用选中 id 集合驱动itemView.isSelected和局部刷新，这个基本功打好，后面什么列表场景都不慌。

还有一个容易忽略的数据问题：删除动作做完，如果数据源真的已经清空了选中集合，但列表容器还挂在界面上，一定要把 ActionMode 手动finish()掉。有些开发者把finish()只放在按钮点击里，数据被外部刷新导致列表变化后，旧 CAB 还傻傻显示前任选中数量，这种状态不一致是最难排查的线上问题。

5.2 交互层面：把用户当傻瓜，也要给高手留后门

context-mode 在交互上的定位是“轻量批量操作”，所以别把它做成重型编辑器。三个原则供参考：第一，退出方式要齐，左上角完成按钮、系统返回键都要能退出，onDestroyActionMode里做全量状态清理；第二，删除这种破坏性操作要留确认，CAB 上直接放“删除”按钮很容易误触，可以在点击后弹一个确认对话框，或者用 Snackbar 提供撤销；第三，对高频用户提供全选快捷键，长按进入模式后点两次全选按钮就能反选，批量处理邮件、聊天记录时这个效率提升非常明显。

最后分享一个我自己常用的小设计：把“分享”的菜单项和单复数绑定，选中 1 条时显示“分享”，多选时显示“分享全部”，配合onPrepareActionMode动态改标题和图标透明度。这类细节不会写进需求文档，但用户会感知到“这个列表是活的”，比任何动画都更能建立信任感。context-mode 本身不难，难的是让每一次批量操作都显得可靠、可控、可撤销——把这些想清楚，才算是真正把 CAB 用到位了。