自定义FCM广播接收器处理消息的可行性及潜在风险问询

嘿，你的这个自定义广播接收器拦截FCM消息的思路确实解决了后台/杀死状态下onMessageReceived不触发的痛点，不过除了REGISTRATION事件的潜在崩溃，还有几个场景和风险需要你留意：

1. Android 12+的exported属性强制要求 #

从API 31（Android 12）开始，系统要求所有接收外部广播的组件必须显式声明android:exported属性。你的接收器当前没有配置这个字段，在Android 12+的设备上可能会导致接收器注册失败，甚至应用安装直接报错。建议补充：

<receiver 
    android:name=".notifications.FCMOverlordBroadcastReceiver" 
    android:permission="com.google.android.c2dm.permission.SEND"
    android:exported="true"> <!-- 必须添加，允许接收FCM的外部广播 -->
    <intent-filter android:priority="1000"> <!-- 提高优先级，确保先于Firebase默认接收器处理 -->
        <action android:name="com.google.android.c2dm.intent.RECEIVE"/>
        <category android:name="${applicationId}"/>
    </intent-filter>
</receiver>

另外我去掉了REGISTRATION事件的监听——既然你知道它可能导致崩溃，直接移除更稳妥，FCM的注册逻辑交给SDK内部处理就好。

2. 广播优先级与竞争问题 #

默认情况下，你的接收器和Firebase自带的FirebaseMessagingReceiver会同时监听FCM广播。如果系统先把消息分发给Firebase的接收器，它可能已经弹出了默认通知，你再调用abortBroadcast()也无济于事。给你的intent-filter加上android:priority="1000"（系统允许的最大值），确保你的接收器先拿到消息并拦截。

3. 异常处理缺失导致的崩溃风险 #

你的onReceive方法里直接用context!!强制非空，而且没有包裹核心处理逻辑的异常捕获：

• 如果context为空（极端场景下可能发生），会直接抛出空指针崩溃
• 如果NotificationHandler里的逻辑（比如Glide加载图片、通知构建）出现异常，会导致广播接收器崩溃，甚至被系统标记为“不稳定组件”，限制后续的广播接收

建议加上异常捕获：

class FCMOverlordBroadcastReceiver: BroadcastReceiver(){
    override fun onReceive(context: Context?, intent: Intent) {
        try {
            context?.let { ctx ->
                // 推荐用官方API解析Intent，比手动传extras更可靠
                val remoteMessage = RemoteMessage.fromIntent(intent)
                NotificationHandler(ctx).onMessageReceived(remoteMessage)
                abortBroadcast()
            }
        } catch (e: Exception) {
            Log.e("FCMOverlord", "处理FCM消息失败", e)
            // 不要在这里崩溃，避免影响后续广播接收
        }
    }
}

另外注意：用RemoteMessage.fromIntent(intent)代替手动包装extras，是因为FCM内部可能对Intent做了特殊处理，直接用官方API解析兼容性更好。

4. 多进程场景的潜在问题 #

如果你的应用有多个进程，且这个接收器被系统分配到了非主进程运行，那么context会对应非主进程的上下文，可能导致Glide初始化失败、通知渠道创建异常等问题。可以在接收器声明里明确指定主进程：

android:process=":main"

5. Firebase SDK更新的兼容性风险 #

这种拦截系统广播的方式属于“非官方用法”，虽然目前可行，但如果后续Firebase SDK调整了消息分发逻辑（比如不再通过com.google.android.c2dm.intent.RECEIVE传递消息），你的接收器会直接失效。

长期来看，更稳妥的方案是只发送FCM数据消息（而非通知消息）：数据消息无论应用在前台/后台/杀死状态，都会触发onMessageReceived，你可以完全自定义通知样式、跳转逻辑，而且payload上限是4KB，远大于自定义数据的200字符限制。如果能调整Firebase控制台的发送方式，建议优先考虑这种官方方案。

内容的提问来源于stack exchange，提问作者Alpha