Taro アーキテクチャ分析 (1): マルチターミナルフレームワーク分析、Taro WePY ユニアプリ比較

マルチターミナルフレームワークの分類

オールインクルーシブ

このタイプのフレームワークの最大の特徴は、基盤となるレンダリングエンジンやレイアウトエンジンから、中層のDSLや上位のフレームワークまでを自社で開発していることであり、代表的なフレームワークとしてはQtやFlutterがあります。このタイプのフレームワークの利点は非常に明白です: 高いパフォーマンス (上限)、プラットフォーム間で一貫したレンダリング結果。欠点も非常に明らかです。DSL (QML/Dart) を完全に再学習する必要があり、プログラムが小さいという中国の特性を持つ端末に適応するのが困難です。

このタイプのフレームワークは、最も独創的で最も純粋なマルチターミナル開発フレームワークであり、下位層から上位層までのすべてのリンクがユーザー自身の手で行われるため、可能な限り一貫した開発とクロスターミナルエクスペリエンスを保証できます。しかし、フレームワークの開発コストは膨大で、レンダリングエンジン、レイアウトエンジン、DSL、上位層フレームワークの各部分の開発・保守には多大な工数が必要です。

ウェブ技術

このタイプのフレームワークは、Web テクノロジー (JavaScript、CSS) をモバイル開発にもたらします。CSS の処理には自社開発のレイアウトエンジンを使用し、ビジネスロジックの作成には JavaScript を使用し、DSL として一般的なフロントエンドフレームワークを使用し、各エンドで独自のフレームワークを使用します。レンダリング用のネイティブコンポーネント。代表的なフレームワークはReact NativeとWeex、これをやる

利点は次のとおりです。

迅速な開発
フロントエンドのエコロジーを再利用する
学習と使用が簡単で、フロントエンドまたはバックエンドのモバイルバージョンに関係なく、多かれ少なかれ JS と CSS を学習できます。

欠点は次のとおりです。

インタラクションが複雑な場合、高性能なコードを書くのは難しいこの種のフレームワークの設計では、必然的に JSとNative間の通信が必要になるジェスチャー操作などの通信が頻繁に発生すると、UIの動作が妨げられる可能性が高い16ms 以内に描画されます。React Native には、この問題を回避できる宣言型コンポーネントがいくつかありますが、宣言型の記述方法では複雑な対話のニーズを満たすことが困難です。

レンダリングエンジンがなく、各エンドのネイティブコンポーネントがレンダリングに使用されるため、同じコードのレンダリングの一貫性は最初のコードほど高くありません。

コンパイルされたJavaScript

このタイプのフレームワークがこの記事の主役です: Taro、WePY、uni-app、mpvue、chameleon. これらの原則も同様です: まず JavaScript に基づいた DSL フレームワークを選択し、この DSL フレームワークを標準として使用します。それぞれ異なるコードにコンパイルされ、コードが正しく実行されることを保証するためのランタイムフレームワークまたは互換性のあるコンポーネントライブラリが両端にあります。

このタイプのフレームワークを作成する最大の利点および最大の理由は、プログラムが小さいことです。これは、システムプラットフォームをまたがることができることに加えて、1 つ目と 2 つ目のフレームワークはブラウザーでコンパイルして実行することもできるためです。(Qt には WebAssembly 用の Qt があり、Flutter には Hummingbird があり、React Native には React-native-Web があり、Weex にはネイティブサポートがあります)

もう一つの利点は、モバイル端末は一般的に React Native/Weex にコンパイルされるため、Web テクノロジーフレームワークの利点も備えていることです。これは素晴らしく見えますが、実際には、React Native/Weex でコンパイルされたフレームワークの欠点を避けることはできません。さらに、コンパイルされたフレームワークの抽象化は自由ではありません。バグが発生した場合、問題の根本はランタイム、コンパイル時間、コンポーネントライブラリ、およびこれら 3 つが依存するライブラリなどにある可能性があります。

Taro のオープンソース開発の過程で、Babel のバグ、React Native のバグ、JavaScript エンジンのバグ、そしてもちろん Taro 自身のバグにも遭遇しました。同じ原則を持つ他のフレームワークでもこの問題は避けられないと思います。

しかし、これは、小規模プログラム用に設計されたこの種のマルチターミナルフレームワークが役に立たないという意味ではありません。まず第一に、巨大なスーパーアプリからは百の花が咲きました。フレームワークはミニプログラムをスムーズにするために多くの作業を行います。ほとんどの場合、開発者はこれらのタスクを気にする必要はありません。第 2 に、多くのビジネスタイプは複雑なロジックや対話を必要とせず、フレームワークの基礎となる依存関係でバグを引き起こすのはそれほど簡単ではありません。

したがって、ビジネスがコンパイル済みフレームワークの選択に適している場合、著者の意見では、最初に考慮すべきことは DSL の選択の出発点です。複数の端末を必要とする企業は通常、迅速な開発を望むため、チームの開発リズムに迅速に適応できる DSL が重要です。React と Vue (または Vue に似たもの) にはどちらも長所と短所があり、チームのテクノロジースタックと好みに応じて選択できます。