我承认我之前想简单了，蘑菇短视频的通知权限问题我终于定位到原因了
我承认我之前想简单了，蘑菇短视频的通知权限问题我终于定位到原因了
前言 我以为只是少勾一个权限就能搞定通知问题，结果越查越深，发现是多种因素叠加导致大量用户收不到推送。把排查过程、最终定位到的根因和可落地的修复方案整理成这篇文章，给遇到类似问题的产品和开发同学一个清晰的路线图，也顺便记录我的“翻车与反思”。
问题现象（用户反馈）
- 部分用户完全收不到新消息/评论/系统推送通知。
- 有的用户能点开应用在内部看到消息，但没有系统通知。
- 问题主要集中在 Android 手机，个别机型更严重（部分国产 ROM 上线报告比例更高）。
先入为主的假设（我之前想简单的地方） 最开始我猜是：
- 后台推送服务器出了问题；
- 或者是某个版本把通知权限从 manifest 删掉了； 这些假设都做了验证，但都不是全部答案——真正的原因更“多线程”而且与 Android 新的权限模型、FCM 消息类型和厂商的后台管理共同作用。
我做了哪些排查（步骤与工具）
- 在 Firebase 控制台和自建推送系统分别发送测试消息，观察是否能到达。
- 在真机上用 adb logcat 过滤关键字（FirebaseMessaging、Notification、GCM、AlarmManager）查看日志。
- 检查 AndroidManifest.xml 中的权限声明和 targetSdkVersion。
- 在应用里打印 FCM token、消息回调，确认 app 是否能接收 data 消息。
- 在不同 Android 版本（特别是 Android 13/Tiramisu）和多款厂商 ROM 上测试复现。
- 检查通知渠道（NotificationChannel）创建逻辑与 importance 设置。
- 复核线上推送 payload（notification vs data-only）以及优先级（priority/priority high / content_available）。
最终定位：多因子复合问题（主因 + 两个重要的次因） 1) 主因（核心）：Android 13 引入的 POST_NOTIFICATIONS 运行时权限未被正确处理
- 如果 app 的 targetSdkVersion >= 33（Android 13），系统要求在运行时向用户请求 POST_NOTIFICATIONS 权限。
- 我们的版本在 manifest 中添加了该 permission，但没有在运行时弹窗请求（也有版本在混淆或构建脚本中被遗漏），导致对 Android 13+ 的设备，用户默认是未授予，系统不会展示推送通知（即使 FCM 到达）。
- 这直接导致大量 Android 13 设备“没有通知提示”。
2) 次因 A：服务器端发送了大量 data-only 消息，且这些消息依赖应用端逻辑来构建通知
- data-only 消息需要应用在收到时自己生成通知。若应用进程被系统杀死（尤其在某些厂商上被强杀/限制后台），data-only 消息可能无法被交付或无法触发通知。
- 当应用进程不在时，notification 字段的消息由系统显示；data-only 在这种场景下就失效。
3) 次因 B：通知渠道或 channel 配置不当 + 厂商的电池/后台限制
- 我们在创建 NotificationChannel 时默认 importance 设成了 LOW 或忽略了 sound，部分设备因此把通知变成“静默”或自动屏蔽。
- 一些厂商（MIUI、OPPO、Vivo、华为）对“自启动/后台活动”做了强限制，且会在权限或 channel 行为异常时直接阻断通知展示。
可复制结论（如何复现问题）
- 在 Android 13 设备装入未请求 POST_NOTIFICATIONS 的应用，app 发 data-only 的 FCM，杀掉进程后发送消息，系统不会展示通知。
- 在某些厂商机型上，即使系统有 notification payload，若 channel importance 为 LOW 且 app 被后台限制，也可能收不到弹窗、声音等。
修复方案（立刻可执行的步骤） 给开发者和产品的清单（按优先级）
1) 运行时请求 POST_NOTIFICATIONS（针对 Android 13+）
- AndroidManifest.xml 添加：
- 在应用启动或关键入口处判断并请求权限（Kotlin 示例）： if (Build.VERSION.SDKINT >= Build.VERSIONCODES.TIRAMISU) { if (ContextCompat.checkSelfPermission(this, Manifest.permission.POSTNOTIFICATIONS) != PackageManager.PERMISSIONGRANTED) { ActivityCompat.requestPermissions(this, arrayOf(Manifest.permission.POSTNOTIFICATIONS), REQUESTCODE) } }
- 给用户友好的弹窗说明为什么需要通知权限，避免用户拒绝。
2) 优化服务端推送策略（兼容性改进）
- 对于重要通知（消息、评论、点赞）优先使用包含 notification 字段的 FCM 消息或同时包含 notification + data，这样当 app 被系统杀死时系统可以代为展示通知。
- 若必须使用 data-only（需要自定义通知样式），确保将 priority 设置为 high，且在 iOS/Android 上做平台差异化处理；注意 data-only 在被系统限制时仍有风险。
示例 payload（notification + data）： { "to": "", "notification": { "title": "有人评论了你的视频", "body": "快来看看吧" }, "data": { "videoId": "12345", "type": "comment" } }
3) 检查并统一 NotificationChannel 配置
- 创建 channel 时使用合适的重要级别（IMPORTANCEHIGH 或 DEFAULT），并设置 sound、vibration 等： NotificationChannel(channelId, name, NotificationManager.IMPORTANCEHIGH)
- 在升级发布流程中，如果需要变更 channel 的重要级别，谨慎处理：已存在的 channel 用户可以更改，代码再创建不会覆盖用户设置；需要在升级文档/发布说明中提醒 QA 验证。
4) 处理厂商自启和电池优化限制（产品/用户层面的引导）
- 在应用首次运行或通知功能入口，检测是否被厂家后台优化所限制，给出步骤引导用户打开“自启动”或“允许后台运行”；示例说明和截图可以显著提升用户按步骤设置的成功率。
- 在 FAQ/帮助页增加针对常见机型（MIUI/ColorOS/EMUI）的设置引导。
5) 增强监控与埋点（避免下次再手忙脚乱）
- 在应用端埋点记录：是否有 POST_NOTIFICATIONS 已授权、token 是否注册成功、最近一次收到通知时间等。
- 服务端记录下推送回执（如果支持）或监控 FCM 回调错误，及时发现 delivery 问题。
开发/测试建议（确保修复落地）
- 用多台真机覆盖 Android 11/12/13+，并至少在 MIUI/ColorOS/EMUI 上跑完整场景测试（冷启动、被杀后台、Doze 模式）。
- 使用 Firebase 控制台做 notification payload 测试，使用自建接口发 data-only 测试两种失败场景。
- 在灰度发布里优先给流量占比小的用户群，监控“通知到达率”指标。
给用户的快速自查指南（适用于普通用户）
- 设置 -> 应用 -> 蘑菇短视频 -> 通知：确认允许通知，并检查通知样式是否为“允许打扰”或有声音。
- 若使用的是 MIUI/ColorOS/其它厂商 ROM：检查“应用自启动”和“在后台运行”选项，允许蘑菇短视频的自启/后台运行。
- 如果仍然没收到，尝试清理通知设置再重启手机，或更新到最新版本的蘑菇短视频。
我的反思（产品与工程的沟通）
- Android 的通知体系在近两年变化较大（特别是权限与 channel），技术升级需要与产品/QA 做明确的兼容测试清单，不应把“权限弹窗”当成可选项。
- 服务端和客户端应约定推送 payload 的优先级策略，不能只靠 data-only 或只靠 notification，重要消息需要冗余策略。
- 厂商 ROM 的行为不可忽视，必要时把设备兼容测试写入发布门槛。
结语（我做了什么，以及下一步） 经过以上定位和修复，我先推动了两个紧急动作： 1) 客户端补上运行时请求并在下个小版本强制检查通知权限； 2) 服务端临时对重要通知走 notification + data 双路推送，并对历史消息做补发策略。
接下来会把监控埋点上线，观察 7 天内的到达率变化，并将常见厂商的自启引导做成图文小弹窗，帮助更多用户快速恢复通知体验。
