作者 | 技神
來源 | 阿裡技術公衆号
移動端發展至今，誕生了很多架構用于解決各領域的專有問題。比如針對移動端動态化的Hybrid方案；兼顧動态化和性能的RN、WEEX乃至界面搭建方案；針對熱修複的各種Patch方案；還有一些配置、編排等特殊需求的方案。這些方案的核心都是用某種語言描述業務的邏輯方法，描述能力越強大，能夠解決的問題越多。腳本語言似乎有着無限的可能性，但是當我們嘗試解決某個未知領域的計算問題，對于問題計算的可行性又缺少自信。此外，正确評估各種架構的計算性極限對于我們選型、解決具體問題也是十分重要的。是以需要總結如何設計、評估端計算架構的一般性方法。
一 從解決埋點熱修問題了解何為端計算
因衆所周知的原因，蘋果禁止類似JSPatch的熱修複方案上線。對于考拉iOS用戶端，大多數問題需要發版解決。通過發版解決資料問題，周期長且持續産生髒資料。對于依賴資料驅動産品疊代的開發方式會産生很大影響。同時，我也在思索是否有一種更靈活的移動端取數方案，縮短資料試驗周期。基于以上目的，埋點熱修方案的研發就提上了日程。
雖然我們可以使用JS腳本作為計算載體，但是需要證明埋點熱修是否可通過計算修複。
如上圖所示，埋點修複其實就是将一個錯誤的字典計算為一個正确字典的過程。如果滿足下面兩個條件，則可以修正任何錯誤的埋點資料：
- 能夠無二義性的識别錯誤資料。
- 完備的資料，可以計算出正确的資料。
要滿足第一個條件，可以根據字典本身的資料特征、互動特征、目前頁面等上下文資料來識别。埋點資料源自服務端傳回資料、前端位置及互動和頁面上下文。要滿足第二個條件，隻需要補充上述資料即可。是以接入的資料源是否完備，是決定架構修複能力上限的一個重要的因素。
上面解決了埋點錯埋和多埋的問題，但是不能解決埋點漏埋的問題。解決埋點漏埋需要在互動的合适時機，計算好埋點字典傳輸給SDK。計算的問題上面已經解決。那麼隻要滿足在合适的時機計算，就可以解決埋點漏埋的問題。
綜上所訴，如果要修複埋點問題，則需要滿足下面三個條件：
- 需要在合适的時機進行計算。
其實對于錯埋和多埋的修複場景，就是在上報SDK前這一時機進行計算。
至此，一個解決埋點熱修問題的計算架構原理基本完成。架構主要圍繞三件事情展開：
- 一，向JSContext補充API提供基礎計算能力。
- 二，補充資料源為計算提供物料。
- 三，補充觸發計算的時機。
計算、資料、時機是一個計算架構能力最重要的三個因素。為了進一步說明，下面給出一個修複加購埋點漏埋問題的案例。
随着提供的API、資料以及時機能力增強，該架構可以解決一些線上功能性問題修複。比如：
- 修複視訊多段拍攝存在問題：在進入剪輯編輯器前修改傳入的音軌資訊，禁用多段拍攝功能，并調整頁面相關控件的顯示狀态。
- 修複搜尋特定關鍵詞，導緻富文本渲染出現崩潰：修改下發資料字段，回避崩潰問題。
- 修複因缺少參數，導緻品牌非自營商品搜尋請求失敗：修改接口的請求體，補充必要資料。
- 修複SKU切換時某區域資料未重新整理問題：在SKU切換後，重置該區域的View的顯示狀态。
此外，還進行過一些資料實驗。比如分析5秒内使用者退出APP的原因，UT通道資料丢失名額建立等。
對計算、資料、時機三個次元的補充，架構已經從埋點修複，泛化為一般的端計算架構。通過控制資料，去影響APP的功能。從端計算的角度看JSPatch等熱修架構，它的計算、資料層面限制較少，但是修複時機是函數調用級别。相比代碼行級别的修複，架構對修複方案有一定的限制。
二 從端計算角度改善DinamicX架構
DinamicX的搭建能力非常強，一般情況下，模闆主要從單一資料源取數計算。資料源通常由網絡請求下發。
如果期望做一些接口膠水層聚合，或者定制用戶端ViewModel的邏輯，可以接入FAAS層對DX的資料源進行重計算。
但是FAAS隻能利用服務端側資料進行計算，從端計算角度看，無法天然使用用戶端側資料進行計算。這樣并不适應需要服務端側和用戶端側資料共同計算的需求。比如有些展示坑位有紅點提示，需要點選後讓紅點消失，或者消失後隔一段時間再次展示。這個需求用戶端側相對好實作一些，坑位點選後本地打标，也不需要消耗服務端資源。服務端也有一些方案，比如點選後發起請求由服務端打标，然後FAAS層根據标記計算資料源展示。或者用戶端打标，在請求時回傳标記給服務端，然後由FAAS層計算資料源展示。兩種服務端方案，本質上類似，都是想辦法讓服務端側擷取這個标記資料。
不想消耗服務端資源，又想從DX層面實作這個需求，如果看了之前埋點熱修的架構方案，很自然的得出下面的解法。
這個方案是可以解決上面的問題，但也有一些設計上的問題。比如純動态化發版解決有些麻煩，邏輯分散，用戶端會有額外的記憶體、IO操作。回到問題本身，其實我們是期望在DX引擎渲染計算時能夠利用服務端側和用戶端側資料。我通過對DX架構的學習，發現一種更優雅解決該問題的方案。
雖然DX渲染接口上隻能使用單一資料源，但是DX提供了DataParser自定義計算表達式機制。我們可以定制一個DataParser，在模闆渲染中使用用戶端側資料。這樣DX模闆其實可以支援多種資料源進行計算。同時DX提供了一個使用者上下文，用于參與DataParser和EventHandler的計算。我們可以設計一個DataParser，擷取使用者上下文中的鍵值對資料；此外可以設計一個EventHandler用于将鍵值對資料設定到使用者上下文中。使用者上下文提供多種生命周期的存儲方法，實作頁面内DX元件間資料互通，頁面間DX元件間資料互通，以及持久化能力。從時機角度看，其實DX可以在事件觸發時，執行多個EventHandler。這樣可以通過組合執行EventHandler代替類似萬能函數的EventHandler實作。使計算更具有靈活性。最終改造後的方案如下。
新方案通過計算和資料兩個角度進行了優化。方案不額外占用服務端資源，在DX模闆中實作了全部邏輯，同時支援動态釋出能力。比較優異的解決了該需求。
三 端計算優勢以及未來發展
計算上雲目前是趨勢。極端的角度看，期望用戶端越做越輕，将主要的計算能力放到雲上解決。我之前做過類似雲遊戲的方案，3D遊戲這種極端依賴用戶端硬體能力的應用也可以上雲。随着通訊技術的進一步發展，遊戲上雲、APP上雲将來會有商業化産品出現。雖然趨勢如此，但是端上依然有兩大優勢，是雲計算無法替代的：一是算力經濟性，二是資料完備性。
從算力經濟性角度看，端裝置硬體的算力逐漸攀升。一般使用場景，算力其實是過剩的。同時頻繁、大資料量的通訊，無論對使用者還是營運組織，都是存在成本的。雲計算與端計算未來會因經濟性和體驗，在适用場景上達到一個平衡。這是整體計算經濟性最優導緻的結果。
從資料完備性角度看，端上采集永遠是第一手資料，無論次元還是資料量都較大。這些資料傳輸，以及在雲上還原使用者上下文場景都需要巨大的算力。雲端獲得資料前，需要端上處理、清洗資料。雲端資料始終存在人為的資訊丢失、修改情況。可計算性依賴資料完備性，另外出于對響應、算力的考慮，有些計算場景下放到端上計算更合适。特别是一些需要大量、複雜使用者上下文資料參與的場景。此外，未來隐私合規更新，資料傳輸到雲上會更為謹慎。為了保證一些服務的可持續運作，需要提供端計算的适配方案。
服務端和用戶端都滿足資料完備性的情況下，如果用戶端再提供計算動态性支援，其實選用哪個方案沒有本質性差別。例如FAAS服務可以使用雲計算實作，也可以使用端計算實作。剩下的是性能、體驗、成本以及穩定性等其他方面綜合性考慮。