この記事はあなたに伝えます:XianyuはFlutterの技術的経験をどのようにアップグレードしますか?

バックグラウンド

現在、Xianyuの主な事業(検索、詳細など)はFlutterが担っています。Flutterは高性能のクロスエンド技術ソリューションですが、事業の迅速な反復と事業の複雑さの継続的な改善により、アプリケーションはそれほど良くありません。満足度は主に、起動の遅さ、ページの読み込みの遅さ、ページのスライド操作のスムーズさ、フリーズなどに反映され、ユーザーエクスペリエンスに大きく影響します。この目的のために、Xianyuエクスペリエンスアップグレードプロジェクトを立ち上げました。Xianyuアプリを使用するユーザーの操作パスの主要ノードから始めて、インストールパッケージのスリム化、起動速度の高速化、ページの読み込み時間の最適化、流暢さの最適化など、アプリケーションを体系的に最適化しました。最終的にはユーザーエクスペリエンスが向上します。この記事では、主にフラッター側のXianyuのパフォーマンスエクスペリエンスの最適化作業を紹介します。これは主に次の3つの部分に分かれています。

  • 流暢さの最適化

  • 検索結果ページの読み込みの最適化

  • 詳細ページの読み込みの最適化

最適化スキームは次のとおりです。


流暢さの最適化

最も難しいFlutter流暢さの問題から始めましょう。オンラインデータと体性感覚の実際の使用から判断すると、検索ページと製品詳細ページのスライドの滑らかさは満足のいくものではなく、世論の遅れについてのフィードバックもたくさんあります。次に、3つの側面で流暢さの最適化を紹介します。

  • フラッターラギングポジショニングツールの構造

  • ロングリストロードモア最適化

  • 小さな画像を読み込んでスクロール

フラッターラギングポジショニングツールの構造

Flutterはデータ駆動型アプローチを使用してUIを構築します。公式のFlutterパフォーマンスのベストプラクティス[1]は指摘しています

  • 親ウィジェットが再構築されると、子Wdigetのbuild()メソッドが頻繁に呼び出されるため、build()メソッドでの反復的で時間のかかる作業は避けてください。

  • 過度に長いbuild()メソッドで過度に大きなウィジェットを返すことは避けてください。それらを異なるウィジェットに分割し、カプセル化します

しかし、ビジネスの急速な反復により、開発者は怠慢になり、パフォーマンスの低いコードを作成する傾向があります。理想的には、問題コードはパフォーマンス分析ツールを介して自動的に特定され、時間内に変更されます。Flutterは、Devtoolsパフォーマンス分析ツールを公式に提供しています。そのタイムラインインターフェイスは、アプリケーションのUIパフォーマンスをフレームごとに分析でき、cpuプロファイラーインターフェイスは、スタックしたプロセスで時間のかかる操作をキャプチャできます。研究開発段階では、このツールを使用して、局所的に再現可能な吃音の問題を分析できます。ただし、Devtoolsの制限は次のとおりです。

  • 吃音の問題が発生した後の分析にのみ使用でき、吃音の問題を監視することはできません。

  • オフライン調査にのみ使用できます。オンラインフィードバックの場合、シーンが不足しているため、何もする方法がありません。

この目的のために、オンラインおよびオフラインの監視と測位によって引き起こされる吃音の時間のかかる機能を監視および特定するためのフラッター吃音ツールを構築する必要があります。実装のアイデア:リリースモードのDartコードはAOTに基づいてコンパイルされ、ビジネスコードとSDKはプラットフォーム関連のマシンコードにコンパイルされるため、シグナルメカニズムを介してネイティブスタックを取得し、シンボリック復元を使用できます。フラッタースタックを取得します。

Catonツールを使用して、流暢さの低下を引き起こす2種類の問題を特定します。時間のかかる機能と過剰なレンダリングの問題です。

時間のかかる機能の配置

時間のかかる関数が原因でスタックした問題については、スタックを表示することで時間のかかる関数を見つけることができます。

コールスタックから、チャネルコールのデータのシリアル化と逆シリアル化には時間がかかることがわかります。FxImageのコードを見ると、resumeImageに対応するネイティブ実装が空であり、フラッター側が実際にこのチャネル呼び出しを保存できることがわかります。

ポジショニングオーバーレンダリング

自動化フェーズで報告される大量のデータは、以下に示すようにレンダリングフェーズのスタックであり、ビジネスコードが見つかりません。

これは、Flutterの更新メカニズムが一元化された非同期レンダリングメカニズムであるためです。ビジネスレイヤーはインターフェイス要素を更新する必要があります。フレームワークレイヤーは、最初に更新が必要な要素をダーティし、次に次のエンジン側のレンダリングコールバックを待ちます。今回はコールバックをレンダリングします。以前に収集されたダーティ要素は一律に更新されます。このメカニズムにより、取得およびレンダリングフェーズ中にスタック内に多数のElement.rebuildおよびupdateメソッドが発生します。これらはすべて、フラッターフレームワークの関数呼び出しスタックであり、ビジネス側のコードが欠落しています。これらのスタックを見るだけです。スタックした問題を見つけるのに役立ちません。

私たちのアイデアは、レンダリングプロセスでダーティ要素の情報を増やすことで、ダーティ要素の複雑さに応じて(要素のサブノードの深さ、長さ、数に応じて複雑さを計算します)、次のことを検出するのに役立ちます。コードの不規則性がありますリフレッシュ範囲が大きすぎるという問題が発生します。

このソリューションを通じて、詳細ページを見つけて、コンポーネントの過剰レンダリングの問題をすばやく尋ねます。

ダーティ要素の情報を見ると、ダーティ要素がより複雑であることがわかります。最適化スキーム:ビルド効率を改善し、setStateリフレッシュデータシンクをリーフノードに、各ラベルをLabelStatefulWidgetに抽出し、部分的なリフレッシュのみを実行します。

ロングリストロードモア最適化

ラグツールを使用すると、検索結果のページリストをスライドして読み込むプロセス中にリストコンテナ全体が汚れて再構築され、深刻な流暢さの問題が発生することがわかりました。分析後、さらにデータをロードして戻った後、リストデータが追加された後にsetStateが呼び出され、ダーティコンテナウィジェットがクリーンアップされることがわかりました。また、プリロードを行うため、下部の最初の数画面にスライドすると、より多くのロジックをロードするようにトリガーされます。これにより、ウィジェットが汚れているときにウィジェットを再構築する頻度が高くなります。最初のフェーズでは、ビジネスレイヤーから開始し、より多くのデータをプリロードしてsetStateを呼び出さなかったが、最初にそれをメモリに保存し、一番下にスライドしてリストコンテナを再構築した後にsetStateを呼び出した。後で、リストコンテナの下部から最適化します。ロードモア中にリストコンテナ全体が汚れたり再構築されたりすることはありません。コンテナの読み込みとスライドのプロセスが大幅に最適化され、改善の経験がより明確になります。

最適化の前に、次の図に示すように(赤い領域はダーティウィジェットを示します)、コンテナー全体が更新されていることがわかります。

[画像のアップロードに失敗しました...(image-88d1df-1607610735943)]

最適化後、新しく追加されたカードのみを更新します

[画像のアップロードに失敗しました...(image-d1416d-1607610735943)]

小さな画像を読み込んでスクロール

フィードストリームカードには多数の画像が含まれています。高速スライドのプロセスでは、多数の画像をロードすることはメモリとIOの大きなテストであり、特にローエンドマシンでの流暢さに影響します。最適化のアイデア:高速スクロールのプロセスでは、小さいファジー画像のみをロードし、スクロールが停止するまで待ってから、元の画像を徐々に表示します。画面領域を超えて元の画像をロードしないで、画面エクスペリエンスを最適化します。効果を図に示します:(効果を示すために、ここに5分の1に縮小された小さな画像があります)

[画像のアップロードに失敗しました...(image-853675-1607610735943)]

概要

最適化後、Xianyuの詳細ページと検索ページの流暢なFPSが3ポイント増加し、ローエンドマシンでの大規模なフリーズの数が半分に減少し、ミッドエンドモデルからハイエンドモデルの流暢さが57以上で、大規模なフリーズの数は0に近いです。

詳細ページの高可用性fpsデータは次のとおりです。

オンラインローエンドマシンのfps曲線では、横軸はフレームレート範囲を表し、緑は最適化されたバージョンです。曲線の右側が多いほど、流暢になります。

オンラインハイエンドマシンのfps曲線。緑は最適化されたバージョンです

検索ページで高可用性のfpsデータは次のとおりです。

オンラインローエンドマシンのfps曲線。緑は最適化されたバージョンです

オンラインハイエンドマシンのfps曲線。緑は最適化されたバージョンです


検索結果ページの読み込みの最適化

流暢さの問題を最適化した後、ページの読み込みのためにどのような最適化を行う必要があるかを見てみましょう。最適化の前に、検索キーワードから検索結果の表示まで長い負荷がかかります。ページの読み込み速度を最適化するために、ビジネスプロセスから始めて、ブレークスルーを見つけます。検索結果ページを開くプロセスは次のとおりです。

検索結果ページはFlutterによって実装されていますが、クリックしてネイティブページから開きます。混合スタックのコンテキストでは、コンテナーを開くためのルートインターセプトには時間がかかります。URLを介してプリフェッチ情報を伝達し、ネイティブがジャンプナビゲーションを実行しているときに非同期および並列のデータプリフェッチを実行できるため、ページを開く時間の消費を減らすことができます。同時に、検索ページのリクエストRTが比較的高いため、一般ページが表示され、ネットワークリクエストが返されるのを待機しています。したがって、ネットワークリクエストが返されるときにテンプレートがプリロードされている場合、確率はヒットします。

最適化されたプロセスは次のとおりです。

データのプリフェッチとテンプレートのプリロードスキームを使用した特定の並列手段により、ローエンドのAndroidマシンでの検索結果ページのロード時間を300ミリ秒最適化しました。同時に、データが要求されたときに小さな黄色のニベをロードする代わりに、スケルトン画面のアニメーション(lottieによって実現)が表示されるため、ユーザーエクスペリエンスが向上します。

最適化前:

[画像のアップロードに失敗しました...(image-45c8ba-1607610735943)]

最適化:

[画像のアップロードに失敗しました...(image-e347e6-1607610735943)]


詳細ページの読み込みの最適化

詳細ページの読み込みを最適化するために、主に次の3つの方法を使用して最適化します。

  • FlutterBoostの最適化

  • データ透過送信

  • トランジションアニメーション

FlutterBoostの最適化

Xianyuは現在もNative + Flutterのハイブリッド開発モデルであり、FlutterBoostを使用してハイブリッドスタックページのマッピングとジャンプを処理します。FlutterBoostのオープン処理では、startActivity()を介して新しいコンテナが開かれ、詳細ページのジャンプシーンのほとんどがFlutterページからジャンプされます。実際、以前に開かれたコンテナは再利用できます。このようなアプリケーションシナリオのために、FlutterBoostに新しい機能を追加しました。Flutterページで新しいFlutterページを開くときに、2つのFlutterページ間で同じFlutterコンテナー(Activity、ViewController)を共有して、ページを開く速度を上げることができます。そしてメモリ消費を削減し、ページ切り替えアニメーションを実現するためにFlutterをサポートします。

データ透過送信

検索結果ページが詳細をスキップし、詳細をスキップしたいと推測するシナリオでは、詳細データの一部は以前のインターフェースからすでに利用可能です。データのこの部分を詳細ページに透過的に送信できます。詳細データをリクエストする場合は、最初にメインの画像、タイトル、価格、その他の詳細データなどの簡単なコンテンツを表示してから、詳細ページを更新して簡単なエクスペリエンスを提供します。

トランジションアニメーション

以前のデータ透過送信に基づいて、トランジションアニメーションを使用して、没入型ページ切り替えの効果を実現し、ユーザーエクスペリエンスをさらに向上させます。

実現のアイデア:ルーティングナビゲーションのプロセスでは、ModalRouteを継承してbuildPageプロセスを引き継ぎ、詳細ページAnimateDetailPageの簡略化バージョンをアニメーション化し、アニメーションステータスを監視し、アニメーションが完了したらウィジェットツリーに詳細ページDetailPageをハングアップします。 。

最適化前:

[画像のアップロードに失敗しました...(image-155316-1607611144523)]

最適化:

[画像のアップロードに失敗しました...(image-f9445-1607611144523)]


要約見通し

要約すると、Xianyu Flutterのパフォーマンスエクスペリエンスのアップグレードでは、技術的な詳細の最適化の観点から、メインページの読み込み時間と流暢さを最適化しました。ビジネスプロセスの最適化に加えて、いくつかの一般的な最適化機能も蓄積しました。たとえば、データのプリフェッチ、フレーム内の画面上のウィジェット、長いリストをロードするためのより多くの最適化、長いリストの部分的な更新機能、および長いリストのスクロール差分アルゴリズムの最適化。視覚的な最適化に関しては、若々しさのテーマが強調され、デザインには多数のマイクロアニメーション要素が使用されています。FlutterLottieアニメーションは、公開ページ、検索結果の読み込みページ、読み込み中の各更新アニメーション。最適化後、Xianyuアプリの操作はよりスムーズで滑らかになりました。

将来的には、Flutterエンジンの起動についてさらに調査し、検討する必要があります。特に、ホームページがFlutterに切り替えられた後は、Flutterの起動を最適化する必要があります。また、事業の反復が早いため、初期の最適化作業は後の段階で容易に悪化する可能性があります。ビジネスが急速に変化する中で効率を満たし、パフォーマンスを確保する方法は、解決する必要がある次の問題です。たとえば、コード統合前のパフォーマンスバヨネットを介して、パフォーマンス基準を満たさないコードを返し、最適化の提案を行います。 ;パフォーマンス最適化メソッドはコンテナフレームワークに組み込まれています。

参考文献

[1] Flutterパフォーマンスのベストプラクティス:https:  //flutter.cn/docs/testing/best-practices

元のアドレス:Xianyuはどのようにして技術的な経験をFlutterにアップグレードしますか?
(サイレント...建州は実際にはその効果のアニメーションを置くことができません、興味があれば元のテキストに行くことができます)

やっと

Androidテクノロジーの学習は、順調に進むことはできません。山と谷があります。私たちを打ち負かすことができないものが、最終的に私たちを強くすることを信じなければなりません。

千マイルの旅は一歩から始まります。あなたと私が互いに励まし合うことを願っています。

この記事オープンソースプロジェクトに含まていますhttps//github.com/xieyuliang/Note-Android(青いフォントをクリックして入力してください)、さまざまな方向への自己学習プログラミングルート、インタビューの質問の収集/顔が含まれています経典、および一連の技術記事待ってください、リソースは更新され続けています...

今回はここで共有してください次の記事で会いしましょう

おすすめ

転載: blog.csdn.net/weixin_49559515/article/details/112020923