一、需求背景：
1、**需求評審后，按照原生客戶端的排期，要年后2月份才能上線。時間太久；
2、客戶端人力資源緊缺（iOS 3，Android 2），如果承接***需求，人力被占用，其他需求都無法安排；
問題點：大需求場景下，暴露出當前的團隊規(guī)模結合當前技術棧在承接能力方面有所欠缺；
二、需求目的：
1、客戶端建設跨端和動態(tài)化能力，提高工作效率，縮短需求交付時間。
2、通過新的技術棧，優(yōu)化大需求承接能力：大前端技術棧，前端也可以開發(fā)客戶端需求
三、需求詳情：
1、app建設跨端能力：app內接入react-native模塊；開發(fā)通用基礎能力；
2、建設動態(tài)化能力：包管理平臺
四、需求預期收益：
目標值：綜合提效30%
人效提升計算公式：∑（Android Native總人日+iOS Native總人日-RN總人日）/ ∑（Android Native總人日+iOS Native總人日）
示例：
實現(xiàn)某一需求的排期如下：
- 純展示需求
| 開發(fā)方式 | iOS | Android | rn | 合計 |
|---|---|---|---|---|
| native | 5 | 5 | 10 | |
| rn | 5 | 5 |
提效結果： （10 - 5）/ 10 = 50%
- native和rn弱交互需求，涉及少量native開發(fā)
| 開發(fā)方式 | iOS | Android | rn | 合計 |
|---|---|---|---|---|
| native | 5 | 5 | 10 | |
| rn | 1 | 1 | 5 | 7 |
提效結果： （10 - 7）/ 10 = 30%
- native和rn交互需求，涉及一定量native開發(fā)
| 開發(fā)方式 | iOS | Android | rn | 合計 |
|---|---|---|---|---|
| native | 5 | 5 | 10 | |
| rn | 2 | 2 | 5 | 9 |
提效結果： （10 - 9）/ 10 = 10%
五、方案內容
5.1、什么是跨端和動態(tài)化
app需求交付流程
開發(fā)流程分析（跨端）
使用原生開發(fā)：
開發(fā)階段：iOS和Android需要分別指定開發(fā)人員（2人），編寫各自平臺的代碼；
測試階段：需要分別指定不同平臺的測試人員（2人）；
使用跨端開發(fā)：
開發(fā)階段：指定單一單發(fā)人員（1人），編寫js代碼，支持兩個平臺使用，部分場景需要額外編寫一些適配代碼；
測試階段：由于是一套代碼，僅需要一個人測試即可（1人），需要額外關注一下不同平臺的適配是否正常；
發(fā)布流程分析（動態(tài)化）
使用原生發(fā)版：
-
應用打包后，需要分別提交各自的應用商店審核，審核通過后，再操作上線。
依賴商店審核時間，存在審核不通過甚至拒絕上架的問題，需要重新提審；
對緊急bug修復和時間敏感需求不友好；
-
app發(fā)版后，僅僅是更新了應用商店內的版本；
需要引導用戶升級，但是用戶有可能不升級app，存在版本碎片化的問題；
新功能無法短時間內觸達全量用戶；
使用動態(tài)化發(fā)版：
發(fā)版僅僅是往自有服務器提交靜態(tài)資源，不再受限于應用商店，靈活可控。
直接提交靜態(tài)資源到自己的服務器，app內自動拉取最新版本，用戶啟動app即可看到新功能。新功能可以快速觸達全量用戶；
目標流程
跨端：一套代碼多端投放。開發(fā)、測試效率都更高。
動態(tài)化：動態(tài)更新。用戶打開app的時候，無感升級到最新的版本。繞過商店審核，版本管理更靈活。
5.2、技術選型
React-native： flutter
2015年Facebook發(fā)布的跨端開發(fā)框架，目前得到了國內外很多知名公司的青睞。
國內：阿里、騰訊、百度、字節(jié)、京東、美團、快手、funplus等
國外：Facebook、特斯拉、Shopee等
使用方式
行業(yè)內rn的四種使用方式：使用rn的常見方式
一、整個app使用RN開發(fā)： 適合新項目
二、native內嵌入單一RN模塊： 適合存量項目
三、native和rn混編：適合存量項目
四、RN容器化： 適合多個app項目
5.3、RN的路線規(guī)劃
二 ---> 三 ---> 四
單一的RN模塊 ---> native和RN混編 ---> 容器化復用
三 ---> 四
native和RN混編 ---> 容器化復用
| 序號 | 能力項 | 人力投入 | 備注 |
|---|---|---|---|
| 1 | 端內集成rn模塊（iOS、Android） | iOS：1Android：1 | |
| 2 | 熱更新 | iOS：1Android：1前端：1 | 需要支撐不同的環(huán)境：feature、uat、pre、daily、prod |
| 3 | HDesign UI 組件庫（RN） | ||
| 4 | 分包 | iOS：1Android：1前端：1 | |
| 5 | 調試工具 | iOS：1Android：1 | |
| 6 | 包管理平臺 | iOS：1Android：1前端：1運維：1 | |
| 7 | 路由協(xié)議 | iOS：1Android：1前端：1 | |
| 8 | 通知中心 | iOS：1Android：1前端：1 | |
| 9 | bridge管理中心 | iOS：1Android：1前端：1 | |
| 10 | 集成對h5的支持 | 前端：1 | |
| 11 | 容器建設 | iOS：1Android：1 | |
| 12 | 封裝跨端包，提供給更多app快速接入 | iOS：1Android：1 | |
| 13 | 性能監(jiān)控方案 | iOS：1Android：1前端：1 | |
| 14 | 線上錯誤收集 | iOS：1Android：1前端：1 |
執(zhí)行步驟：三步走
【可用】試點業(yè)務跑通技術方案：試點需求周四確定
【好用】能力建設：建設更多高質量的跨端基礎能力
【愛用】打磨細節(jié)：更強大更復雜的能力建設以及使用體驗的優(yōu)化
5.4、階段劃分
整體分為三個階段
階段一：（2023.Q4）
快速提供跨端能力
（2023.10）支撐業(yè)務開發(fā)：社區(qū)需求
（2022.12）
階段目標：
| 序號 | 內容 | 時間 |
|---|---|---|
| 1 | 端內集成rn模塊（iOS、Android） | |
| 3 | 試點業(yè)務落地 | 待細評,預期 |
階段二：（2024.Q2）
支撐更多業(yè)務開發(fā)
基建能力建設
跨端人才培養(yǎng)
階段目標：
| 序號 | 內容 | 時間 |
|---|---|---|
| 1 | 提供熱更新能力 | |
| 2 | HDesign UI 組件庫（RN） | |
| 3 | 分包 | |
| 4 | 調試工具 | |
| 5 | 包管理平臺 | |
| 6 | 路由協(xié)議 | |
| 7 | 通知中心 | |
| 8 | bridge管理中心 | |
| 9 | 性能監(jiān)控方案 | |
| 10 | 線上錯誤收集 | |
| 11 | 調試工具 | |
| 12 | 包管理平臺 | |
| 13 | 單元測試 |
階段三：（長期）
提升開發(fā)體驗和效率
更多基建完善
打磨細節(jié)
階段目標：
| 序號 | 內容 | 時間 |
|---|---|---|
| 1 | 集成對h5的支持 | |
| 2 | 容器建設 | |
| 3 | 封裝跨端包，提供給更多app快速接入 |
六、資源投入
人力：成立跨端專項小組：
| 方向 | Android | iOS | 前端 | 測試 |
|---|---|---|---|---|
| 人力 | 1 | 1 | 1.5 | 1 |
服務器：搭建熱更新服務的時候至少需要一臺靜態(tài)資源服務器（2024.Q2）
七、依賴方
后期建設包管理平臺的時候，需要運維參與
八、風險點
整體方案比較成熟，技術上無明顯風險點。
