Lumos：移動端混合棧跨端提效實踐

一. 背景：

隨着哈囉出行發展，移動端業務場景越來越豐富，業務需求量逐步增加。如何提升開發效率，節省人力已成爲我們面臨的真實問題。我們思考如何藉助原生端已支持的跨端平臺引擎，來統一移動端業務邏輯開發，消除兩端邏輯差異，保證業務邏輯代碼兩端只寫一次，完成需求開發的提效，縮短問題排查時間。

現狀：

例如消息平臺的端內 Push 數據處理邏輯，站內信歷史數據篩選邏輯，支付平臺的支付方式的複雜判斷邏輯，還有用戶平臺的登錄流程，一鍵登錄等處理兩端邏輯大部分都是重複的，以及業務側新需求，很多都是相同邏輯兩端分別開發或同時修改原有業務邏輯，兩端技術棧上的實現需要 2 倍的人力成本，兩套實現邏輯對應的出錯概率也會相應增加。

_上述的數據處理邏輯，篩選邏輯以及判斷邏輯等業務邏輯爲交互上的狀態更新，邏輯流轉等。數據聚合等還是儘量由服務端或者 BFF 層來處理。_BFF 在 B 端的實踐就是主要處理不同域之間的數據聚合，保證給到的 model 是面向 UI 的。

總結：

  1. 相同業務場景，業務邏輯兩端分別實現。邏輯開發對應人力 *2；

  2. 方案設計環節可能缺失。由於信息不對稱等因素，不合理的設計可能導致健壯性，擴展性，複用性等打折扣；

  3. 兩端的業務邏輯細節實現方式不一致；

  4. 不規範的代碼設計導致業務邏輯跟頁面強耦合。

Lumos 混合棧提效方案：

結合目前團隊內的跨端語言使用情況以及 CI 等基礎建設，我們使用 Dart 來完成業務邏輯的跨平臺建設。通過混合棧框架實現：

  1. 相同的業務場景，業務邏輯兩端只實現一份。邏輯開發對應人力 *1；

  2. 統一業務邏輯開發的前提是 合理一致的方案設計，反向保證方案設計環節；

  3. 統一兩端業務邏輯細節的實現方式，爲後續問題排查提升效率；

  4. 實現業務邏輯剝離，減少頁面與邏輯的耦合。

(Lumos 原爲《哈利波特》中的照明咒—熒光閃爍，寓意更開闊明朗的未來)

二. 方案設計

  1. 架構圖 - 業務視角：

  1. 時序圖：

Native 調用 Flutter 流程

Flutter 調用 Native 流程 (複用已有原生能力)

  1. 性能監控和異常捕獲：

監控指標：

  1. 方法調用效率：針對 API 入口做調用效率的監控，抽樣上傳。根據實際性能數據完成分析對比；

  2. 數據傳遞，回傳效率 ：針對不同數據量級做分層評估模型（參考維度：數據層級深度，數據屬性個數，數據長度 3 個維度加權計算）統計數據傳遞，回傳時間；

  3. 內存，CPU 佔用：複用 FlutterAPM 能力，監控線上 Lumos 引起的內存，CPU 佔用變化情況；

  4. 異常捕獲：複用 FlutterAPM 能力，完成異常捕獲和上報，確保及時響應和排查問題。

  5. 通信協議：

協議規定：

action moduleName methodName                        (Lumos定義）
 __|__   __|__   ____|____ 
/     \ /    \  /         \                              
 action:/login/getUserName/

參數描述：

Fo5iMW

三. 實踐

針對業務邏輯迭代頻繁的模塊，例如用戶平臺，支付平臺，使用 Lumos 邏輯邏輯跨平臺容器可以大大提升迭代速度，配合容器配置化平臺方案，可以將業務驗證成本最小化。實現業務穩定的前提下，快速迭代試錯。

  1. 業務場景技術架構：

  1. 混合棧實現一次業務邏輯開發

場景一：基於目前訂單中心的業務迭代頻率與迭代內容以及業務風險把控，我們首選這裏做 AB 接入。訂單中心頁面數據由配置中心下發，不同類型的訂單對應不同 type。這裏就涉及數據下發，數據匹配和數據篩選。整套數據處理由於兩端統一的 type 類型約定，所以邏輯上是一致的。這裏在統一定義好數據返回格式後，在 Dart 側完成一次業務邏輯開發即可。

簡化流程圖：

場景二：支付組件涉及頁面較簡單 - 支付收銀臺，待支付收銀臺，但是對於不同星級用戶以及不同場景環境，支付選項是多種多樣的。

目前的痛點是：支付平臺業務需求迭代頻繁，90% 以上的迭代內容爲支付流程優化，邏輯修改或新增類型。配置化程度低，且 iOS,Android 兩端修改，耗時耗力。

在對高可用高穩定追求更高的支付業務，結合支付後續業務規劃，Lumos 可以用來承載抽象出的業務規則和業務邏輯。配合配置平臺，支付平臺的需求迭代可以又穩又快的轉起來。

  1. 提效數據統計：
  1. 案例一：[交易平臺][訂單中心改造]

開發資源：iOS,Android 每端各需 3 人日，共計 6 人日

開發比例：全部爲邏輯開發

使用 Lumos 節省：3 人日

  1. 案例二：[消息平臺][IM 消息推送]

開發資源：iOS,Android 每端各需 8 人日，共計 16 人日

開發比例：邏輯開發量: UI 開發量爲 1：3

使用 Lumos 節省：6 人日

例如一個 iOS,Android 每端各需 6 人日，共計 12 人日的業務需求：

SNIowh

如果將聯調，測試，埋點，驗證環節計算入內，提效數據效果會更明顯。

四. 未來與展望

未來的規劃中，Lumos 的使用場景不只侷限於業務邏輯的開發提效。業務所處領域的數據，流程，規則等是可以通過 Lumos 統一集中在一起，通過狀態集中管理來更新，監聽，並維護我們的應用。使用 Lumos 來黑盒管理業務模型，僅對業務邏輯做必要的參數輸入，而不去關心狀態的流轉，這樣可以更專注於業務邏輯的開發。

這種基於狀態模式的主要優點在於封裝了轉換規則，並枚舉可能的狀態，它將所有與某個狀態有關的行爲放到一個類中，並且可以方便地增加新的狀態，只需要改變對象狀態即可改變對象的行爲。 同時拋開所有展示層，這一層也可以不依賴於展示層而獨立運行。

終極模式，我們希望藉助 Lumos 託管業務模型層，負責統一方案設計後的領域數據流轉和業務流程，業務規則的整合，使 App 層次更清晰合理，保證迭代速度和質量的大前提下，靈活有序的對接各個平臺。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/u6uYoFJLKmjdHoeSgr5cBg

猜你喜歡