みなさん、こんにちは。私は Flutter GDE の Guo Shuyu です。今日のトピックは、ポピュラー サイエンスの共有コンテンツです。主に Flutter についてより包括的な理解をもたらし、いくつかの誤解を解くのに役立ちます。共有コンテンツは、特に長くなりますが、Flutter をもう一度知るのに役立つはずです。
Flutter がリリースされてから約 6 年が経ち、皆さんも Flutter にあまり馴染みがないと思いますが、まだ Flutter について「よく分からない」という方もいると思いますので、この共有の主な目的は、Flutter を広めることです。 Flutter に関する常識、Flutter に関するよくある誤解を解釈し、雲を抜けて月を眺め、Flutter を再理解します。
したがって、今日は技術的な実現については話さず、ロマンスについてのみ話します。
噂から始める
まずは「噂」からですが、実はFlutterはデビュー当時から物議を醸しており、文章にしても言語にしても、一時期「差別」に悩まされてきました。今振り返ってみると、これは Google の「基本操作」には当てはまりません。
Android が Kotlin と Gradle を活性化したように、Flutter も Dart を活性化し、両者は補完的な関係にあります。
Flutterの開発言語であるDartはもともと競争に負けた「Snow Project」にあった言語なので歴史的な負担もなく、Flutterの足跡に合わせて軽快に戦闘に臨むことができる。
最初に Dart を選択すると、上で示したように JS や Kotlin などのエコロジカルな分割との「衝突」につながりますが、この点で Google は間違いなく活性化に非常に優れており、Dart は Dart 1 から Dart への移行にも非常に優れています。 3. さて、Flutterの足音とともに徐々に成長しています。
もちろん、その一方で、これはおそらく、Dart プロジェクト チームが Flutter の隣にあるという噂と関係があるでしょう。少なくともコミュニケーションには便利です。
もちろん、Flutter のクロスプラットフォーム設定は多くの「マイナス」バフももたらしました。そのうちのいくつかは当初非常に人気がありました。
実際のところ、誰もが少し考えてみる必要があります。それが Google のテクノロジーである場合、それを iOS App Store に掲載できないのは明らかに不合理です。そして、この噂の由来はさらに次のとおりです。
Flutter 開発により iOS ネイティブ開発が失われるため、Apple は独自の開発者を維持する必要があります。
これは実は多くの人の誤解を利用しているのですが、Flutter を使用するか React Native を使用するかにかかわらず、iOS を開発して App Store に公開する限り、必然的に Xcode と MacOS が必要になります。これは Apple にとって悪いことではありません。フルタイムの iOS 開発は Apple のシステムに投資されますが、これ以上ではない可能性があるため、さらに次のことが行われます。
Flutter は上位レベルの UI とロジック ビジネスの完成に役立ちますが、基礎となる対話、ビルド パッケージ化、プラットフォーム サポートはすべてネイティブ開発のサポートと切り離せないものであるため、次のようになります。
Flutter は iOS のエコロジーをある程度圧縮しますが、別の観点から見ると、他のエコロジーの人々が iOS に接触して使用できるようになり、Flutter の Plugin も依然として Swift の推進をある程度サポートしています。
以前から「Flutterはマテリアル系UIだからお蔵入りできない」という話がありましたが、この理論に従えば、筆頭アプリであるTwitterもマテリアル系の製品が強いはずで、Flutterはクパチーノ スタイルのコントロールも備えていますが、製品デザイン スタイルがヒットの理由として使用されるとは予想していませんでした。
Flutter を使用してどのようなスタイルのアプリケーションを開発するかは、その使用方法によって決まります。
実際、Flutter の UI 実装から見ると、Flutter と React Native の違いは、そのコントロールがプラットフォームから独立して自己レンダリングされるため、Unity のような独立したゲーム エンジンに近いということです。 Flutter 当然のことながら、これは App Store の技術的環境における小さな装飾にすぎません。
さらに、App Store の中核はアプリのコミッションです。より多くのアプリを棚に置くほど、より多くのコミッションがプラットフォームを通過する必要がある可能性があります。App Store のガイドラインを満たしている限り、どのようなテクノロジーを使用して棚に置くかは関係ありません。棚に置いてあることが、棚に置かない理由にはなりません。
最後に、新しいニュースをご紹介します。数日前、WeChat は、小規模プログラム用の新しいレンダリング エンジンである Skyline の正式版をリリースし、読み込み速度が 50% 以上向上したと主張しました。ネチズンは、Skyline のレンダリングがパケットキャプチャによるフラッター レンダリング ソリューション。
 |
 |
|---|
WeChat アプレットは Flutter を使用してレンダリングしますが、さらに重要なのは、そのレンダリングがよりきめ細かく制御可能であることです。同期ラスタライズの戦略により、部分レンダリングやネイティブ コンポーネントの融合などの問題をより適切に解決できます。
もちろん、ここでの WeChat アプレットは、フラッター開発方法ではなく、フラッター レンダリング モードを使用しています。開発は依然としてオリジナルのキットですが、Skyline は、大手メーカーが Flutter を使用する一般的な方法でもある変換レイヤーを実行しています。
フラッターの位置決め
次にFlutterの位置づけについてですが、実はFlutterリリース後はクロスプラットフォームの「黒人採用」という属性から、クロスプラットフォームを中心にセルフメディアの不安が生じるのは避けられず、少し前に流行したAIと似ていて、「不安」な雰囲気が似ています。
その前に「ぎこちない」があるからには「ぎこちない吹き」もあるはずで、次の図は Flutter の初期段階で最もよく使われる「ぎこちない吹き」のシーンを示しています。
こうした「恥ずかしい一撃」は、人々に不安をもたらすだけでなく、あらゆる人々の抵抗を呼び起こし、人々は、Flutter の位置づけが、終わりのない状況である Android と iOS の生態系を奪いに来るのではないかと微妙に感じています。
しかし、実際には Flutter の位置づけはそうではなく、Flutter の開発によってネイティブ開発が圧迫されることは避けられませんが、Flutter の本当の目的はここではない、あるいは私たちの視点と Flutter チームは同じレベルにありません。
たとえば、以前に簡単なアンケートを実施しましたが、下図にあるように、「Flutter、どのIDEツールをよく使用しますか？」という統計によると、71.9％が開発ツールとしてAndroid Studioを使用することを選択しました。
しかし、公式統計データによると、この状況は「ソフトウェアエンジニア」や「技術責任者」などの「一部」のシナリオにのみ対応しており、その他の職種ではAndroid Studioを使用してFlutterを開発する可能性が高いことがわかります。
Flutter開発はAndroid開発から転用されたものが多いように感じられるので、Android Studioの使い方に慣れておくと問題なさそうです。
しかし、実際には、全体的な傾向は依然として VS Code にあります。なぜなら、世界には、開発者に加えて、Flutter を使用する「非開発者」も存在するからです。彼らの役割は、学生、デザイナー、PM、その他の非プロの開発者である可能性があります。 、Flutter チームの哲学は次のとおりです。
Flutter は、プロの開発者と非プロの開発者の間に厳格な線引きをしません。なぜなら、今日の学生や趣味の開発者の多くは、明日にはプロになる可能性があるからです。
たとえば、物議を醸した Flutter の GetX の作者である彼の本職は弁護士ですが、開発が大好きで、10 年間ネットワーク セキュリティとサイバー犯罪に取り組み、その後 Dart 言語を学習し始め、次に Flutter を学習し、その後、こうしてオープンソース活動を始めましょう。
したがって、市場での公式の位置付けは、Android、iOS、Web、PC などのネイティブ開発者を略奪して変革するものでは決してなく、より多くのビジョンを持ち、非専門家に開発能力を提供することを望んでいます。カンファレンスでは、FlutterFlow などのコード プラットフォームも何度も言及されていますが、Daro の Flutter のようなローコード プラットフォームもあります。
クロスプラットフォーム UI フレームワークとして、Flutter はフルプラットフォームの UI とロジックのサポートを提供し、開発のしきい値を下げ、コードの再利用を改善することで技術的機能を拡張します。これが Flutter チームのビジョンであり、私たちの視点に立ち返るだけです。開発者は圧迫される可能性があります。
一方で、テクノロジーが成熟するにつれて、開発の敷居はますます低くなります。たとえば、次のようになります。
現段階では、Android と iOS の動作環境の変化は、クロスプラットフォーム フレームワークの出現によるものではなく、テクノロジーがより成熟し、リソースが増加し、開発の敷居が自然に下がっているためです。 Android の始まりは公式 Jetpack システムの完成度は、すべてが「自立」する必要があった 13 年前のようなものではありません。
デバイスのハードウェア サポートが強化され、公式のサポート機能がますます充実するにつれて、クロスプラットフォームの需要は自然に増加します。これは、リソースの再利用の改善が制作において避けられない傾向であるためです。外出先でもサポート
したがって、私の観点からは、クロスプラットフォームは完全に圧迫されているわけではなく、逆に、プラットフォーム A の開発者がプラットフォーム B と連絡を取るのに役立つものもありますし、その逆もある程度、アクティブな開発者を改善することにもなります。 AB の 2 つのプラットフォームの機能。
さらに、Flutter の位置づけは、最近の Web アップデートからもわかります。Web 上での Flutter 3.10 のリリースでは、Flutter Web の公式の立場が明確になっています。
「Flutter は、CanvasKit や WebAssembly などの新しい Web テクノロジーを中心に設計された最初のフレームワークです。」
Flutter チームは、Flutter Web の位置付けは、汎用 Web フレームワークとして設計されていないと述べました。Angular や React など、この分野で非常に優れたパフォーマンスを発揮する類似の Web フレームワークは数多くあり、Flutter は新しいテクノロジーを中心に構築されるべきですCanvasKit やWebAssembly
したがって、Flutter 自体の位置づけは、開発者を競争させたり、変革させることではありません。たとえば、Web 分野では、Dart がネイティブの wasm コードへの直接コンパイルやガベージ コレクションの実装をサポートし始めているなど、むしろ最先端のテクノロジーへの試みです。標準では、将来的に WebGPU が実装されるため、WebGPU + WebAssembly により、将来的に Flutter Web が新しい Flutter Impeller エンジンをサポートできるようになる可能性があります。
PS: ここでの WebGPU は、W3C によって確立された標準に由来しています。WebGL とは異なり、WebGPU は OpenGL に基づいていません。これは、ブラウザ内で 3D 描画の新しい実装を提供できるまったく新しい標準です。GPU ハードウェアに属します (グラフィックス カード) から Web (ブラウジング)、デバイス) まで、グラフィックスやコンピューティング関連のインターフェイスを含む低レベル API を開きます。
したがって、Flutter はネイティブ開発の一部を変革する可能性がありますが、ネイティブ開発には影響しません。これは Flutter のビジョンや目的ではありません。
Flutterの限界と将来
肯定的なことをたくさん言いましたが、Flutter にはどのような制限があるのでしょうか? 実際、フレームワークには制限があり、Flutter の制限は主にその利点から生じます。
ここでは、クロスプラットフォーム フレームワークの開発について簡単にレビューします。
- Cordova などの独自のクロスプラットフォーム フレームワークは、
WebViewローカルの h5 リソースをロードすることで UI クロスプラットフォームを実現し、js ブリッジがネイティブ プラットフォームと対話してプラグインを呼び出し、ネイティブ呼び出しを実現します。 - 第 2 段階は、パフォーマンスを追求して登場した React Native と Weex です。統一されたフロントエンド ラベル コントロールがレンダリング用のネイティブ コントロールに変換され、パフォーマンスが向上します。ただし、ネイティブ コントロールを介してレンダリングされるため、一貫した UI の問題が発生し、互換性の問題、マッチングコスト。
- Flutter では、独立したレンダリング エンジンを使用して、GPU を使用してコントロールを直接レンダリングすることで、プロキシ レンダリングのパフォーマンスのオーバーヘッドを回避し、さまざまなプラットフォームで一貫した UI を確保します。
この観点からすると、Flutter の方が優れているように思えますが、なぜ制限されているのでしょうか。
制限事項
この独立したレンダリング UI 実装により、Flutter の UI レンダリング ツリーはネイティブ プラットフォームから分離されており、現時点で Flutter のネイティブ コントロールにアクセスする必要がある場合、アクセス コストとパフォーマンスへの影響は比較的大きくなります。
実際、アプリの開発では WebView、地図、広告、ビデオなどのネイティブ UI へのアクセスが必然的に必要となるため、Flutter の各バージョンは、ネイティブ コントロールへのアクセスを調整するために長い間努力してきました。 Android ではこれまでに 3 回あり、PlatformView のより大きなアクセス変更は現時点では基本的に使用できますが、次のような制限がまだあります。
3.10、 Flutter は、
PlatformViews画面に表示されるときの途切れを軽減するために iOS のリフレッシュ レートを制限します。PlatformViewsアプリがアニメーションを表示しているとき、またはスクロール可能なときにユーザーはこれに気づくことがあります。
詳細には立ち入りませんが、興味があれば、私が理解した記事を読んでください。
もう一つの制限は「ホットアップデート」です。Flutter がホットアップデートをサポートできないわけではありませんが、Flutter チームのベテランの 1 人である Eric でさえ、退職後に Flutter ホットアップデートをサポートするために shorebirddev を設立しましたが、Flutter 自体の特性は実際には非常に優れています。重要: ホット アップデートには適していません。
Flutter は Release で AOT 実行可能バイナリコードにコンパイルされており、バイナリコードの配布は本来 Google Play や App Store で禁止されているため、Flutter を更新する必要がありますが、この操作によりメンテナンスコストが増加し、パフォーマンスがある程度低下します。
そして、shorebirddev はさらに大胆で、ホット アップデートの機能をサポートするために、Flutter ブランチを直接フォークして魔法のような変更を実行します。このため、現時点では、shorebirddev の Flutter アプリを使用して市場に出すことはサポートされていません。
もちろん、将来的にサポートされる可能性はありますが、たとえば公式 iOS ではすでにサポートされることが示されています。
もう 1 つの制限はテキストのレイアウトと編集です。Flutter のテキスト レイアウトの制限は、まったく新しい独立したエンジンであるため、独自の独立したテキスト レンダリングとレイアウト ロジックを持っています。長年開発されてきた Web レイアウトと比較して、 「かわいい新しさ」に満ちているとのことでしたが、多言語中国語への対応にしても、フォントやフォントの問題にしても、Flutterには調整に時間を要する細かい部分があります。
新しいインペラーエンジンが最近交換されたためでも、テキスト内で修正する必要がある問題はさらに多くなるでしょう。
たとえば、[Impeller] タブには、テキストとタイポグラフィに関する多くの質問があります。
さらに、前に述べたように、将来的には Flutter Web は Wasm への投資を増やすことになるため、互換性の問題も発生するでしょう。たとえば、このページは wasm でレンダリングされた Flutter Web ページですが、プラグインを使用すると、ページのコンテンツを翻訳するには、タイトルだけが翻訳されるまで、メインコンテンツは翻訳されていないことがわかります。
これは、現時点では Flutter Web のメインコンテンツが HTML コンテンツなしでキャンバス上に描画されているため、認識および翻訳できず、また、Web ページを保存または印刷すると、完全な本文コンテンツが出力できないためです。
Web 上のもう 1 つの制限は SEO です。Flutter は Google に Web サイトを見て 3 ～ 8MB であると判断させます。Google Insight を使用して Web サイトをテストする場合、Web サイトは 1.8MB 未満であり、その範囲内で読み込まれる必要があります。順位まであと1秒。
Google や Bing などの検索エンジンは、速度、プログラミング言語、画像の自動サイズ変更、CDN、最終コンテンツに基づいて Web サイトをランク付けします。Google では、ロボットのビューがユーザーのビューと同じであることを要求しています。
たとえば、seo_rendererの使用はクローキングに関する Google の SEO ガイドラインに違反する可能性があり、基本的に Googlebot に「代替テキスト」を追加しているように見えますが
Text、完全に異なる HTML コンテンツを返します。これが問題の核心です。
最後に、Flutter 開発の中期以降は必ずネイティブ開発が必要になりますが、これは避けられない問題であり、コミュニティのプラグイン環境がどんなに充実していても、プロダクトやボスの気まぐれには耐えられません。 、 そのような：
コミュニティにはすでに完全なサードパーティの生体認証プラグインが存在しますが、最終的にはコピーをフォークして、製品の特殊なニーズを満たすように変更する必要がありました。
したがって、Flutter 自体には利点と欠点の両方の制限があり、Flutter を選択するかどうかは主に製品のポジショニングとニーズに基づいて決まります。
未来
最後に、Flutter の将来について話さなければなりませんが、現時点での Flutter への最大の変更点は、新しい基礎となるエンジンである Impeller です。
Skia の代替として、これが Flutter チームの開発のための唯一の方法です。前述したように、Skia 自体には多くの歴史的負担と考慮すべきプラットフォームがあります。Flutter と歩調を合わせる方法はありません。そのため、Flutter は、新しい自己開発 Impeller は非常に重要な投資であり、Flutter チームにより多くの可能性をもたらします。
React Native も Herme を自社開発したのと同じように、JSI は同期呼び出しをサポートし始めました。
現在、Impeller は正式版で iOS をサポートしており、Android にも対応しており、一部のレンダリング フォントの問題など、多くの「痛い時期」の問題も抱えていますが、この投資によってもたらされるメリットは大きく、もしかしたら将来的にはさらに登場するかもしれません。まったく新しいジェネリック「スキア」が誕生するかもしれません。
もう 1 つはゲームです。過去 2 年間、Google I/O は、ピンゲームやカードゲームなど、Flutter を介して対応するゲームをリリースしました。これら 2 つのゲームも、ゲーム分野での Flutter の可能性を示しています。Flutter の自然な設定により、便利で便利です。同様のシナリオなので、Flutter を通じてゲームを実現することも公式表示の可能性です。
Flutter は、過去 2 年間の I/O で Flutter のゲーム機能を非常にうまく活用してきたことがわかります。全体的な UI とゲーム エクスペリエンスは高品質であり、特に今日のゲームは AI 生成とデザインを組み合わせており、さらに改善されました。
最後に、Flutter Forward で Flutter チームによって実証された 3D 機能です。これは、skia が以前は 2D エンジンであったため、3D シーンを完全にはサポートできませんでしたが、今回の Flutter は、単なるデモではありますが、将来の 3D レンダリングの可能性を示しています。 , ケーキを塗る段階に属しますが、これはFlutterの将来への期待でもあります。
したがって、将来的には Flutter での 3D ゲームのサポートも期待できますが、前提としては、まず Flutter が既存のすべての穴を埋めることができるということです。
さて、今日の共有はこれで終わりです。皆さん、ありがとうございました。