14、通知渠道分组：ChannelGroup的创建与管理、按应用模块分组、用户可见的分组名称
通知渠道分组，说白了就是给你的通知渠道“建个文件夹”。
Android 8.0 引入通知渠道后，大家发现一个问题：如果 App 功能模块太多，通知渠道列表会变得又长又乱。用户看着一长串开关，根本不知道哪个是哪个。我当年接手一个电商项目，光推送类型就分了 20 多种，用户反馈说“这 App 通知设置跟天书一样”。嗯，那时候我就意识到——光有渠道还不够，得学会分组。
14.1 为什么需要 ChannelGroup？
你想想看，一个社交 App 可能有这些通知：
- 私信通知
- 评论通知
- 点赞通知
- 系统通知
- 活动通知
如果不分组，用户看到的是一堆平铺的开关。如果按“消息通知”、“社交互动”、“系统公告”分组，用户一眼就能找到想调整的模块。这就是 ChannelGroup 的价值——提升用户体验，降低设置门槛。
核心要点：ChannelGroup 是通知渠道的逻辑容器。它不会影响通知的发送行为，只影响通知在系统设置界面的展示方式。
14.2 创建 ChannelGroup
创建分组非常简单。你需要一个唯一的 Group ID 和一个用户可见的名称。
// 创建分组
String groupId = "group_social";
CharSequence groupName = "社交互动";
NotificationChannelGroup socialGroup =
new NotificationChannelGroup(groupId, groupName);
// 注册到 NotificationManager
NotificationManager notificationManager =
(NotificationManager) getSystemService(Context.NOTIFICATION_SERVICE);
notificationManager.createNotificationChannelGroup(socialGroup);这里有个细节：Group ID 必须唯一，而且一旦创建，不建议修改。我曾在项目中因为重构改了 Group ID，结果旧设备上残留了空分组，用户设置里出现了一个“无渠道的分组”，特别尴尬。
个人习惯：我一般用“模块名_功能”的命名方式，比如 group_order_refund、group_order_delivery。这样一眼就能看出归属。
14.3 将渠道绑定到分组
创建分组后，创建通知渠道时指定分组即可：
NotificationChannel channel = new NotificationChannel(
"channel_like",
"点赞通知",
NotificationManager.IMPORTANCE_DEFAULT
);
// 绑定到分组
channel.setGroup("group_social");
notificationManager.createNotificationChannel(channel);注意顺序：先创建分组，再创建渠道。如果渠道绑定了不存在的分组，系统会忽略分组设置。我记得有一次调试，渠道死活不显示在分组下，查了半天发现是分组还没创建就绑定了渠道。
避坑指南：我曾经在批量创建渠道时，把分组创建和渠道创建写在了同一个循环里。结果某些渠道先于分组创建，导致分组失效。正确的做法是：先批量创建所有分组，再批量创建所有渠道。
14.4 按应用模块分组的实践
我建议按照 App 的业务模块来划分分组。下面是一个典型电商 App 的分组方案：
| Group ID | 分组名称（用户可见） | 包含渠道 |
|---|---|---|
| group_order | 订单通知 | 下单成功、发货提醒、物流更新、退款进度 |
| group_promotion | 促销活动 | 限时秒杀、优惠券到账、满减提醒 |
| group_social | 社交互动 | 评论回复、点赞通知、关注提醒 |
| group_system | 系统公告 | 版本更新、安全提醒、隐私政策变更 |
这样分组后，用户在系统设置里看到的是四个清晰的模块，而不是一长串看不懂的渠道名。用户体验提升非常明显。
14.5 管理 ChannelGroup
除了创建，你还需要知道怎么查询和删除分组：
// 获取所有分组
List<NotificationChannelGroup> groups =
notificationManager.getNotificationChannelGroups();
// 获取单个分组（API 26+）
NotificationChannelGroup group =
notificationManager.getNotificationChannelGroup("group_social");
// 删除分组（API 26+）
notificationManager.deleteNotificationChannelGroup("group_social");删除分组时要注意：分组下的所有渠道也会被删除。这个操作不可逆，用户之前对渠道的设置也会丢失。我建议只在 App 版本升级、模块下线等场景下使用，不要轻易调用。
重要提醒：删除分组前，最好先遍历分组下的渠道，给用户一个确认弹窗。或者干脆只做“废弃”处理，不真正删除。
14.6 用户可见的分组名称
分组名称是直接展示给用户看的，所以命名要讲究。我总结了几个原则：
- 简短明了：控制在 4-6 个字，比如“订单通知”、“系统公告”
- 避免技术术语：不要用“推送组”、“渠道组”这种词
- 保持一致性：和 App 内功能模块的名称保持一致
- 考虑国际化：如果 App 支持多语言，记得在 strings.xml 中配置
<!-- strings.xml -->
<string name="group_order">订单通知</string>
<string name="group_promotion">促销活动</string>
<string name="group_social">社交互动</string>我个人习惯把分组名称放在 strings.xml 里，而不是硬编码。这样后期改文案、做多语言都方便。
14.7 知识体系图
下面这张图帮你理清 ChannelGroup 的核心逻辑：
14.8 总结与建议
ChannelGroup 不是什么高深的技术，但它能显著提升用户体验。我给你的建议是：
- 尽早规划：在引入通知渠道时，就同步设计分组方案。后期拆分很麻烦。
- 分组粒度适中：太粗（只有一个分组）没意义，太细（每个渠道一个分组）反而更乱。3-6 个分组比较合理。
- 测试分组展示：不同厂商的 ROM 对分组的展示方式可能不同，建议在主流机型上测试一下。
嗯，关于 ChannelGroup 的内容就这些。记住一句话：分组是给用户看的，不是给系统看的。站在用户的角度去设计分组，你的通知设置就不会差。
公众号:蓝海资料掘金营，微信deep3321