Notifee事件处理机制概述
notifee是一个功能强大的react native通知库，它提供了丰富的api来处理应用内、后台和远程通知。在ios平台上，notifee区分了两种主要的事件监听器：onbackgroundevent和onforegroundevent。
- onBackgroundEvent: 用于处理应用在后台或被终止状态时发生的通知相关事件。这通常包括接收到远程通知（EventType.DELIVERED）等。
- onForegroundEvent: 用于处理应用在前台运行时发生的通知相关事件，例如通知的显示、用户点击通知等。
理想情况下，当用户点击一个在后台状态下接收到的通知时，我们期望onBackgroundEvent能够捕获到EventType.PRESS事件，以便应用在启动或从后台恢复时立即响应。然而，实际操作中，iOS平台上的Notifee行为可能与预期有所不同。
onBackgroundEvent中EventType.PRESS的缺失
在集成Notifee时，开发者通常会在应用的入口文件（如index.js）中设置onBackgroundEvent监听器，以确保即使应用未运行也能处理通知事件。一个典型的设置示例如下：
import {AppRegistry} from 'react-native';
import App from './App';
import {name as appName} from './app.json';
import notifee, {EventType} from '@notifee/react-native';
notifee.onBackgroundEvent(async ({type, detail}) => {
console.log('onBackgroundEvent', {type, detail});
if (type === EventType.PRESS) {
console.log('用户点击了通知，ID:', detail.pressAction?.id);
// 执行点击后的逻辑
}
if (type === EventType.DELIVERED) {
console.log('通知已送达，ID:', detail.notification?.id);
}
});
AppRegistry.registerComponent(appName, () => App);当应用在后台接收到远程通知并使用notifee.displayNotification显示后，如果用户点击了该通知，期望EventType.PRESS能够被上述onBackgroundEvent捕获。然而，在iOS环境下，观察到的现象往往是，onBackgroundEvent仅记录了EventType.DELIVERED事件，而EventType.PRESS事件并未触发。这意味着应用无法在后台状态下通过onBackgroundEvent直接响应用户的通知点击操作。
用于显示通知的代码示例：
const handleBackgroundMessage = async message => {
console.log('处理后台消息');
await notifee.requestPermission();
// 显示通知
const notificationPayload = {
title: message.data.title || '默认标题',
body: message.data.body || '默认内容',
};
await notifee.displayNotification(notificationPayload);
};
// 假设此函数在接收到远程消息时被调用
// 例如：Firebase Messaging的setBackgroundMessageHandler解决方案：在onForegroundEvent中捕获点击事件
经过实践验证，虽然onBackgroundEvent未能如预期捕获EventType.PRESS，但当应用因用户点击通知而被唤醒或从后台切换到前台时，EventType.PRESS事件实际上会在onForegroundEvent监听器中触发。这提供了一个有效的解决方案或工作 HACK。
为了实现这一目标，我们需要在应用的根组件或任何合适的生命周期钩子中设置onForegroundEvent监听器。一个推荐的做法是在React组件的useEffect钩子中进行设置，并确保在组件卸载时清理监听器。
import React, {useEffect} from 'react';
import notifee, {EventType} from '@notifee/react-native';
const App: React.FC = () => {
useEffect(() => {
// 设置前台事件监听器
const unsubscribe = notifee.onForegroundEvent(({type, detail}) => {
switch (type) {
case EventType.PRESS:
console.log('用户在前台点击了通知:', detail.notification);
// 在这里处理通知点击逻辑，例如导航到特定页面
// detail.notification 包含了被点击通知的详细信息
break;
case EventType.DELIVERED:
console.log('通知在前台已送达:', detail.notification);
break;
// 可以根据需要处理其他前台事件类型
}
});
// 清理函数，在组件卸载时移除监听器
return () => unsubscribe();
}, []); // 空依赖数组确保只在组件挂载和卸载时执行一次
// ... 应用的其他组件内容
return (
// ...
);
};
export default App;工作原理分析： 当用户点击一个通知，并且应用当前处于后台或未运行状态时，iOS系统会尝试启动或唤醒应用。一旦应用被激活并进入前台，Notifee的onForegroundEvent监听器就会被激活，并捕获到之前被点击的通知所对应的EventType.PRESS事件。
注意事项与潜在延迟： 这种方法虽然有效，但需要注意以下几点：
- 延迟问题： 由于事件是在应用被唤醒并加载到前台后才触发，从用户点击通知到EventType.PRESS事件被处理之间可能会有短暂的延迟（通常约为1秒）。这可能对用户体验造成轻微影响，取决于应用对即时响应的需求。
- 启动流程： 这种处理方式意味着应用需要完成一定的启动流程才能响应点击。对于需要快速跳转到特定界面的场景，可能需要额外考虑如何优化启动速度。
- 文档差异： Notifee的官方文档在某些部分可能存在误导，尤其是在关于EventType.PRESS在后台事件中的行为描述上。开发者应以实际测试结果为准。
- getInitialNotification的替代： Notifee也提供了getInitialNotification()方法来获取应用启动时被点击的通知。在某些情况下，这可能是一个更直接的替代方案，但实际测试中，它也可能不总是可靠地捕获到EventType.PRESS事件。将onForegroundEvent作为主要捕获手段，可以作为一种更通用的实践。
总结
在Notifee的iOS集成中，当应用处于后台状态时，onBackgroundEvent无法可靠地捕获用户点击通知的EventType.PRESS事件是一个常见挑战。通过将EventType.PRESS事件的监听逻辑转移到onForegroundEvent中，我们可以有效地解决这一问题。尽管这种方法可能引入轻微的延迟，但它提供了一个稳定的机制来响应用户点击通知，从而确保了核心的用户交互体验。开发者应根据项目的具体需求，权衡响应速度和实现复杂性，选择最合适的通知事件处理策略。
