李国乾-便利蜂ReactNative多版本共存的平滑升级实践.pdfVIP

便利蜂 React Native 多版本共存的 平滑升级实践 便利蜂 / 李国乾 React Hook React 17 Metro JSI Hermes Engine 0.57 0.61 0.52 0.59 0.64 Babel7 Fast Refresh TypeScript 研发效率 拥抱社区 性能 Bugfix ⾮稳定版 ⼤量侵⼊式修改 ⼤纲 • 便利蜂升级 RN 的背景 • 升级策略选择 • 实现多版本共存 • 实践中遇到的问题 ⼤纲 • 便利蜂升级 RN 的背景 • 升级策略选择 • 实现多版本共存 • 实践中遇到的问题 移动端业务 • 重度依赖 RN • 基于 0.3x 版本 • 复杂的 B 端系统 应⽤举例 Git Repo JS Bundle ⼤纲 • 便利蜂升级 RN 的背景 • 升级策略选择 • 实现多版本共存 • 实践中遇到的问题 ⽆感知升级 框架抹平 Breaking Change 业务⽆感知，静默升级 局限：适⽤场景少 有感知升级、单版本 提供 『升级指南』 各个部⻔、业务线统⼀升级、测试 ⼀次发版全部升级 有感知升级、多版本 提供 『升级指南』 各个部⻔、业务线分别升级、测试 ⽆需⼀次发版全部升级 可以选择不升级 微前端 微前端架构旨在解决单体应⽤在⼀个相对⻓的时间跨度下，由于参与的⼈员、团 队的增多、变迁，从⼀个普通应⽤演变成⼀个巨⽯应⽤(Frontend Monolith) 后，随之⽽来的应⽤不可维护的问题。 —— /guide 79% 22% 有感知升级、多版本 22% ⾼频迭代项⽬：升级 36% 低频迭代项⽬：增量升级 43% 不迭代项⽬：不升级 总结 ⽆感知升级：适⽤于改动⼩的场景，版本差异不能过⼤ 有感知升级，单版本：说服所有部⻔⼀起升级 有感知升级，多版本：部分项⽬升级，多版本⻓期共存 ⼤纲 • 便利蜂升级 RN 的背景 • 升级策略选择 • 实现多版本共存 • 实践中遇到的问题 MVP ⽅案 JavaScript Runtime Bridge Native Modules App MVP ⽅案 JavaScript Runtime JavaScript Runtime Runtime 隔离 Bridge