一.跨平台，是想跨哪些平台？
目前（2020/7/18）來看，移動端跨平台需求主要集中在：
- 跨 PC 端與移動端：PC 向無線過渡的早期，希望 PC Web 與移動 Web 複用同一套代碼
- 跨 Native 與 Web：商品詳情頁等要求有一套功能差不多的 Web 頁能夠在端外通路，需要跨 Native App 與 Web
- 跨 Native 雙端：出于開發效率等原因，希望 Android、iOS 雙端複用一套業務代碼
- 跨 App：一些産品功能期望能在多個管道投放上線，以工具類需求為主，如打車、買票、點餐
在可預見的未來，可能還會有這些跨平台需求：
- 跨輕應用：系統級即用即走的輕量級應用，如 Android 快應用 、 iOS App Clips
- 跨 IoT 裝置：各種有顯示屏的裝置都會成為新的“端”，如車載裝置、智能家居
- 跨一切用戶端：可能是僞需求，同一産品在不同平台的側重點不同，或許并不需要把所有功能完整地搬到各式各樣的用戶端裝置/平台管道上，例如快應用與 Native App 的定位顯然不一樣
在這樣的時代背景下，無論從資源成本、開發效率，還是從産品疊代、技術演進的角度來看，跨平台開發都是強需求，是以才有了層出不窮的各種跨平台方案探索
二.層出不窮的跨平台技術
細數近幾年業界主流的移動端跨平台方案，可大緻分為 3 類：
- Web 生而跨平台：隻要有浏覽器或 WebView，依托 Web 技術即可輕松跨平台，如 Web App、 PWA（Progressive Web Apps） 、Hybrid App、PHA（Progress Hybrid App）
- 容器化 Native 跨端：将 Native App 改造成标準化的容器，進而允許一套代碼跨多端标準容器運作，如 React Native/Weex、Flutter
- 小程式一碼多投跨 App：國内市場中，越來越多的超級 App 支援了小程式，但各自的小程式架構并沒有統一标準，于是有了 Taro kbone uni-app 等一系列跨小程式架構的方案來滿足跨 App 投放産品功能的需求
跨平台：Web 與生俱來
跨平台是 Web 與生俱來的優勢，浏覽器和 WebView 都是 W3C 規範下的标準化 Web 容器，是以 Web 頁面能夠輕松投放到端外浏覽器、端内 WebView、以及其它 App 提供的 WebView 中
單從成本角度來看，Web 方案是跨平台的不二之選：
- 沒有額外的學習成本：一套基礎技術吃遍端内、端外、甚至 PC 浏覽器、電視機頂盒
- 不依賴特殊的配套設施：開發、調試、建構、釋出、監控、運維等所有工程化環節都是通用的
- 坐擁龐大的既有生态：npm 百萬子產品，應有盡有
- Web 基于開放标準：走出去引進來都不是難事
并且，Web 本身就是一個平台，退可守，技術風險更低
但在另一些方面，依靠 Web 技術跨端也存在其局限性：
- 平台能力：受限于 Web 标準容器，無法滿足平台能力相關的需求，如相機、藍牙、多媒體等
- 體驗：移動端 Web 體驗遠不及 Native，主要展現在首屏加載慢、動畫卡頓、長頁滾動閃爍等場景
- 性能：記憶體消耗大、GPU 使用率低
加上 Web 标準更疊慢，新特性相容性差（如
Push API過去許多年了，仍然無法放心使用），Web 基礎能力難以滿足 Native 端的需求。是以，在傳統 Web App 的基礎上，展開了更多的探索：
- ：離線緩存、系統通知、主屏圖示等類 Native App 能力加持之下的 Web App，但相容性并不樂觀
- Hybrid App：Web 與 Native 混合的方案，将由 Native 實作的平台能力（比如掃描二維碼）注入到 WebView 環境供 Web App 使用，以擴充 Web 的平台能力
- PHA（Progressive Hybrid App） ：PWA 與 Hybrid 思想的結合，通過 Hybrid 手段讓 Web 的性能和體驗接近 Native
PWA 标準化似乎走不通，即便走通了能夠真正放心用起來可能也是數年之後了。Hybrid App 解決了一部分問題（平台能力擴充），但還不夠。PHA 是這兩種思路的延續，借助 Native 技術實作 PWA 的夢想
但無論 PHA 還是 HA，引入 Native 依賴都意味着 Web 開放性的損失，繼而帶來跨端、跨 App 方面的問題
跨端：容器化 Native
除 Web 天然跨端之外，另一種統一多端的思路是将 Native 定制成标準容器，讓同一份代碼跑在一個個标準容器中，例如：
- Android 容器：Native 殼 App
- iOS 容器：Native 殼 App
- Web 容器：Web Runtime
React Native 跨 Android、iOS、Web、Windows 四端，Weex 跨 Android、iOS、Web 三端，Flutter 以類似的方式跨 Android、iOS、Web、Linux 四端
從技術角度來看，RN 與 Weex 在 Native 容器中提供了 JavaScript 運作環境，以及布局引擎，渲染層都采用 Native 控件，是以 UI 互動上仍然存在系統差異。而 Flutter 方案更徹底一些，連渲染層也換成了基于圖形引擎自繪 UI 控件，進而保證 UI 互動的跨端一緻性
然而，由于容器化 Native 的方案是從 Native 出發，沒有跨端天賦，除了要想辦法支援 Web，還面臨一個更難解決的問題——跨 App
跨 App：小程式一碼多投
技術視角下，小程式跨 Native App 仍然是依靠 Web 方案，那麼，為什麼不直接用 Web App 呢？
由于商業競争等因素，闖入别人家地盤的 Web App 通常會遭到一些限制，如安全警告、權限控制、甚至幹脆禁止通路（是以才有了密碼分享等彎彎繞繞的方式）
小程式則不同，其初衷是開放的，歡迎大家入駐（當然，也要遵守規則），并且國内的許多大型 App 也都相繼開放了小程式能力，小程式逐漸成為跨 App 的正規方式。但小程式平台多起來之後，架構标準不統一的問題也暴露了出來，都叫小程式，但都大同小異，于是，如何快速産出多種小程式變成了一個值得探索的技術課題
實作原理上分為兩種，編譯轉換與運作時适配，前者能夠達到等同于原生小程式的性能但帶來了諸多限制（編譯期難以識别的寫法都不支援），現有的 Web App 不那麼容易遷移成跨 App 小程式，例如 Taro、uni-app 等。後者犧牲性能換取了更多的可能性，現有的 Web App 能夠相對容易地遷移過來，例如 Taro Next、kbone 等
P.S.當然，也可以有動靜結合的思路，理想情況下，絕大多數基礎業務走運作時平遷，個别高性能要求的部分走編譯轉換
三.重重變化之中，什麼才是不變量？
管道/端/平台、業務代碼、工程化配套設施似乎都在快速地發生變化，沒有哪個是穩定不變的
既然全都在變，就換個角度看，哪個部分一定會發生變化？
- 容器：新的管道/端/平台都是新的容器
- 跨容器技術：新容器的出現，意味着新的跨容器技術要求
哪個部分是不必要跟着變的？
- 業務代碼：技術方案的更疊、新管道/端/平台的出現，通常伴随着業務代碼的遷移，Native 切 React Native 切 Flutter……樂此不疲，但從成本上看，業務代碼并不一定也并不應該跟着變
- 工程化配套設施：大多與技術棧強相關，例如 Web App 的開發、調試、建構、釋出、監控、運維與 Native App 存在諸多差異，但其中更基礎的部分是技術無關，而流程相關的，例如建構-釋出流程、監控運維服務等并不需要跟着變
- 容器中的平台能力：無論何種跨容器的方案，平台能力擴充需求都是一緻的，對應的 Native 子產品封裝不應該跟着變
業務代碼遷移的成本是非常高的（涉及技術棧變化時更痛），配套設施的推倒重建也絕對是大工程，那麼，有沒有辦法把這些不應該跟着變的部分固定下來？
有，将變化的部分抽象出去。依賴抽象而不依賴具體，上層就不用跟着變了：
标準架構 \
--------- | 配套設施
标準容器 /
在這樣的抽象模型下，上層業務代碼依賴标準業務架構，而不直接依賴容器能力，進而允許業務架構以下的部分能夠替換。業務架構依賴抽象的标準容器，而不與具體的特定容器相綁定，可替換為遵循容器标準的其它容器
基于标準架構，能夠提供配套的腳手架、元件庫、可視化搭建等配套開發工具。基于标準容器，能夠建立性能診斷、事件追蹤等配套調試能力，進而覆寫到工程化的整個鍊路，配套設施也幾乎不用跟着變了
至于平台能力擴充，作為标準容器中的重要部分，也應該抽象出标準 API（類比浏覽器提供的 BOM 系 API），供上層業務使用
四.跨平台技術的未來
預見不到未來，是以這裡抛出幾個可能性：
- 移動跨端隻跨 Native 兩端：對許多移動産品而言，體驗細膩、性能優異的 Native App 仍是目前最重要的應用形态，并且雙端功能完全一緻，同等重要，是以隻跨 Android、iOS 兩端，統一移動端 Native 開發是相對合理的方案
- 小程式跨 App 自成一體：如果小程式不能真正标準化，跨 App 投放需求催生出的跨小程式架構方案就有必要存在
- Web 仍是 Web，Hybrid 仍将持續：Web 特性更疊周期太長，移動裝置的更疊太慢，等不及 Web 以年為機關的進化速度，依靠 Native 增強 Web 的 Hybrid 過渡方案很可能長期“過渡”下去
P.S.小程式已經在标準化程序中了，小程式架構成為标準化的容器也不是沒有可能，畢竟小程式架構不存在 WebView、浏覽器一樣的慢周期阻力
不看好一招吃遍天下的跨全端的方案，因為無論 universal 元件還是 universal API 都是最小交集，無法滿足實際需要。并且，真的需要讓一套代碼運作在所有管道、端、平台上嗎？
同一産品在不同平台的側重點不同，或許并不需要把所有功能完整地搬到各式各樣的用戶端裝置/平台管道上，例如快應用與 Native App 的定位顯然不一樣