React Native Update

核心功能

react-native-update 技能专注于将 Pushy 热更新能力快速接入 React Native 项目，支持 React Native CLI 与 Expo 两种工程结构。其核心工作流包括：自动识别项目类型（CLI/Expo）→ 执行最小化依赖安装 → 完成 iOS/Android 原生层必要改动（Bundle URL 映射、MainApplication 集成点）→ 注入 Pushy 客户端与 UpdateProvider 启动代码 → 运行诊断脚本排查常见遗漏 → 输出可执行的「已完成/待补全/待验证」清单。

显著优点

• 双栈覆盖：同时支持传统 React Native CLI 与 Expo Managed/Bare Workflow，降低多项目维护成本。
• 最小侵入：强调「copy-paste-safe」与「smallest viable changes」，避免大范围重构现有架构。
• 诊断闭环：内置 integration_doctor.sh 脚本，可在集成后自动扫描常见配置遗漏（如 appKey 缺失、update.json 未接入、原生层未注册等）。
• 冲突预警：明确提示 Expo 项目中 expo-updates 与 Pushy 的冲突风险，并提供排查指引。

潜在局限与风险

• Debug 模式限制：技能明确告知热更新仅在 Release 构建生效，Debug 调试阶段无法验证完整流程，需开发者具备 Release 打包经验。
• 原生差异适配：面对 Monorepo、混合原生代码或重度定制原生层（如自定义 ReactActivity/ReactFragment）时，只能提供「定向 patch 指导」而非全自动改写，需开发者具备一定 Android/iOS 原生知识。
• 平台策略差异：iOS 与 Android 的 checkStrategy/updateStrategy 配置逻辑、审核合规要求不同，需分别验证。

适合人群

• 需要为现有 React Native 项目快速接入热更新能力的移动端开发者。
• 使用 Expo Bare Workflow、希望替换或补充 expo-updates 的团队。
• 对原生层改动有基础了解，但希望减少重复配置工作的工程师。

常规风险

• appKey/update.json 泄露风险：Pushy 的 appKey 与 update.json 地址若硬编码在客户端，存在被逆向提取后滥用的可能，建议配合服务端动态下发或签名验证。
• 更新策略误配：checkStrategy 与 updateStrategy 设置不当可能导致强制更新打断用户体验，或静默更新未生效。
• 原生层版本兼容性：React Native 版本升级（尤其是 0.70+ 新架构）可能导致原生集成点变更，需持续跟进官方 Playbook。

核心用法

本Skill专注于解决React Native热更新集成的复杂性痛点，为React Native CLI和Expo双平台项目提供端到端的集成指导。使用流程清晰分为六个阶段：首先自动检测项目类型（CLI或Expo）及目标平台；其次依据references/integration-playbook.md执行精准的依赖安装步骤；接着完成iOS/Android原生层的关键配置注入，包括Bundle URL重写和MainApplication集成点适配；随后添加Pushy客户端与UpdateProvider的最小化启动代码；再通过scripts/integration_doctor.sh诊断脚本自动扫描常见遗漏；最终输出结构化的行动清单（已完成/待补充/待验证项），确保集成过程可追溯、可验证。

显著优点

来源权威可靠：直接对接sunnylqm维护的react-native-update开源项目，该方案在国内RN社区拥有广泛生产验证，热更新成功率和稳定性经过大规模用户检验。

集成路径极简：坚持"最小可行改动"原则，所有代码片段均经过copy-paste安全设计，避免侵入式架构改造，最大限度保护既有代码库整洁性。

冲突预判完备：内置Expo项目专属的expo-updates冲突检测机制，提前警示版本管理器互斥风险，显著降低集成后的调试成本。

诊断工具实用：integration_doctor.sh脚本覆盖80%以上的常见集成失误场景，包括appKey缺失、update.json路径错误、原生层未正确hook等，实现问题前置发现。

潜在缺点与局限性

平台覆盖边界：当前主要优化中文档和脚本针对标准单仓库结构，对于monorepo、混合原生开发（Flutter/RN混编）或重度定制化的原生层，仅能提供patch级指导而非完整重写方案。

验证环境依赖：Skill明确声明热更新仅在release模式生效，debug模式无法验证，这意味着开发者必须完成完整打包流程才能确认集成成功，延长了反馈循环。

版本追踪滞后：作为文档型Skill，其推荐的react-native-update版本可能略滞后于上游最新发布，建议用户结合实际版本兼容性说明进行判断。

适合的目标群体

• 需要快速为现有RN项目添加热更新能力的中小团队开发者
• 从Expo Managed Workflow迁移到Bare Workflow后需要替代方案的技术负责人
• 在热更新集成过程中反复遭遇原生层配置陷阱、寻求标准化解决方案的RN工程师
• 对代码改动侵入性敏感、希望在现有架构最小改动前提下获得热更新能力的保守型项目

常规使用风险

性能风险：热更新机制本身会增加启动时的网络检测开销，在弱网环境下可能导致首次启动感知延迟，需在更新策略（checkStrategy/updateStrategy）中合理配置检测时机。

依赖冲突风险：react-native-update与expo-updates、CodePush等同类方案存在互斥性，Skill虽已内置冲突警告，但若项目历史遗留多版本管理器代码，仍可能导致构建失败。

发布合规风险：iOS App Store对热更新有严格审核政策，需确保更新内容仅限于JavaScript/资源层面，不触及原生功能变更，Skill本身不提供合规审查，开发者需自行把控更新包内容边界。

长期维护风险：热更新服务端（Pushy）的可用性直接影响更新下发，建议评估服务商稳定性SLA，并保留应急的全量发版通道。