モバイルクロスプラットフォーム技術の下での変化と不変

一.クロスプラットフォーム、どのプラットフォームをクロスしたいのか？

現在（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 標準コンテナに制限され、プラットフォーム能力関連のニーズを満たせない、例えばカメラ、Bluetooth、マルチメディアなど
体験：モバイル端 Web 体験は Native に遠く及ばず、主に初回画面読み込み遅い、アニメーション卡顿、長ページスクロール閃光などのシーンに体现
パフォーマンス：メモリ消費大、GPU 利用率低

さらに Web 標準の更迭は遅く、新特性の互換性は悪い（例えば Push API は過去许多年経っても、仍然として安心して使用できない）、Web 基礎能力は Native 端のニーズを満たすのが困難である。そのため、伝統的な Web App の基礎上で、より多くの探索が展開された：

PWA（Progressive Web Apps）：オフラインキャッシュ、システム通知、主画面アイコンなどの類 Native App 能力加持の下での Web App、しかし互換性は楽観的ではない
Hybrid App：Web と Native 混合の方案、Native が実装するプラットフォーム能力（例えば QR コードスキャン）を WebView 環境に注入し、Web App が使用できるようにし、Web のプラットフォーム能力を拡張
PHA（Progressive Hybrid App）：PWA と Hybrid 思想の結合、Hybrid 手段を通じて Web のパフォーマンスと体験を Native に近づける

PWA 標準化は似乎行不通で、たとえ行通じても本当に安心して使えるようになるのは数年後かもしれない。Hybrid App は一部分の問題を解決した（プラットフォーム能力拡張）が、まだ十分ではない。PHA はこれら 2 つの思路の継続で、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 の正規な方式になっている。しかし小程序プラットフォームが多くなった後、フレームワーク標準が統一されていない問題も暴露され、すべて小程序と呼ぶが、すべて大同小異で、そこで、どのように快速に多種の小程序を産出するかは探索に値する技術課題となった

実現原理上は 2 種類に分かれ、コンパイル変換とランタイム適応で、前者は原生小程序と同等のパフォーマンスを達成できるが诸多の制限をもたらす（コンパイル期に識別しにくい書き方はすべてサポートしない）、既存の 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 の位置付けは明らかに異なる

参考資料

Why Rax?