简介面向Android开发者的自定义ToolBar菜单角标实现方案围绕ActionProvider封装与Menu小红点效果展开适合需要为应用顶部工具栏添加未读消息数、状态提示等徽标场景的开发者。压缩包共1390个文件大小约10.09MB包含png图标、xml布局与配置、class编译产物、json资源清单、dex可执行文件及gradle工程脚本等其中大量png与xml用于演示不同角标状态和样式源码与成品apk可对照查看。已有317人学习下载通过该资源可直接获取自定义ActionProvider的编写思路、Menu菜单项绑定方式及红点绘制细节内容预览中可见aidl接口定义及打包产物说明包内还包含完整的Android构建与依赖文件便于结合Android Studio工程调试。若需步骤讲解可前往作者博客查阅配套教程整体是进阶读者实现高定制化ToolBar效果的实用参考。 做消息模块的时候我最头疼的不是红点怎么画、角标数字怎么算而是用户点了那个红点之后动作逻辑散落在各个页面和回调里今天加一个弹窗明天加一个跳转后天又要埋点改到最后自己都不知道一个Badge点击之后到底会触发多少东西。后来我把这块统一抽成了一个组件命名就叫BadgeActionProvider核心思路很简单把“角标展示”和“角标点击后的动作执行”彻底拆开让所有业务方只面向动作描述编程。这篇文章就把我设计和落地这个组件的过程完整记录下来包括接口设计、内部实现、踩坑记录如果你是Android开发刚好在做消息中心、首页金刚区或者Tab红点这类功能这篇应该能帮你少走不少弯路。1. 设计之前BadgeActionProvider到底在解决什么问题1.1 角标不是“一个红点”而是一套动作链很多需求文档里写的是“给这个入口加个红点”但真正落地的时候你会发现红点只是最表层的东西。一个完整的角标功能至少包含三层角标数据的获取与展示数字、红点、气泡样式用户点击后的行为分发跳转页面、弹窗、发起网络请求动作执行后的状态更新角标消除、数字减一、刷新列表。如果你只在每个入口的点击事件里写if (badgeCount 0) { startActivity(...) }短期内看起来没问题但一旦入口变多动作逻辑开始交叉就会陷入“每个页面都在判断角标状态”的泥潭。我把点击后的行为统称为“动作链”BadgeActionProvider的核心职责就是让这条动作链变得可描述、可注册、可复用而不是散落在各个Activity里。1.2 为什么是Provider而不是工具类或回调接口起名字的时候我特意用了“Provider”而不是“Util”或“Manager”是因为它提供的不是某个具体实现而是一种能力入口。你可以把它理解成“动作的提供者”业务方不关心这个角标被点击之后具体由谁来处理只关心“我发一个动作描述出去有人会接住它并执行”。这和直接用接口回调有什么区别接口回调是点对点的强耦合A页面写了onBadgeClick就必须有B对象来响应。而Provider模式是注册式的动作和响应之间通过“动作标识”建立映射业务方只管注册自己关心的动作组件本身负责路由和兜底。这样带来的好处很直接新增一个入口动作不需要改动已有页面代码多个入口可以复用同一个动作处理器动作不响应时有统一的默认行为不会出现“点了没反应”的裸奔情况。2. 核心拆解BadgeActionProvider的职责与边界2.1 三层职责划分组件内部我划分了三个层次每一层只负责一件事避免互相渗透。第一层是数据层解决“角标长什么样”。这层接收来自服务端或本地数据库的角标数据归一化成统一的Badge模型包含角标类型、数量、关联的动作标识、优先级和扩展参数。模型的设计不要和UI绑定actionId、actionParams这种字段必须存在因为它们是后续动作路由的关键。第二层是路由层解决“点击之后去执行什么”。这是BadgeActionProvider的核心内部维护一个“动作标识-动作执行器”的映射表通过actionId找到对应的执行器然后调用统一接口执行。找不到对应执行器时走默认动作通常是跳转默认页或日志上报保证用户侧永远有反馈。第三层是执行层解决“动作到底怎么干”。每个业务方实现IBadgeActionExecutor接口在内部写自己的业务逻辑页面跳转、弹窗、清角标、埋点都可以放进来。执行器的生命周期由组件统一管理不挂在某个Activity上避免内存泄漏和空指针。2.2 谁不该由它负责这个组件容易写成一个“上帝类”什么功能都往里塞所以我一再强调边界。BadgeActionProvider不应该做以下几件事不该直接管理厂商角标权限华为、小米、OPPO的角标权限申请应该由系统层面的BadgeHelper负责而不是业务组件不该负责创建页面实例页面跳转应该交给Router或者Intent组件只负责任务编排不该承担数据拉取逻辑角标数字怎么来是数据层的事组件只消费已经归一化好的数据。划清楚边界之后整个组件的可测试性也上来了。你可以很方便地用Mock数据去触发动作而不需要真的构造一个页面跳转环境。3. 接口设计与关键实现3.1 接口签名怎么做才不容易改我最终沉淀下来的接口很精简核心就三个部分数据模型、动作执行器接口、Provider入口。// 角标数据模型由业务方填充 data class BadgeInfo( val badgeId: String, // 角标唯一标识例如 home_message val count: Int, // 显示数字0 表示红点模式 val actionId: String, // 点击后要触发的动作标识 val actionParams: MapString, String emptyMap(), // 动作参数 val priority: Int 0 // 优先级多个角标汇聚时使用 ) // 动作执行器接口业务方实现 interface IBadgeActionExecutor { fun execute(context: Context, badge: BadgeInfo) } // 组件对外入口 object BadgeActionProvider { fun registerAction(actionId: String, executor: IBadgeActionExecutor) fun unregisterAction(actionId: String) fun handleBadgeClick(context: Context, badge: BadgeInfo) }为什么动作参数用MapString, String而不是强类型对象因为动作执行器可能被多个入口复用参数用K-V形式最灵活解析和排查都方便。执行器内部再把字符串参数解析成自己需要的类型保持接口层面的稳定。3.2 内部实现要点注册表、兜底动作、线程切换注册表我用了一个ConcurrentHashMap。为什么强调并发安全因为角标点击可能来自主线程的点击事件但注册动作可能来自子线程的初始化流程如果不用并发容器极端情况下会丢注册。兜底动作的思路也值得细说。在handleBadgeClick里如果根据actionId查不到执行器不能直接return一定要有一个全局默认执行器。我目前的做法是默认跳转到角标对应的列表页如果没有列表页配置就把点击事件丢弃并打一条Warn日志。这样既保证用户不会“点了没反应”也方便线上排查是不是漏注册了动作。线程切换我也踩过坑。执行器里的execute方法统一在工作线程调用会出问题因为有些动作必须切回主线程。我的思路是组件层面不强制线程但提供一个ensureMainThread的扩展让执行器内部自己决定inline fun ensureMainThread(crossinline action: () - Unit) { if (Looper.myLooper() Looper.getMainLooper()) { action() } else { Handler(Looper.getMainLooper()).post { action() } } }这个设计避免了组件层做太多隐式假设每个执行器对自己的执行环境负责。4. 实操落地从接入到扩展4.1 业务侧接入只需要四步这组件最让我满意的就是接入成本低新业务接入的时候不会产生抵触情绪。标准流程是这样的在Application初始化时创建并注册好通用的动作执行器比如“跳转消息列表”的执行器业务方在拿到角标数据时构造好BadgeInfo把actionId填成自己注册过的标识在UI层展示角标时点击回调里直接调BadgeActionProvider.handleBadgeClick(context, badgeInfo)如果某个页面有特殊的点击逻辑页面销毁前注册临时执行器销毁时注销。我遇到过好几个业务方问“我不注册执行器能不能直接用”答案是可以的走默认兜底动作只是做不到业务自定义。但这是组件的设计初衷不注册就是纯展示注册了才有承接能力。4.2 多模块场景下注册时机怎么保证在组件化项目里执行器的注册代码放在哪个模块、什么时候执行很容易出问题。如果某个子模块的注册代码写在init里但用户点击角标时模块还没初始化就会走兜底逻辑看起来像“Bug”。我的解决方案是增加一层延迟注册初始化时不直接注册执行器而是注册一个Provider工厂真正点击时才调用工厂创建执行器。这样能有效避免初始化顺序问题。还有一种方案是把executor的class全路径写在配置表里用反射创建实例适合动态下发动作的场景。我目前生产环境用的是前者后者用在灰度实验和动态配置上。4.3 配合Deeplink和路由扩展性更强BadgeActionProvider和路由是天然搭配。很多动作本身就是页面跳转我不用在IBadgeActionExecutor的实现里写Intent跳转逻辑而是直接调用路由框架把badge.actionParams作为路由参数传进去。举个例子角标点击后要跳转到订单详情路由地址是/order/detail参数里有orderId。这时候你只需要写一个执行器class OrderDetailActionExecutor : IBadgeActionExecutor { override fun execute(context: Context, badge: BadgeInfo) { val orderId badge.actionParams[orderId] Router.getInstance() .build(/order/detail) .withString(orderId, orderId) .navigation(context) } }以后如果跳转逻辑变了比如先弹一个确认弹窗再跳转只需要改这一个执行器和角标展示完全隔离。这种扩展方式在首页金刚区、Tab消息红点、运营活动入口上都验证过相当稳。5. 常见问题与排查技巧实录5.1 问题速查表现象可能原因解决思路点击角标无响应actionId未注册或注册表被清空检查registerAction是否执行日志里查找No Action Found警告角标点击后重复跳转执行器内部注册了重复的跳转逻辑排查是否多个执行器同时响应同一个actionId检查注册表唯一性页面销毁后点角标崩溃执行器持有了Activity引用执行器用全局Context页面级操作前判空并检查isFinishing/isDestroyed子线程更新UI崩溃执行器在子线程跑了UI操作强制走ensureMainThread后再更新View偶现角标点击失效延迟注册导致执行器未初始化改用工厂模式懒加载或把注册优先级提前到主线程初始化阶段5.2 处理动作重复执行的心得动作重复执行这个问题比大多数新手预期得要隐蔽。有一次线上反馈说“点了一下消息角标弹了两个详情页”查了很久才发现是某个版本的埋点SDK初始化时会自动补发一次点击事件相当于同一个handleBadgeClick触发了两次。这不是组件本身的问题但组件层面最好能提供幂等保护。我的做法是在组件内部做一个时间戳去重同一badgeId的点击事件在500毫秒内只处理一次。这个保护罩成本极低但能挡掉大量由重复点击、重复投递引发的问题。private val lastClickMap ConcurrentHashMapString, Long() fun handleBadgeClick(context: Context, badge: BadgeInfo) { val now System.currentTimeMillis() val last lastClickMap[badge.badgeId] ?: 0L if (now - last 500L) return lastClickMap[badge.badgeId] now // 后续动作路由... }5.3 测试视角的注意事项Angular这层可能不太被重视但如果你负责组件质量我强烈建议为BadgeActionProvider单独配一套单元测试覆盖这些场景actionId有注册、无注册、重复注册三种情况下的行为多个角标同时点击时的并发正确性重点看注册表有没有丢数据;执行器抛出异常时有没有被捕获会不会导致崩溃参数为null时默认兜底动作会不会炸。目前我的测试方案是用Robolectric跑本地单测再在真机上做一次手工回归重点机型覆盖厂商角标差异比较大的那几款。实测下来这种双轨验证策略能让线上问题率降一个量级。最后聊一点实际体会BadgeActionProvider这个组件不是一口气设计成这样的。第一版就是个简单的工具类所有点击逻辑用一个when塞在同一个文件里后来接入的业务方多了耦合越来越重才慢慢重构到现在这个形态。如果你也在做类似的事情我的建议是别追求一步到位先把点击动作从页面里解放出来让角标只负责展示让动作走统一的路由第二步再考虑注册表的边界和组件的生命周期管理。还有一个细节提醒一下命名和分层一定要保持在最初的思路上否则代码很快就腐化。每次新加一个执行器都要问一句“这个动作真的属于这个组件吗”如果发现有一天BadgeActionProvider里出现了网络请求、数据库写入那就要警惕了。记住它只负责“动作的提供与分发”不负责“动作的具体业务实现”。守住这条边界这个组件就能长期稳定地服务整个App的消息体系。本文还有配套的精品资源点击获取
简介面向Android开发者的自定义ToolBar菜单角标实现方案围绕ActionProvider封装与Menu小红点效果展开适合需要为应用顶部工具栏添加未读消息数、状态提示等徽标场景的开发者。压缩包共1390个文件大小约10.09MB包含png图标、xml布局与配置、class编译产物、json资源清单、dex可执行文件及gradle工程脚本等其中大量png与xml用于演示不同角标状态和样式源码与成品apk可对照查看。已有317人学习下载通过该资源可直接获取自定义ActionProvider的编写思路、Menu菜单项绑定方式及红点绘制细节内容预览中可见aidl接口定义及打包产物说明包内还包含完整的Android构建与依赖文件便于结合Android Studio工程调试。若需步骤讲解可前往作者博客查阅配套教程整体是进阶读者实现高定制化ToolBar效果的实用参考。 做消息模块的时候我最头疼的不是红点怎么画、角标数字怎么算而是用户点了那个红点之后动作逻辑散落在各个页面和回调里今天加一个弹窗明天加一个跳转后天又要埋点改到最后自己都不知道一个Badge点击之后到底会触发多少东西。后来我把这块统一抽成了一个组件命名就叫BadgeActionProvider核心思路很简单把“角标展示”和“角标点击后的动作执行”彻底拆开让所有业务方只面向动作描述编程。这篇文章就把我设计和落地这个组件的过程完整记录下来包括接口设计、内部实现、踩坑记录如果你是Android开发刚好在做消息中心、首页金刚区或者Tab红点这类功能这篇应该能帮你少走不少弯路。1. 设计之前BadgeActionProvider到底在解决什么问题1.1 角标不是“一个红点”而是一套动作链很多需求文档里写的是“给这个入口加个红点”但真正落地的时候你会发现红点只是最表层的东西。一个完整的角标功能至少包含三层角标数据的获取与展示数字、红点、气泡样式用户点击后的行为分发跳转页面、弹窗、发起网络请求动作执行后的状态更新角标消除、数字减一、刷新列表。如果你只在每个入口的点击事件里写if (badgeCount 0) { startActivity(...) }短期内看起来没问题但一旦入口变多动作逻辑开始交叉就会陷入“每个页面都在判断角标状态”的泥潭。我把点击后的行为统称为“动作链”BadgeActionProvider的核心职责就是让这条动作链变得可描述、可注册、可复用而不是散落在各个Activity里。1.2 为什么是Provider而不是工具类或回调接口起名字的时候我特意用了“Provider”而不是“Util”或“Manager”是因为它提供的不是某个具体实现而是一种能力入口。你可以把它理解成“动作的提供者”业务方不关心这个角标被点击之后具体由谁来处理只关心“我发一个动作描述出去有人会接住它并执行”。这和直接用接口回调有什么区别接口回调是点对点的强耦合A页面写了onBadgeClick就必须有B对象来响应。而Provider模式是注册式的动作和响应之间通过“动作标识”建立映射业务方只管注册自己关心的动作组件本身负责路由和兜底。这样带来的好处很直接新增一个入口动作不需要改动已有页面代码多个入口可以复用同一个动作处理器动作不响应时有统一的默认行为不会出现“点了没反应”的裸奔情况。2. 核心拆解BadgeActionProvider的职责与边界2.1 三层职责划分组件内部我划分了三个层次每一层只负责一件事避免互相渗透。第一层是数据层解决“角标长什么样”。这层接收来自服务端或本地数据库的角标数据归一化成统一的Badge模型包含角标类型、数量、关联的动作标识、优先级和扩展参数。模型的设计不要和UI绑定actionId、actionParams这种字段必须存在因为它们是后续动作路由的关键。第二层是路由层解决“点击之后去执行什么”。这是BadgeActionProvider的核心内部维护一个“动作标识-动作执行器”的映射表通过actionId找到对应的执行器然后调用统一接口执行。找不到对应执行器时走默认动作通常是跳转默认页或日志上报保证用户侧永远有反馈。第三层是执行层解决“动作到底怎么干”。每个业务方实现IBadgeActionExecutor接口在内部写自己的业务逻辑页面跳转、弹窗、清角标、埋点都可以放进来。执行器的生命周期由组件统一管理不挂在某个Activity上避免内存泄漏和空指针。2.2 谁不该由它负责这个组件容易写成一个“上帝类”什么功能都往里塞所以我一再强调边界。BadgeActionProvider不应该做以下几件事不该直接管理厂商角标权限华为、小米、OPPO的角标权限申请应该由系统层面的BadgeHelper负责而不是业务组件不该负责创建页面实例页面跳转应该交给Router或者Intent组件只负责任务编排不该承担数据拉取逻辑角标数字怎么来是数据层的事组件只消费已经归一化好的数据。划清楚边界之后整个组件的可测试性也上来了。你可以很方便地用Mock数据去触发动作而不需要真的构造一个页面跳转环境。3. 接口设计与关键实现3.1 接口签名怎么做才不容易改我最终沉淀下来的接口很精简核心就三个部分数据模型、动作执行器接口、Provider入口。// 角标数据模型由业务方填充 data class BadgeInfo( val badgeId: String, // 角标唯一标识例如 home_message val count: Int, // 显示数字0 表示红点模式 val actionId: String, // 点击后要触发的动作标识 val actionParams: MapString, String emptyMap(), // 动作参数 val priority: Int 0 // 优先级多个角标汇聚时使用 ) // 动作执行器接口业务方实现 interface IBadgeActionExecutor { fun execute(context: Context, badge: BadgeInfo) } // 组件对外入口 object BadgeActionProvider { fun registerAction(actionId: String, executor: IBadgeActionExecutor) fun unregisterAction(actionId: String) fun handleBadgeClick(context: Context, badge: BadgeInfo) }为什么动作参数用MapString, String而不是强类型对象因为动作执行器可能被多个入口复用参数用K-V形式最灵活解析和排查都方便。执行器内部再把字符串参数解析成自己需要的类型保持接口层面的稳定。3.2 内部实现要点注册表、兜底动作、线程切换注册表我用了一个ConcurrentHashMap。为什么强调并发安全因为角标点击可能来自主线程的点击事件但注册动作可能来自子线程的初始化流程如果不用并发容器极端情况下会丢注册。兜底动作的思路也值得细说。在handleBadgeClick里如果根据actionId查不到执行器不能直接return一定要有一个全局默认执行器。我目前的做法是默认跳转到角标对应的列表页如果没有列表页配置就把点击事件丢弃并打一条Warn日志。这样既保证用户不会“点了没反应”也方便线上排查是不是漏注册了动作。线程切换我也踩过坑。执行器里的execute方法统一在工作线程调用会出问题因为有些动作必须切回主线程。我的思路是组件层面不强制线程但提供一个ensureMainThread的扩展让执行器内部自己决定inline fun ensureMainThread(crossinline action: () - Unit) { if (Looper.myLooper() Looper.getMainLooper()) { action() } else { Handler(Looper.getMainLooper()).post { action() } } }这个设计避免了组件层做太多隐式假设每个执行器对自己的执行环境负责。4. 实操落地从接入到扩展4.1 业务侧接入只需要四步这组件最让我满意的就是接入成本低新业务接入的时候不会产生抵触情绪。标准流程是这样的在Application初始化时创建并注册好通用的动作执行器比如“跳转消息列表”的执行器业务方在拿到角标数据时构造好BadgeInfo把actionId填成自己注册过的标识在UI层展示角标时点击回调里直接调BadgeActionProvider.handleBadgeClick(context, badgeInfo)如果某个页面有特殊的点击逻辑页面销毁前注册临时执行器销毁时注销。我遇到过好几个业务方问“我不注册执行器能不能直接用”答案是可以的走默认兜底动作只是做不到业务自定义。但这是组件的设计初衷不注册就是纯展示注册了才有承接能力。4.2 多模块场景下注册时机怎么保证在组件化项目里执行器的注册代码放在哪个模块、什么时候执行很容易出问题。如果某个子模块的注册代码写在init里但用户点击角标时模块还没初始化就会走兜底逻辑看起来像“Bug”。我的解决方案是增加一层延迟注册初始化时不直接注册执行器而是注册一个Provider工厂真正点击时才调用工厂创建执行器。这样能有效避免初始化顺序问题。还有一种方案是把executor的class全路径写在配置表里用反射创建实例适合动态下发动作的场景。我目前生产环境用的是前者后者用在灰度实验和动态配置上。4.3 配合Deeplink和路由扩展性更强BadgeActionProvider和路由是天然搭配。很多动作本身就是页面跳转我不用在IBadgeActionExecutor的实现里写Intent跳转逻辑而是直接调用路由框架把badge.actionParams作为路由参数传进去。举个例子角标点击后要跳转到订单详情路由地址是/order/detail参数里有orderId。这时候你只需要写一个执行器class OrderDetailActionExecutor : IBadgeActionExecutor { override fun execute(context: Context, badge: BadgeInfo) { val orderId badge.actionParams[orderId] Router.getInstance() .build(/order/detail) .withString(orderId, orderId) .navigation(context) } }以后如果跳转逻辑变了比如先弹一个确认弹窗再跳转只需要改这一个执行器和角标展示完全隔离。这种扩展方式在首页金刚区、Tab消息红点、运营活动入口上都验证过相当稳。5. 常见问题与排查技巧实录5.1 问题速查表现象可能原因解决思路点击角标无响应actionId未注册或注册表被清空检查registerAction是否执行日志里查找No Action Found警告角标点击后重复跳转执行器内部注册了重复的跳转逻辑排查是否多个执行器同时响应同一个actionId检查注册表唯一性页面销毁后点角标崩溃执行器持有了Activity引用执行器用全局Context页面级操作前判空并检查isFinishing/isDestroyed子线程更新UI崩溃执行器在子线程跑了UI操作强制走ensureMainThread后再更新View偶现角标点击失效延迟注册导致执行器未初始化改用工厂模式懒加载或把注册优先级提前到主线程初始化阶段5.2 处理动作重复执行的心得动作重复执行这个问题比大多数新手预期得要隐蔽。有一次线上反馈说“点了一下消息角标弹了两个详情页”查了很久才发现是某个版本的埋点SDK初始化时会自动补发一次点击事件相当于同一个handleBadgeClick触发了两次。这不是组件本身的问题但组件层面最好能提供幂等保护。我的做法是在组件内部做一个时间戳去重同一badgeId的点击事件在500毫秒内只处理一次。这个保护罩成本极低但能挡掉大量由重复点击、重复投递引发的问题。private val lastClickMap ConcurrentHashMapString, Long() fun handleBadgeClick(context: Context, badge: BadgeInfo) { val now System.currentTimeMillis() val last lastClickMap[badge.badgeId] ?: 0L if (now - last 500L) return lastClickMap[badge.badgeId] now // 后续动作路由... }5.3 测试视角的注意事项Angular这层可能不太被重视但如果你负责组件质量我强烈建议为BadgeActionProvider单独配一套单元测试覆盖这些场景actionId有注册、无注册、重复注册三种情况下的行为多个角标同时点击时的并发正确性重点看注册表有没有丢数据;执行器抛出异常时有没有被捕获会不会导致崩溃参数为null时默认兜底动作会不会炸。目前我的测试方案是用Robolectric跑本地单测再在真机上做一次手工回归重点机型覆盖厂商角标差异比较大的那几款。实测下来这种双轨验证策略能让线上问题率降一个量级。最后聊一点实际体会BadgeActionProvider这个组件不是一口气设计成这样的。第一版就是个简单的工具类所有点击逻辑用一个when塞在同一个文件里后来接入的业务方多了耦合越来越重才慢慢重构到现在这个形态。如果你也在做类似的事情我的建议是别追求一步到位先把点击动作从页面里解放出来让角标只负责展示让动作走统一的路由第二步再考虑注册表的边界和组件的生命周期管理。还有一个细节提醒一下命名和分层一定要保持在最初的思路上否则代码很快就腐化。每次新加一个执行器都要问一句“这个动作真的属于这个组件吗”如果发现有一天BadgeActionProvider里出现了网络请求、数据库写入那就要警惕了。记住它只负责“动作的提供与分发”不负责“动作的具体业务实现”。守住这条边界这个组件就能长期稳定地服务整个App的消息体系。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
