Changes and invariance in the wave of cross-end development

1990 年代初頭の PC 時代以来、モバイルネットワークの急速な普及に伴い、2010 年前後のモバイル時代や IoT 時代にはさまざまなモバイルインターネットデバイスが登場した。
最も一般的な PC、タブレット、スマートフォンに加え、小型のスマートウォッチや大型画面端末も含まれる。
スマートデバイスは絶え間なく登場し、人々の生活の隅々にまで浸透しており、デバイスのシステム種別や画面サイズの断片化がますます進んでいる。


データによると、現在のユーザーは平均 5 台のスマートデバイスを所有している。
2022 年末までに、中国の IoT 接続デバイス数は 100 億台を超えると推定されている。
スマートデバイスの急増に伴い、スマートホームやスマートオフィスなどのデバイス間接続への需要が高まっており、クロスエンド開発への需要も急増することを意味している。


従来のハードウェア開発は種別ごとに独立していた。
携帯電話は携帯電話、コンピュータはコンピュータという具合である。
同じハードウェア種別でも OS が異なれば、開発もまた独立していた。
iOS は iOS、Android は Android である。
この背景には大量の重複作業があり、一度の開発で全シナリオのニーズを満たすクロスエンド開発は必然的な流れとなっている。
このため、さまざまなクロスエンドソリューションの探求が絶え間なく行われてきた。


クロスエンド技術の変化するものと不変なもの

クロスエンド技術の進化を振り返ると、Web コンテナから汎用 Web コンテナ、そしてセルフレンダリングへと、技術ソリューションは急速に変化してきた。
あるソリューションから別のソリューションへの移行コストは再開発に相当する。
クロスエンド技術ソリューションがどのように変化しても、ビジネスコードを不変に保つにはどうすればよいか。
この問題を解決するために、まずクロスエンド技術の進化を再確認する必要がある。


クロスエンド技術の進化

1. Web コンテナ方案：

ブラウザと WebView は W3C 仕様に準拠した標準 Web コンテナであり、Web ページはどのブラウザや WebView にも簡単に組み込むことができる。
開発コスト、統一された標準、エコシステムの充実という点で、Web ソリューションは基本的に最適な選択肢である。
しかし、Web 自体にページの読み込み遅延、メモリ消費の大きさ、インタラクション体験の乏しさといった問題がある。
Web をベースに Hybrid、PWA、PHA などの Web 機能拡張方案が派生し、パフォーマンスと体験を大幅に改善したが、ネイティブレベルのパフォーマンスと体験には依然として劣るという欠点が残っている。


Web の効率性と動的性はネイティブ開発では実現が難しい。
ネイティブのパフォーマンスと体験は Web が常に追求してきた目標でもある。
両者のバランスを取る方法はあるだろうか。
React Native の登場は、開発者に新しい考え方をもたらした。


2. コンテナ型ネイティブ方案：RN / Weex

Web コンテナ方案のパフォーマンスと体験の不足を補いつつ、Web の開発効率も維持するために、RN 系コンテナは JS エンジンを可能な限り保持し、フロントエンドエコシステムとの親和性を最大化して開発効率を向上させている。
パフォーマンスと体験については、レンダリングでネイティブのレンダリングパイプラインを再利用し、ネイティブレンダリングによってパフォーマンスと体験を確保している。
クロスエンド対応は類似のコンテナソリューションで実現でき、主流の RN や Weex がこの方式を採用している。


コンテナ型ネイティブ方案は、ネイティブ体験と Web の充実したエコシステムの両立を実現したように見える。
しかし、埋めがたい一貫性の問題、W3C 標準のサポート不足、開発体験の課題、周辺エコシステムの不備といった問題が残っている。
それでもコンテナ型ネイティブ方案は成功を収め、フロントエンドの領域を急速に拡大させた。


3. セルフレンダリング方案：Flutter

Web コンテナにはパフォーマンス問題があり、ネイティブコンテナには一貫性の問題がある。
そこで、ネイティブレンダリングパイプラインを迂回し、独自のレンダリングエンジンを構築してクロスエンドの一貫性問題を解決できないだろうか。
その答えは必然的に導き出された。
Flutter は Skia ベースの独自描画エンジンを実装し、高い一貫性と良好なパフォーマンスを実現したが、独自の欠点もある。


設計上の新しい考え方として、JS を廃止して Dart を開発言語として採用したため、ネイティブ開発者とフロントエンド開発者の両方にとって学習コストが生じている。
ただし、開発者の視点から見れば、学習コストはそれほど高くない。
より大きな問題は、プロジェクト関連の CI/CD やエコシステム関連の投資と知見をすべて再構築する必要があり、莫大なコストがかかることである。


このため、多くのフロントエンド開発者が導入を躊躇している。
そして自然にさまざまな探求が行われている。
上層では Flutter とフロントエンドエコシステムの接続をより良くし、下層では Flutter の独自描画レンダリングを活用してマルチターミナルのレンダリング一貫性を確保するアプローチである。
ここでの詳細は割愛する。


4. ミニプログラムの「一コード複数展開」クロスエンドアプリ方案：

ミニプログラムはヘッドアプリがトラフィックの閉ループを構築し、コンテナを管理・制御する仕組みである。
同時に、デュアルスレッドモデルと独自 DSL の導入は新たなクロスエンド問題をもたらした。
主要メーカーが独自にミニプログラムコンテナとクイックアプリを実装したことで、クロスエンドコンテナの断片化がさらに深刻化している。


実装方案は大別すると、コンパイル時とランタイムの 2 つに分類できる。


・コンパイル時アプローチ：コンパイル時にフレームワークのビジネスコードをミニプログラムのネイティブ DSL に変換する。


・ランタイムアプローチ：ミニプログラムの setData とランタイムフレームワークを接続してクロスエンドを実現する。


こうしたフレームワークは数多く存在する。
実際、ミニプログラムの一コード複数投入はビジネスモデルの制約下での技術的妥協の産物と言える。


進化における変化するものと不変なもの

上記のクロスエンド技術の進化の紹介から、クロスエンド技術ソリューションがどのように変化しても、クロスエンドの目標は不変であることがわかる。
パフォーマンス体験、配信効率、マルチターミナル一貫性の追求は常に維持されており、ソリューションの本質はこれらのバランスと選択の方法に帰着する。


クロスエンド技術ソリューションは常に変化し続けている。
ソリューションに基づく端末機能要件、コンテナ、ブリッジなども変化し、ビジネス開発フレームワークやインフラも変化していく。
この変化の中で不変の存在を見つけ出し、変数を制御することで混沌を秩序化し、クロスエンド技術の進化を追跡可能にできるだろうか。
各ソリューションの反復で必然的に変化する「コンテナ」を唯一の変数として扱い、ビジネスコード、インフラ、開発エコシステム、基盤機能を不変に保てるだろうか。


・新しいコンテナになっても、ビジネスコードは変更なしに新コンテナ上で安定して動作するか。


・新しいコンテナになっても、周辺のサポート施設と開発エコシステムを継続して利用できるか。


・新しいコンテナになっても、端末機能要件は変わらないか。


上記の変化と不変のものに基づき、「クロスエンドコンテナ仕様の統一とコンテナ標準化の実現」は確かに正しい方向性である。
この標準に従って実装されたコンテナは自由に切り替え可能で、上位のビジネス、フレームワーク、インフラに影響を与えず、クロスエンドで「一度記述すれば、どこでも実行できる」を容易に実現できる。


コンテナをどのように標準化するか

標準化の方法

Web の視点から考えると、答えは見つかりやすい。
ブラウザはどのように標準化しているだろうか。


まずブラウザアーキテクチャを見てみよう。
Web はブラウザコアによってレンダリングされ、HTML、CSS、JS を実行して開発者が期待する UI を描画する。
カーネルは主にブラウザエンジンと JS エンジンで構成される。
JS エンジンは TC39 (ECMAScript) 標準に従って JS を実行し、ブラウザエンジンは DOM や CSS など JS 以外の処理を担当し、W3C 標準に準拠している。
2 つのエンジンは相対的に独立しつつも強力に連携しており、異なるブラウザでの実装もそれぞれ異なる。


このアーキテクチャの中核部分が WebCore であり、ローディングとレンダリングの基礎能力である。
この部分は全ブラウザで共有される。
その他の部分（図のグレー部分）は同じ標準に従うが、実装は異なる。
プラットフォームの違い、サードパーティ依存の違い、ニーズの違いなどにより、各ブラウザが独自の方法で設計・実装することが許容されている。


ブラウザの考え方を参考にすれば、クロスエンドコンテナでも同様のことができる。
同一標準に基づくクロスエンドコンテナの実装は、開発工数を大幅に削減でき、W3C 標準への準拠によりフロントエンドエコシステムへの接続も容易になる。
Alibaba でも実際にそうしている。


Alibaba の標準化実践では、グループ内のクロスエンドコンテナに関わる複数の事業部を集め、W3C / WHATWG の標準とビジネスニーズを参照しながら、CSS / WebAPI / ブリッジチャネルの 4 つの側面から標準サブセットを策定した。


なぜ完全実装ではなくサブセットを選択したのか。
主にパフォーマンスと効率のバランスを考慮した結果である。
標準化された開発効率と開発体験を実現するのが無疑最適だが、クロスエンドコンテナでは丸みや影などさまざまな問題が発生する。
類似のケースは多い。根本的に Web とネイティブの設計思想は全く異なり、強制適合は深刻なパフォーマンス低下を招く。さらに、ブラウザは長年の開発歴史があり、関連仕様は膨大で歴史的負荷も大きい。モバイルや IoT でのパフォーマンス対応は依然として非常に挑戦的な課題である。

では、HTML、CSS、Web API の標準サブセットを策定すればフロントエンドエコシステムと接続できるだろうか。それだけでは不十分だと考える。現状では、異なるクロスエンドコンテナ間で標準が大幅に異なり、クロスエンド開発エコシステムの不一致を招いている。多くの場合、独自開発が必要になる。既存のフロントエンドやクロスエンドエコシステムの多くを直接使用できない。たとえば、一般的なデバッグ機能では、各コンテナが異なるインスペクタを実装しているため、既存の Devtools を直接使用できず、ほとんどが独自の Devtools を開発している。Weex Devtools と AJX Devtools はリモートデバッグプロトコルに基づいて通信するが、実装は独立している。もう一つの例として、List コンポーネントがある。ほぼすべてのクロスエンドコンテナがリストレンダリングの問題を解決するために List コンポーネントを必要とするが、いずれも独自実装のカスタム List コンポーネントである。これらに多くのリソースを費やしてきた。コア機能で WebCore の能力を共有できれば、より優れたクロスエンドカーネルを構築し、ビジネス領域の最適化に集中し、より優れたビジネスに適したコンテナを構築できる。

今年の D2 クロスエンド技術特別セッションでは、この分野の技術専門家を招き、クロスエンド技術の現状と未来について議論し、新しいインスピレーションと、将来の開発に適した考え方や実践経験をもたらすことを期待している。また、2022 年の D2 ターミナル技術カンファレンスでは、Node.js、Swift、フロントエンドエンジニアリング、Flutter、JS エンジン、ネットワーク、AR/VR/3D、クラウドレンダリングなど、フロントエンドとモバイルの多岐にわたるトピックも用意されている。詳細を知りたい方や交流を希望する方は、D2 から申し込まれたい。D2 で皆様にお会いできることを楽しみにしている。