阿里妹導讀：什麼是端計算？如何在不額外佔用服務端資源的情況下，在客戶端解決計算需求？端計算和雲計算相比，有哪些優勢？本文從設計一個解決埋點熱修問題的通用化架構，及其演變乃至解決其他端計算問題的案例，來說明設計一個端計算架構的一般性方法。

文末福利：輕量應用服務器優惠，新用戶專享。

移動端發展至今，誕生了很多架構用於解決各領域的專有問題。比如針對移動端動態化的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服務可以使用雲計算實現，也可以使用端計算實現。剩下的是性能、體驗、成本以及穩定性等其他方面綜合性考慮。

輕量應用服務器

新用戶專享

阿里雲開發者成長計劃面向全年齡段開發者，依託免費資源、免費體驗、免費學習、免費實踐 4 大場景，全面助力開發者輕鬆掌握雲上技能。新用戶專享輕量應用服務器，內置WordPress等8種主流環境，5M峯值帶寬，40GBSSD雲盤，1000G流量包，輕鬆滿足學習、搭建應用等場景！