移动开发原生移动【免费下载链接】react-native-push-notificationReact Native Local and Remote Notifications项目地址https://gitcode.com/gh_mirrors/re/react-native-push-notification点击查看免费下载本文以仓库 CHANGELOG.md 为骨架系统梳理 react-native-push-notification 从 3.1.1 到 8.1.1 的核心演进脉络Android 通知渠道Channel管理机制的根本变革、AndroidManifest 配置项的迭代、取消通知 API 的命名迁移、iOS 侧依赖体系的调整以及定时/重复/内联回复等能力的补齐。读者阅读后可完整掌握各版本升级的破坏性变更清单、对应的迁移操作步骤并理解底层 Java 模块与 JS API 层的真实实现逻辑为存量项目升级或新项目选型提供可落地的依据。一、版本演进总览一条从「库代管渠道」到「开发者自治」的路线react-native-push-notification是面向 iOS / Android 的本地与远程通知库其变更历史本身即是 Android 通知体系演进的缩影。从 CHANGELOG 可见项目版本线经历了三个关键阶段阶段代表版本核心主题早期兼容期3.1.1 – 3.5.22018–2020补齐 Android OreoAPI 26、FirebaseFCM支持修复大量稳定性问题能力扩张期4.0.0 – 5.1.02020引入 Channel 相关 API、大图通知、onlyAlertOnce、自定义渠道统一 iOS/Android 返回结构渠道自治与收敛期6.0.0 – 8.1.12020–2021渠道创建责任移交开发者、iOS 依赖改为 peerDependency、取消 API 命名规范化其中 v6.0.0、v8.0.0 是两次最需要开发者关注的破坏性版本下文将分别展开。仓库根目录的 package.json 显示当前版本为8.1.1与 CHANGELOG 最新发布版本一致。二、Android 通知渠道Channel管理v6.0.0 的根本性变革v6.0.0 是 Android 侧最具结构性影响的一次变更。CHANGELOG 明确写道In order to limit the scope of responsability of this library, developers are now responsible of the creation of the channels.这意味着渠道的创建责任从库移交给了开发者。具体影响如下必须在使用前创建渠道开发者需在应用启动时调用createChannel再触发任何通知channelId变为必填在localNotification与localNotificationSchedule中不传channelId会触发警告一批参数被废弃channelName、channelDescription、importance均不再作为通知选项使用改由渠道定义时指定一批 Manifest 条目被废弃meta-data android:namecom.dieam.reactnativepushnotification.notification_channel_name android:value.../ meta-data android:namecom.dieam.reactnativepushnotification.notification_channel_description android:value.../ meta-data android:namecom.dieam.reactnativepushnotification.channel_create_default android:value.../这一变更同时被用来规避 issue #1649默认渠道创建时机引发的通知不触发问题。从源码看createChannel最终由 JS 侧 component/index.android.js 桥接到原生模块再落到 RNPushNotificationHelper.java 的createChannel(ReadableMap)其读取channelId、channelName、channelDescription、playSound、soundName、importance、vibrate等字段并通过checkOrCreateChannel在 API 26 以下直接返回false该功能仅在 Android Oreo 及以上生效。渠道创建后不可更新因此若修改渠道配置必须更换新的channelId。三、默认渠道回退链Manifest 配置的三个层级v6.1.0 引入了「默认渠道」的声明方式为本地通知提供了一条清晰的回退链。CHANGELOG 中给出了完整定义meta-data android:namecom.dieam.reactnativepushnotification.default_notification_channel_id android:value.../回退顺序为优先读取com.dieam.reactnativepushnotification.default_notification_channel_id若未定义回退到 Firebase 的com.google.firebase.messaging.default_notification_channel_id若仍未定义回退到 Firebase 默认渠道fcm_fallback_notification_channel。这一回退逻辑在 RNPushNotificationConfig.java 中有完全对应的实现return getStringValue(KEY_NOTIFICATION_DEFAULT_CHANNEL_ID, getStringValue(KEY_NOTIFICATION_FIREBASE_DEFAULT_CHANNEL_ID, fcm_fallback_notification_channel) );此外RNPushNotificationHelper.java 在构建通知时也会读取该回退链当传入的 bundle 中缺少channelId时channel_id会取自RNPushNotificationConfig.getNotificationDefaultChannelId()。也就是说即使 JS 侧漏传channelId只要 Manifest 配置了默认渠道通知仍能落到正确渠道上。四、AndroidManifest 通知配置的迭代前台策略、开机恢复与 Actions 接收器4.1 前台通知开关notification_foregroundv3.4.0 起可在 Manifest 中声明前台通知策略默认false即前台收到的远程通知不弹系统通知避免与本地通知重复展示meta-data android:namecom.dieam.reactnativepushnotification.notification_foreground android:valuefalse/该开关在 RNPushNotificationConfig.java 中通过metadata.getBoolean(KEY_NOTIFICATION_FOREGROUND, false)读取。若希望前台也展示远程通知需结合 README 的建议在onNotification中根据notification.foreground手动触发本地通知并注意通过userInfo打标避免onNotification递归死循环。4.2 开机恢复调度BOOT_COMPLETED 与 QUICKBOOT_POWERONv6.0.0 移除了对BOOT_COMPLETED意图的强制检查从而允许更多启动广播类型。CHANGELOG 建议的接收器配置为receiver android:namecom.dieam.reactnativepushnotification.modules.RNPushNotificationBootEventReceiver intent-filter action android:nameandroid.intent.action.BOOT_COMPLETED / action android:nameandroid.intent.action.QUICKBOOT_POWERON / action android:namecom.htc.intent.action.QUICKBOOT_POWERON/ /intent-filter /receiver对应的 RNPushNotificationBootEventReceiver.java 在onReceive中遍历 SharedPreferences键为rn_push_notification中持久化的全部调度记录若fireDate已过期则直接sendToNotificationCentre展示否则通过sendNotificationScheduledCore重新注册 AlarmManager 闹钟。这正是定时通知在设备重启后依然生效的底层保证。4.3 通知 Actions 接收器v4.0.0 要求额外声明 Actions 接收器以处理通知按钮点击receiver android:namecom.dieam.reactnativepushnotification.modules.RNPushNotificationActions /同时移除了Notifications.registerNotificationActions()与RNPushNotificationRegistrationService后者须从 Manifest 中删除DeviceEventEmitter.addListener(notificationActionReceived, ...)被.configure()中的onAction回调取代。五、取消与查询 API 的命名规范化v8.0.0v8.0.0 做了两项影响调用方代码的调整cancelLocalNotifications更名为cancelLocalNotification去掉末尾的s旧名称保留弃用警告。在 index.js 中可以看到迁移垫片Notifications.cancelLocalNotifications function(userInfo) { console.warn(This method is now deprecated, please use cancelLocalNotification (remove the ending s).); return this.cancelLocalNotification(userInfo); };userInfo不再自动填充通知id。此前库会把id注入userInfo以便取消操作v8.0.0 移除了该行为CHANGELOG 认为对多数使用者无影响。此外 v8.0.0 还修复了 Android 上cancelLocalNotification()失效的问题issue #2100 与 #2122。从 RNPushNotificationHelper.java 的实现可见取消操作会三管齐下通过AlarmManager.cancel撤销闹钟、从 SharedPreferences 删除持久化记录、再从通知栏notificationManager.cancel移除。六、iOS 侧演进依赖独立、能力对齐与 repeatType 扩展iOS 侧的核心逻辑始终委托给react-native-community/push-notification-iosv6.0.0 起该库成为peerDependency必须由项目自行安装。当前 package.json 声明react-native-community/push-notification-ios: ^1.10.1v8.1.0 将其升级至 1.10.0并允许 iOS 的repeatType使用month、week、day、hour、minutev8.0.0 引入picture参数作为双端通用属性Android 端是bigPictureUrl的别名该映射在 index.js 与 index.js 中实现v7.4.0 为 iOS 增加subtitle通知副标题v8.1.1 修复 iOS 重复通知的时序问题并将 iOS 依赖升至修复版。iOS 的重复通知在 index.js 中被转换为repeatsComponent结构second、minute、hour、day、dayOfWeek五个布尔位例如repeatType: week会同时置位second/minute/hour/dayOfWeek而repeatType: month置位second/minute/hour/day。注意 iOS 不支持repeatTime。七、Android 定时与重复通知的底层机制7.1 定时通知的调度链路localNotificationSchedule在 index.js 将date转为毫秒时间戳fireDate后调用原生scheduleLocalNotification。原生侧 RNPushNotificationHelper.java 使用AlarmManager默认走setExact(RTC_WAKEUP, fireDate, pendingIntent)精确触发当allowWhileIdle为 true 且 SDK 23 时走setExactAndAllowWhileIdle使通知在 Doze 模式下也能按点触发。CHANGELOG 与 README 均提醒allowWhileIdle会显著影响低电量待机时的功耗仅应在通知必须准点触发如日历提醒时开启。调度记录会通过 RNPushNotificationAttributes.java 序列化为 JSON 存入 SharedPreferences供开机恢复与getScheduledLocalNotifications查询使用。7.2 重复通知repeatType repeatTimev7.4.0 起 Android 支持repeatTime指定重复间隔倍数Android 的repeatType可选month、week、day、hour、minute、time六种当repeatType为time时repeatTime表示两次触发间隔的毫秒数且必须大于 0否则被 RNPushNotificationHelper.java 直接拒绝其他类型的repeatTime默认为 1increment repeatTime 0 ? (int) repeatTime : 1通过Calendar.add(repeatField, increment)计算下一次触发时间RNPushNotificationHelper.java。例如每隔一天触发一次PushNotification.localNotificationSchedule({ message: My Notification Message, date: new Date(Date.now() 60 * 1000), repeatType: day, repeatTime: 2, });值得注意的实现细节重复通知不是用setRepeatingAPI 19 起不精确可能延迟数分钟而是每次触发后由scheduleNextNotificationIfRepeating重新计算下一次fireDate并重新调度从而保证准点。八、v4.0.0 – v5.1.0 期间沉淀的核心 API 能力CHANGELOG 记录了该阶段密集新增的 API多数沿用至今API说明引入版本PushNotification.createChannel(info, cb)创建自定义渠道5.0.0PushNotification.getChannels(cb)列出全部渠道 ID4.0.0PushNotification.channelExists(id, cb)查询渠道是否存在4.0.0PushNotification.channelBlocked(id, cb)查询渠道是否被用户屏蔽importance 为 NONE4.0.0PushNotification.deleteChannel(id)删除渠道4.0.0PushNotification.getScheduledLocalNotifications(cb)列出尚未展示的本地通知4.0.0largeIconUrl/bigPictureUrl基于 URL 加载大图标与大图4.0.0shortcutId/showWhen/groupSummary/onlyAlertOnce角标、时间展示、分组、单次提醒4.0.0–5.0.0when/usesChronometer/timeoutAfter时间戳、秒表样式、自动取消时长5.1.0messageId与react-native-firebase/messaging集成定位5.0.0这些 API 的 JS 侧实现均可在 index.js 与 component/index.android.js 中一一对应找到原生侧渠道查询/删除逻辑在 RNPushNotificationHelper.java。内联回复v7.0.0Android 内联回复要求将动作命名为ReplyInput并配合reply_placeholder_text与reply_button_textPushNotification.localNotificationSchedule({ message: My Notification Message, date: new Date(Date.now() (60 * 1000)), actions: [ReplyInput], reply_placeholder_text: Write your response..., reply_button_text: Reply });回复内容通过notification.reply_text在回调中获取。原生侧 RNPushNotificationHelper.java 使用RemoteInput.Builder(KEY_TEXT_REPLY)构建内联输入框仅在 API 20KITKAT_WATCH及以上生效。九、数据一致性iOS/Android 返回结构统一v5.0.0v5.0.0 统一了双端onNotification与popInitialNotification的返回结构主要修正点popInitialNotification()与onNotification()现在返回相同格式popInitialNotification在configure()中仅在应用启动时触发一次与 iOS 对齐且不会与用户点击通知导致的onNotification重复触发notification.foreground修正了此前大多数场景误报false的问题。结构转换发生在 index.js 的_transformNotificationObject中iOS 侧从PushNotificationIOS的getData()/getMessage()/getBadgeCount()/getTitle()/getSubtitle()/getSound()组装字段Android 侧则把字符串化的data与userInfo合并解析为对象并删除userInfo、notificationId等冗余字段。十、受支持的 React Native 版本对照CHANGELOG 末尾保留了组件版本与 RN 版本的对应关系供存量项目核对组件版本支持的 RN 版本1.0.7≤ 0.271.0.80.282.0.10.292.0.20.30 / 0.31 / 0.32≥ 2.1.0≥ 0.33当前 package.json 的 peerDependencies 声明react-native: 0.33与 CHANGELOG 末行的结论一致。十一、升级迁移清单按版本归纳基于 CHANGELOG 的破坏性变更整理出如下实践清单升级到 v4.0.0删除 Manifest 中的RNPushNotificationRegistrationService将DeviceEventEmitter的notificationActionReceived监听迁移到configure({ onAction })为处理按钮点击添加RNPushNotificationActions接收器。升级到 v6.0.0在应用启动处创建通知渠道为localNotification/localNotificationSchedule传入channelId移除废弃的channelName/channelDescription/importance选项及三个废弃 Manifest 条目如需快速开机恢复将RNPushNotificationBootEventReceiver的 intent-filter 更新为包含BOOT_COMPLETED与QUICKBOOT_POWERON。升级到 v8.0.0将cancelLocalNotifications调用改为cancelLocalNotification不再依赖userInfo.id做取消操作确认已通过 npm/yarn 安装react-native-community/push-notification-iospeerDependency。反复核对项localNotification依赖 Manifest 中的notification_foreground与notification_color元数据后者在 RNPushNotificationConfig.java 中通过ResourcesCompat.getColor解析资源 ID示例工程可参考 example/NotifService.js 与 example/NotificationHandler.js 中的完整接入写法。十二、仓库维护现状与替代方案提示README 明确说明该仓库当前未被积极维护原因包括维护者时间不足与 iOS/Android 通知体系的复杂性并建议评估 Notifee、react-native-notifications 等替代方案。本文档CHANGELOG所描述的能力与 8.1.1 版本一致可作为评估或迁移时的行为基准在选用替代方案前建议先依据上文清单梳理现有项目对渠道、重复通知、内联回复等特性的依赖程度再决定迁移策略。赞分享移动开发原生移动【免费下载链接】react-native-push-notificationReact Native Local and Remote Notifications项目地址https://gitcode.com/gh_mirrors/re/react-native-push-notification点击查看免费下载相关推荐Mongoose 8 升级迁移指南从 7.x 到 8.x 的全面破坏性变更解析Mongoose 8 升级迁移指南从 7.x 到 8.x 的全面破坏性变更解析 从 Mongoose 7.x 升级到 8.x 引入了一系列破坏性变更back数据库后端Create React App 3.x 版本演进全解析从 3.0 到 3.4 的新特性、破坏性变更与升级迁移指南Create React App 3.x 版本演进全解析从 3.0 到 3.4 的新特性、破坏性变更与升级迁移指南 本指南以当前仓库 CHANGELOG 3.前端开发工具CLI构建工具Polly.JS 版本演进全解析从 1.x 到 6.x 的破坏性变更、迁移路径与源码印证Polly.JS 版本演进全解析从 1.x 到 6.x 的破坏性变更、迁移路径与源码印证 Polly.JS 是一款用于录制Record、回放Replay测试开发工具上一篇Wren CLI 的 Stat 类详解读取文件系统条目的底层元数据下一篇TypeScript 类型体操实战用元组长度实现 MinusOne为数字类型做减法创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考