一、需求背景：

1、**需求评审后，按照原生客户端的排期，要年后2月份才能上线。时间太久；

2、客户端人力资源紧缺（iOS 3，Android 2），如果承接***需求，人力被占用，其他需求都无法安排；

问题点：大需求场景下，暴露出当前的团队规模结合当前技术栈在承接能力方面有所欠缺；

二、需求目的：

• 1、客户端建设跨端和动态化能力，提高工作效率，缩短需求交付时间。

• 2、通过新的技术栈，优化大需求承接能力：大前端技术栈，前端也可以开发客户端需求

三、需求详情：

1、app建设跨端能力：app内接入react-native模块；开发通用基础能力；

2、建设动态化能力：包管理平台

四、需求预期收益：

目标值：综合提效30%

人效提升计算公式：∑（Android Native总人日+iOS Native总人日-RN总人日）/ ∑（Android Native总人日+iOS Native总人日）

示例：

实现某一需求的排期如下：

• 纯展示需求

提效结果： （10 - 5）/ 10 = 50%

• native和rn弱交互需求，涉及少量native开发

提效结果： （10 - 7）/ 10 = 30%

• native和rn交互需求，涉及一定量native开发

提效结果： （10 - 9）/ 10 = 10%

五、方案内容

5.1、什么是跨端和动态化

app需求交付流程

image.png

开发流程分析（跨端）

image.png

使用原生开发：

• 开发阶段：iOS和Android需要分别指定开发人员（2人），编写各自平台的代码；

• 测试阶段：需要分别指定不同平台的测试人员（2人）；

使用跨端开发：

• 开发阶段：指定单一单发人员（1人），编写js代码，支持两个平台使用，部分场景需要额外编写一些适配代码；

• 测试阶段：由于是一套代码，仅需要一个人测试即可（1人），需要额外关注一下不同平台的适配是否正常；

发布流程分析（动态化）

image.png

使用原生发版：

• 应用打包后，需要分别提交各自的应用商店审核，审核通过后，再操作上线。

  • 依赖商店审核时间，存在审核不通过甚至拒绝上架的问题，需要重新提审；

  • 对紧急bug修复和时间敏感需求不友好；

• app发版后，仅仅是更新了应用商店内的版本；

  • 需要引导用户升级，但是用户有可能不升级app，存在版本碎片化的问题；

  • 新功能无法短时间内触达全量用户；

使用动态化发版：

• 发版仅仅是往自有服务器提交静态资源，不再受限于应用商店，灵活可控。

• 直接提交静态资源到自己的服务器，app内自动拉取最新版本，用户启动app即可看到新功能。新功能可以快速触达全量用户；

目标流程

image.png

跨端：一套代码多端投放。开发、测试效率都更高。

动态化：动态更新。用户打开app的时候，无感升级到最新的版本。绕过商店审核，版本管理更灵活。

5.2、技术选型

React-native： flutter

2015年Facebook发布的跨端开发框架，目前得到了国内外很多知名公司的青睐。

国内：阿里、腾讯、百度、字节、京东、美团、快手、funplus等

国外：Facebook、特斯拉、Shopee等

使用方式

行业内rn的四种使用方式：使用rn的常见方式

一、整个app使用RN开发： 适合新项目

二、native内嵌入单一RN模块： 适合存量项目

三、native和rn混编：适合存量项目

四、RN容器化： 适合多个app项目

5.3、RN的路线规划

二 ---> 三 ---> 四

单一的RN模块 ---> native和RN混编 ---> 容器化复用

三 ---> 四

native和RN混编 ---> 容器化复用

执行步骤：三步走

• 【可用】试点业务跑通技术方案：试点需求周四确定

• 【好用】能力建设：建设更多高质量的跨端基础能力

• 【爱用】打磨细节：更强大更复杂的能力建设以及使用体验的优化

5.4、阶段划分

整体分为三个阶段

阶段一：（2023.Q4）

• 快速提供跨端能力（2023.10）

• 支撑业务开发：社区需求（2022.12）

阶段目标：

阶段二：（2024.Q2）

• 支撑更多业务开发

• 基建能力建设

• 跨端人才培养

阶段目标：

阶段三：（长期）

• 提升开发体验和效率

• 更多基建完善

• 打磨细节

阶段目标：

六、资源投入

人力：成立跨端专项小组：

服务器：搭建热更新服务的时候至少需要一台静态资源服务器（2024.Q2）

七、依赖方

后期建设包管理平台的时候，需要运维参与

八、风险点

整体方案比较成熟，技术上无明显风险点。