メインコンテンツへ移動
黯羽軽揚毎日少しずつ

クロスプラットフォーム方案の三大困境

無料2020-08-09#Mind#移动跨端#Flutter的局限性#Flutter的缺点#跨端开发缺点#跨端方案的局限性

ある時、Write Once, Run Everywhere は単なる美好な願望に過ぎません

はじめに

2018 年、Airbnb は React Native の継続使用を放棄しました。その主な理由は 2 方面にあります：

  • 技術：成熟度、配套施設/ライブラリ建設コスト、初屏パフォーマンスの硬傷などが很好地に解決されなかった

  • チーム組織：エンジニア要求が高く、クロス技術スタック/クロスチームデバッグ/テストなども新しい問題を生んだ

実際、クロスプラットフォーム方案が遭遇する問題はこれらだけでなく、ある時 Write Once, Run Everywhere は単なる美好な願望に過ぎません

一.技術困境

一言で言えば、能力境界に触れる前に、クロスプラットフォーム方案の中のすべては美好的です

React Native を例にすると：

Bridge 層はメッセージ通信を通じて JavaScript 世界と Native 世界を联系します

Shadow Tree は UI 効果及びインタラクション機能を定義するために使用され、Native Modules は Native 機能（例えば Bluetooth）を提供し、二者間は JSON メッセージを通じて相互通信します

P.S.図はやや古いですが、原理の理解には影響しません。更新された React Native 架構図は React Native 架構進化 を参照

このような技術架構では、書くのも実際に実行されるのも JavaScript で、Native が提供するビューレンダリング能力及びプラットフォーム特定能力を呼び出します。Facebook はこれを Scripting native 方案 と呼び、とりあえずコンテナ化 Native クロスプラットフォーム方案と呼びます：

Native App を標準化されたコンテナに改造し、それによって一套のコードがクロス多端標準コンテナで実行することを許可します。例えば React Native/Weex、Flutter

（モバイル端末クロスプラットフォーム技術の下の変と不変 より引用）

コンテナ能力は很大程度上で開発効率を決定します。コンテナが一貫した標準サポート範囲を提供した場合、一人で多端を搞定できます。しかし、一旦能力境界に触れると、高コストの多層連合開発（Native 層、JavaScript エンジン層、特定業務領域層、業務層……）に直面し、人効上では優勢がありません。他方で、如何に多端一貫性を保持するかは、極めて複雑で技術的挑戦に満ちた問題です

さらに、関連する配套能力も直接開発効率に関係します：

  • デバッグ：クロス技術スタックデバッグは常に難題で、問題排查コストは越来越高

  • パフォーマンス：クロススレッド、クロスページ耗时分析が困難で、パフォーマンスツールチェーンが缺失

  • エンジニアリングリンク：技術方案の特殊性により、多くの配套施設（IDE、デバッグ、パフォーマンス、CI/CD、監視などを含むがこれに限定されない）を量身定制する必要があり、各环节のコストを下げることができます

総じて言えば、技術上の最大の困境は：

  • 埋められない多端差異

  • 掀けない JavaScript エンジン蓋

  • 追い付かない配套能力

多端一貫性は技術投入上でほぼ底なし沼で、底層のプラットフォーム架構差異（UI レンダリング方式、イベント機制、システム API）は根深く、各類クロスプラットフォーム方案の現在の成熟度では極めて限られた一部分のみをカバーでき、非常に大きな空白が残っており、コンテナ能力を拡張して埋める必要があります。通用的な基礎能力（UI、インタラクションなど）及び業務領域面向の特定能力（マルチメディア、位置情報など）を含みます

JavaScript エンジンを導入することで動的にコードを実行する能力を獲得しましたが、技術上の不確実性ももたらし、JavaScript エンジン内部の崩壊または異常行為を追跡解決することはほぼ不可能です

通用的な基礎設施の大多は直接クロスプラットフォームシナリオに使用できず、辺边角角の配套能力はすべて力をかけて建設する必要があり、業務の快速生長を満たすために、常に核心关键能力を優先的に建設し、配套サポートは通常滞後しており、同様に効率に影響します

Flutter は何か違いをもたらせますか？

事実、Flutter（現在看起来）も同様にこれらの技術困境に直面しており、技術実現の変化は局面を徹底して変えませんでした

2020 Q1 調査結果によると、Flutter 開発者が最も重要だと考える 6 つの問題は：

  • デバッグエラーと崩壊

  • App がクロス多プラットフォームで実行できることをテスト確保

  • 状態管理方案の選用

  • レイアウト問題（テキスト溢出など）の理解と処理

  • 設計稿に基づいて UI を作成

  • 特定プラットフォーム問題の排查

同時に、最も困難だと考える 6 つの問題は：

  • 特定プラットフォーム問題の排查

  • メモリ問題の診断と修復

  • CPU 使用率問題の診断と修復

  • 既存の Native API への接入

  • UI カクつき��題の診断と修復

  • 特定プラットフォームの Flutter プラグインの開発

したがって、クロスプラットフォーム方案のデバッグ、パフォーマンスの痛みは依然として Flutter で継続し、多端差異及び配套能力の困境は変わっていません

二.チーム組織困境

単端開発モードと比較して、クロスプラットフォーム方案の協業コストはより高く、以下に体現されます：

  • クロステーム

  • リンクが長い

  • コンテナチームの圧力が大きい

  • 職責境界が清晰でない

クロスプラットフォーム方案の下、クロスチーム協業が最も主要な協業方式となり、ニーズ串講、開発、連調、問題排查などの複数の環節都需要クロスチームコミュニケーション/協業で、コミュニケーションコストは無視できません

長いリンクは技術詳細が多層に散らばり、各自が一小部分の知識のみを所有することを意味します：

表層業務ロジック
-----------------------------
特定業務領域フレームワーク
-----------------------------
通用フロントエンドフレームワーク/ライブラリ
-----------------------------
JavaScript エンジン（拡張）
-----------------------------
Native Module | 特定業務領域能力
-----------------------------
Native 通用フレームワーク
-----------------------------
Native View
-----------------------------
プラットフォームオペレーティングシステム

各チームが全景を見ることができないため、每一个原因がそれほど明らかでない問題はすべて一層層下に排查する必要があり、甚至特定業務領域能力に関わる部分はまた多くの層に分かれます……

他方で、これほど繁多な層も複雑さの堆積を引き起こし、下層に行けば行くほど複雑さは高くなります。不確実な可変入力が多いほど、来龍去脈を弄明白するのが難しく、問題排查のコストも高くなります

理想的な場合、漏斗モデルに従って逐層フィルタリングし、每一層は自分の入力出力のみをチェックすればよいですが、滞後した配套能力により表層業務が問題所在の範囲を識別することが難しく、于是コンテナチームが問題流转のフィルタ阀となり、上は紛繁な JavaScript 業務を受け、下は複雑な特定領域能力に连接します。大量の時間が来龍去脈を弄明白することに費やされ、コンテナ能力拡張は被迫降速し、既知問題を反復排查します……

業務視点の下、業務の下の層の職責划分はそれほど清晰ではありません。そのため很容易に層/人を間違え、無効な「リダイレクト」を生じます。コンテナ層も同様に全景ビューを具備しておらず、問題流转軌跡は非常に曲折になり、コミュニケーションコストは各环节に充斥し、開発効率を制約します

三.個人困境

個人にとって、直面する最大の困難はクロスプラットフォーム方案と Web 標準に些许の差異が存在することで、これらの些许の差異は W3C 標準のように清清楚楚に書けるものではありません：

Weex enables developers to use modern web development skills to build Android, iOS, and Web apps with a single codebase.

つまり、通用の Web 経験は完全に適用されず、学習曲線はそれほど友好的ではありません。例えば：

  • rem、メディアクエリ、scale/zoom などの适配経験は必ずしも適用されません

  • DOM 操作を減らす、JavaScript ファイルを合併する、ハードウェアアクセラレーションを开启するなどの常規最適化措置も必ずしも明確なパフォーマンス最適化効果を生むとは限りません

  • （Web を学習するように）ブラウザ之上の標準能力のみを理解するだけでは不十分で、真に高效的に業務開発仕事を完成したいなら、コンテナ原理甚至部分実装詳細も理解する必要があります

Native 背景を持つ開発者が [TypeScript](/articles/typescript 简介-typescript 笔记 1/) を学習するのと同じで、初接触は無師自通で、馴染みの [Class](/articles/类-typescript 笔记 4/)、Interface、[静的タイプ](/articles/基本类型-typescript 笔记 2/) は游刃有余に使えます……しかし、TypeScript を熟知する開発者は必ず個中の詳細に多少の奇怪な場所が存在することを知っています

四.クロスプラットフォームの真の意義とは何か？

React Native の最初の出发点は：

Native 開発も Web のように Move fast できることを希望

  • 快速イテレーション（Rapid iteration cycle）：Web は一日二版、製品イテレーション周期がより短い
  • 快速フィードバック（Immediate testing feedback）：Web 发布は直ちにユーザーに届き、A/B test などの実験結果は立等可取で、製品進化がより速い
  • 快速開発（Rapid development velocity）：ブラウザをリフレッシュすれば生效し、App を再コンパイルするのを待つ必要がない

（React Native 簡史 より引用）

したがって、ニーズの角度から見ると、開発効率は次要的で、動態化の柔軟性、快速イテレーションが業務を先に赢むことがそのクロスプラットフォームの主要な意義です。或者说生産効率を追求しており、開発効率だけでなく、より短いイテレーション周期、より快速なユーザーへの届きは直接の生産効率進歩です

しかし、三大困境の下、開発効率は実際には生産効率にも严重影响していますが、快速イテレーション、動態发布の重大な進歩を抵消するにはまだ足りず、此消彼長も一種のバランス、一種の受容可能な妥協と言えます

五.困境の中で生門を探す

理想的な場合、コンテナは標準化に趨るべきで、多端一貫、豊富で安定した能力サポートを提供するべきです。上の業務スタックは極めて少なくコンテナ能力境界に触れ、それによってコンテナ層が不断优化探索し、更好地に業務発展の需要を満たすことができます

他方で、クロスプラットフォーム方案は多端不一致性がもたらす複雑さをコンテナ層に下沉させたのみで、プラットフォームから独立した言語環境（JavaScript エンジン、Dart 仮想マシンなど）は上層業務ロジックの一貫性を保証できますが、コンテナ層は依然として多端で各自一套を実装する必要があり、如何にコンテナ能力の多端一貫性を保証するかは依然として大きな問題で、非クロスプラットフォーム方案の下よりも容易なわけではありません

したがって、首先要解決コンテナ能力豊富度の問題で、境界を拓宽し、根源から問題を減らします。转而集中火力を真の難題に向け、最も価値のある难点部分を攻め落とします。同時に仮想架構などの方式を通じて全職能的な業務サポートチームを建立し、コミュニケーションコストを低減します：

  • 業務は自研能力を持つ必要がある：下層資源ボトルネックを化解し、共同でコンテナ能���を豊富にする

  • 必須に大力を投入する点に专注：デバッグ能力、標準化、パフォーマンス分析及び継続跟踪、エンジニアリング配套施設

  • 全職能的な業務サポートチームを持つ必要がある：すべての問題を抱え込む能力があり、真に一揽子解決方案を提供し、無意味なコミュニケーションリダイレクトを消除する

その中で、業務自研能力はまず標準的な拡張方式が必要で、コンテナ実装上に拡張しやすく、業務開発者は過多の詳細を了解しなくても快速に開発に入れます。デバッグ能力は長いリンクの技術スタックの下で極めて重要で、問題識別コストが越低く、准确率が越高く、効率が越高く、释放できる資源も越多くなります

業務開発の角度から見ると、より必要なのは一層のゲートウェイで、リクエストが過去にレスポンスが戻ってくることで、一連のルート表ではなく、一跳一跳に跟踪する必要があります。全職能的な業務サポートチームは局域網を組成し、ゲートウェイ之后的トラフィックが快速に流转することを可能にし、高效的に協業する同時に業務開発の幸福感を向上させます

参考資料

コメント

コメントはまだありません

コメントを書く