移動端動態化的由來，你知道嗎？

目前的移動開發者面臨的最大痛點就是面對極其複雜的環境，對此，莊卓然給出一個公式，移動開發的複雜度=應用數量×平臺數量×要適配的各種各樣的機型。

如何解決這個問題呢？在解決問題之前，首先要對移動開發的未來有著精準的研判。

阿里認為，移動開發的未來必定更加平衡，也就是說必須是效能與動態兼得，如此，才能夠滿足未來使用者的需求。另外，移動開發在未來也必定是開放互聯的狀態，移動網際網路將來肯定是基於更加大眾化的技術體系，沒有平臺之間的隔閡，而且簡單易用。

移動端動態化的由來

“動態化”並不是最近幾年才產生的名詞，而是從從網際網路誕生的初期，這個詞就已經出現了。大家所認知的早期網際網路，其實就是各種各類的“動態網站”，內容資料和頁面外觀都不是固定的，都是隨著伺服器端的更新而更新的，讓使用者可以很及時地看到最新的內容。因此，動態化可以說是網際網路的標誌，是網際網路最核心的特性之一。

而移動網際網路的普及，移動端被各類原生應用所佔據，而這些應用更近似於 Software，依託於應用市場進行更新，只有其中的資料是實時的。這樣，每次產品的更新，必須依賴使用者的主動更新，從而造成了一定的使用者成本，不利於產品的快速迭代，降低應用的試錯能力。因此，移動端動態化方案逐漸走進大家的視野，並被大家所關注。

從一開始基於 WebView 的 Hybrid 方案 PhoneGap、Titanium，到現在與原生相結合的 React Native 、Weex，甚至 Flutter，都被或多或少地使用到不同的移動應用中。

原生開發能不能動態化？準確的說是能的，而且 Android 平臺各公司都有很完善的動態化方案，甚至 Google 還提供了 Android App Bundles 讓開發者們可以更好地支援動態化。而反觀 iOS，由於 Apple 官方擔憂動態化的風險，因此並不太支援動態化（去年還封殺了 JSPatch 等一類動態修復方案），因此比較通用的原生動態化方案几乎沒有，只有各大廠自己實現的一些動態化框架。

動態能力建設方向流派眾多

如何選擇動態能力建設的流派，主要從研發成本、相容性、動態能力、穩定性、操作體驗等方面判斷，需要根據團隊的實際情況來進行選擇。

簡單敘述一下動態化能力建設的主要流派：

1、React-Native

• 優點：歷史悠久、資料豐富、學習楷模
• 缺點：相容性一直被詬病，坑太多玩不動
• 典型代表：Facebook、Linkedin

2、原生+H5

• 優點：平衡性佳、研發可控能力好
• 缺點：原生部分動態能力欠缺
• 典型代表：Hybrid方式依然佔據大部分市場

3、原生+小程式（另一種Hybrid方式）

• 優點：同樣擁有平衡性和研發可控性的優點，體驗接近原生，小程式的效能是有目共睹的
• 缺點：與h5一樣原生部分動態能力欠缺
• 典型代表：依然是Hybrid方式，微信、支付寶、美團、FinClip

4、weex flutter

• 優點：效能動態能力兼顧
• 缺點：開發成本高、異構風險大、IDE體系弱
• 典型代表：阿里系

5、H5化

• 優點：節省開發資源，動態性最好
• 缺點：相容性問題多，體驗尚與原生有差距
• 典型代表：騰訊系

當然也有純原生的，所剩無幾就不討論了。

動態化流派眾多，各有利弊，沒有最好，各個團隊需要根據自己的專案選擇最合適的方式。以我們團隊為例，目前選擇了Native+小程式的結合，透過在APP中引入   FinClip小程式容器技術，讓App具備小程式執行的環境。從而實現這種基於小程式的Hybrid的方案。以下簡單介紹一下Native+小程式的模式有哪些優點：

首先基於小程式的Hybrid方案，是透過更加定製化的 JSBridge，並使用雙 WebView 雙執行緒的模式隔離了JS邏輯與UI渲染，形成了特殊的開發模式，加強了 H5 與 Native 混合程度，提高了頁面效能及開發體驗。