Android 向けアプリ起動の最適化

背景

なぜ起動の最適化について再び言及する必要があるのでしょうか? まず第一に、ユーザーが APP に入る唯一の方法はアプリを起動することです。これがコアリンクを体験する最初のリンクです。起動にはコールドスタート、ホットスタート、ウォームスタートがありますが、特に断りのない限り本文中で「起動」という場合はコールドスタートを指します。起動時間が長すぎると、コールドスタートバウンスというユーザーロスが発生します。APP エクスペリエンスの全体的な観点から見ると、起動はコアチェックポイントにあり、これは非常に重要なリンクであり、APP の中核指標の 1 つです。ビジネスがますます複雑になるにつれて、起動プロセス中に実行する必要があることがますます増え、多くのアプリは当初の起動計画が悪化し続け、その結果エクスペリエンスが低下するという問題に直面していますが、私たちも例外ではありません。スタートアップの最適化はよくある問題ですが、この記事では 1688 の現状に焦点を当て、私たちが具体的に行ったことを共有し、何らかの利益をもたらすことを期待します。

テクノロジー開発の旅の始まり

起動最適化について語る前に、まず起動最適化関連技術の開発の歴史を振り返ってみましょう。冒頭のwindowBackgroundへの画像の追加から、その後の各種操作までを画像で簡単に表現します。

この図では、誰もがよく知っている解決策をいくつか列挙しただけです。これはすべてを表しているわけではなく、参照のみを目的としています。スタートアップの最適化を頻繁に行う友人なら、これらの解決策の方がよく知っているかもしれません。スタートアップに関して言えば、多くの企業は努力を惜しまず、最適化の結果を達成するためにパフォーマンスを圧迫するために多くのブラックテクノロジーさえ使用します。開発コストが限られている個人やチームにとっては、実行に適さないものもいくつかあります。以下に、限られたコストでより大きな効果を得るアイデアについて説明します。

注: この記事の内容は、Android 開発を学ぶすべての学生に適用されます。

1688 起動の最適化は何をしますか?

最適化を行う前に、まず現状を分析する必要があります。1688 APP は「Alibaba」と呼ばれ、すべての主要なアプリケーションストアからダウンロードできます (以下、総称して Alibaba APP と呼びます)。アリババAPPの現状はどうなっているのでしょうか？

windowBackground を使用してボディの感触を向上させる
時間のかかるタスクに対して単一ポイントの最適化が行われました。
マルチスレッドのバッチスケジュールタスクを利用します

バッチスケジューリングの実装の簡単な説明: スタートアップタスクを 4 つのバッチに分割します。まず、最初のバッチを Application onCreate で実行し、次に 2 番目のバッチをサブスレッドで実行し、3 番目のバッチを HomeActivity onCreate のサブスレッドで実行します。、ホームページをレンダリングした後、サブスレッドが 4 番目のバッチを実行します。同一バッチ内では、設定されたパラメータに従ってグループ化され、同じグループは同時に実行され、残りはパラメータに従って順次実行されます。このスケジューリングスキームには大きな欠点があります。決定的に実行されるアプリケーション内のタスクを除き、他のサブスレッドのタスクは完了する正確なタイミングを知ることができません。できる限り早く実行を開始することしか言えません。。ビジネスの複雑さが増すにつれて、ホームページに入る前に完了する必要がある一部のタスクは、アプリケーション段階でのみ追加できます。起動タスクを一つ一つメモするのがちょっと面倒だったので、一つのタスクで複数の処理が行われてしまい、タスクも文字化けしてしまいました。

スタートアップ定義

まず、「コールドスタート」とは何かを理解する必要があります。Android の起動の公式定義はドキュメントにあります: https://developer.android.com/topic/performance/vitals/launch-time. Logcat の Displayed のフリッターを通じて起動時間をフィルタリングできます。例えば：

では、アリババグループは Android アプリケーションの起動をどのように定義しているのでしょうか? 主に以下の4つの段階に分かれています。

システムの初期化
アプリケーションの初期化
スクロールせずに見える範囲
起動完了（対話型）

この記事では「アプリケーションの初期化」と「最初の画面表示」の2段階の最適化に焦点を当てます。アプリケーションの初期化とは、アプリケーションの起動からホームページのアクティビティの onResume までの時間を指し、最初の画面表示とは、アプリケーションの起動からホームページのレンダリングが 80% 完了するまでの時間を指します。以下では、アプリケーション初期化ステージの最適化とは、アプリケーションの起動からホームページのアクティビティ onResume までのステージを指します。マルチコア機能を使用してアプリケーションステージでのタスクスケジューリングを改善し、それによって単一タスクの CPU アイドル時間を短縮する方法に焦点を当てています。ホームページ表示の最適化では、ホームページのアクティビティの再開からホームページの 80% レンダリングの完了までの段階に焦点を当て、ホームページの最適化戦略に焦点を当てます。

まず、起動最適化の全体的な計画を示す写真を撮りましょう。

アプリケーションの初期化フェーズの最適化

上で、古いスタートアップフレームワークのいくつかの欠点について説明しました。

決定的に実行されるアプリケーション内のタスクを除き、他のタスクはいつ実行されるかわかりません。後続のシナリオでは大量のチェック初期化が必要です。
タスクは徐々に面倒になり、破損していきます
タスク間でロックの競合があり、モデルによってエクスペリエンスが大きく異なり、1 つのタスクに時間がかかり、上位層はそれを感知できません。

ビジネスの継続的な発展に伴い、モジュールに必要なタスクが正常に初期化されたかどうか、つまり初期化前のタスクが後続のプロセスのどの時点でも明確になるように、特定の時間に特定のタスクをスケジュールする必要性がますます高まっています。ホームページとそれに続く柔軟なスケジュールプラン。決定性も必要です。以前はサブスレッド間に隠されていた問題が、今後は明らかになり、対処される必要があります。第 2 に、単一の責任を決定するために起動タスクを再編成して配置する必要があります。これにより、将来のタスクの継続的な破損を防ぐこともできます。同時に、これは「ロックフリー」タスクスケジューリングの基礎でもあり、マルチコア機能と単一タスクのアイドル状態の削減全体的な最適化を実現するには時間がかかります。クライアント呼び出し、Web 外部リンクの起動、自動ログイン、フロントエンドとバックエンドの切り替えなどの複数のシナリオの状況では、シナリオに基づいてカスタマイズされた起動タスクのオーケストレーションをサポートする必要があります。

これに基づいて、オンラインタスクの実行状況を検知できる、より包括的な監視機能も必要です。開発期間中に、テストプラットフォームと統合してバヨネット強制制御起動タスクを実行し、異常に時間がかかるタスクが発生していないかを検知できます。タスクが表示されます。グループ内のすべての Android 学生に、起動タスクがどのようにスケジュールされているか、および担当するビジネスモジュールに関連付けられた起動リンクがさまざまな起動シナリオでどのように実行されるかを明確に理解できるようにします。

上記の要求に基づいて、私たちはスタートアップフレームワークを再開発し、それをYasuoと名付けました。

そして、強風を受けながら前進するときは、後ろにあるものにも注意を払う必要があります。

誰もが知っているように、爆風に立ち向かえ！新しい起動フレームワークによって APP が風のように早く起動できることを願って、それを「Yasuo」と名付けました。

それでは、Yasuo の全体的な構造はどのようなものでしょうか? タオバオの DAG スケジューリングフレームワークに基づいて、中間層の機能をさらにカスタマイズおよびカプセル化して、オリジナルのスタートアップライブラリに接続し、比較的低コストでスタートアップリンク全体を変換しました。

上の図は、Yaso の全体的なアーキテクチャを最も単純な階層構造で示しています。Taobao DAG スケジューリング機能に下位にアクセスでき、1688 の以前の起動フレームワークを継承しています。コアモジュールは次のとおりです。

コア (DAG に基づく上位層のカプセル化)
統計 (モニタリング統計モジュール)
common (パブリックモジュール)
config (構成モジュールの開始)
api (タスクの開始によって呼び出される API モジュール)
ブートストラップ (ランチャーエントリー)

私たちは主に、さらにいくつかの重要なことを行いました。

タスクを分割して開始し、細かい部分に再分割し、単一の責任に従います。
ヤスオ躯体工事
タスクを再編成し、さまざまな方法でロックのないスケジューリングを実現しようとします

外部の学生向けに、DAG スケジューリングフレームワーク用のオープンソースソリューションがすでに多数存在します。適切なフレームワークを選択して、「Yasuo」に似たランチャーにアクセスして実装できます。アイデアのほとんどは共通です。

タスクの開始と分割はデリケートな作業であり、言うは易く行うは難しです。まず第一に、すべてのスタートアップタスクを比較的包括的に理解し、それらを「解体」するための開始点を見つける必要があります。長年開発してきたアプリなので、基本的にタスク開始時に何が行われるのか説明できる人は誰もおらず、少しずつ見て解体するのに大変な労力がかかりましたが、最終的には元のタスクから40個弱になりました解体されて70個以上到着しました。

タスクが再編成されるため、より多くのエネルギーが消費されます。ご存知のとおり、ほとんどの人は、特に起動リンクで問題が発生することを恐れて、「祖先コード」に触れることをあえてしません。問題が発生すると、オンライン事故につながる可能性があります。今回、私たちは祖先の規範の海に深く入り込み、虎のように激しく行動しました。計画を立てる際に考慮すべき最も重要な点が 3 つあります。

ロック解除済み
シーケンス (明示的な依存関係と暗黙的な依存関係)
複数のシナリオでソリューションをアレンジする

まず、グループのセカンドパーティライブラリを深く掘り下げて、分割とロックフリーのオーケストレーションを実行し、内部コードに基づいてシーケンスの依存関係を特定します。次に、私たちは自分たちのスタートアップタスクを注意深く研究し、グループのクラスメートと協力し、数え切れないほどの実験を行い、最終的な配置計画を決定するまでに、2、3のバージョンを繰り返しました（涙）。起動段階では、独自のタスク間でロック競合が発生する可能性があることに加えて、誰もが遭遇する可能性のある次のような一般的な問題が発生します。

データ読み取り用の SharedPreferences ロック。SharedPreferences が初めてファイルを読み取るとき、そのファイルは新しいスレッドによって読み取られます。
loadLibrary0のロック（ロードso）
キャッシュ読み取りファイルのロック
事前にビューをインフレートする場合、同じコンテキストが使用されている場合、インフレートもロックされることに注意してください。

これらの問題に対する主な解決策は、SharedPreferences とキャッシュのプリフェッチであり、負荷をできるだけ各ステージに分散して実行するようにします。分析には公式の Android 分析ツール systrace を使用することをお勧めします。Yaso の内部モジュールにはすべての起動タスクとステージでトレースがあります。トレーススイッチをオンにすると、実際のパッケージに最も近いリリースパッケージで分析できます。データ。また、Google の新しいツール: https://ui.perfetto.dev/ を使用することをお勧めします。これは、systrace の HTML ファイルを表示するだけでなく、高バージョンの Android システムでトレースを記録することもできます。ドキュメントを使用してカスタマイズしてください。

Alibaba APP オンラインの最新バージョン (9.10.3.0) では、タスクスケジュール部分が開始されます。

特にフロントリンクは基本的にロックが解除されていることが分かります。ロックフリーとは、ロックの競合があってはいけないという意味ではなく、フェーズ的に見ると、時間のかかるピークを解消し、時間のかかるフェーズをスムーズにし、全体最適を実現することを意味します。複数のモデルの問題を考慮する必要があり、ROI に十分な注意を払う必要があります。同時に、単一ステージのタスクの配置では、スレッドのスケジューリング機能も考慮する必要があり、暗黙の依存関係 (ステージ間の依存関係) を使用して、いくつかの難しいロック競合問題を解決することもできます。問題を総合的に見てバランスをとることを忘れないでください。

最後に、メインプロセスのコールドスタートフェーズ中に、次のフェーズ (呼び出しを含む) を有効にしました。

アプリケーション添付
アプリケーション onCreate (3 つの小さなステージが含まれます)
最初のアクティビティの onCreate
外部リンク通話開始
Push Activity onCreate (オフラインプッシュ呼び出し開始)
インタラクティブを起動した後にステージをトリガーします
メインスレッドがアイドル状態になった後
メインスレッドが 5 秒間アイドル状態になった後

さらに、小さなプログラムのプロセスなど、他のプロセスの段階もあります。合計 70 以上のタスクがスケジュールされており、その80%はインタラクションが開始される前に実行されます。つまり、これらのタスクは初期化されており、ユーザーがホームページにアクセスしてインタラクションできる前に使用できます。これは、古い起動フレームワークと比較して、スループットは4 ～ 5 倍向上します。

Alibaba APP (9.10.3.0) の最新オンラインバージョンの起動フェーズ図 (通常のコールドスタート):

アプリケーションの初期化の主要な段階では、新しいソリューションの全体的な消費時間が古いソリューションと比較されます。最適化の余地はあまりありません。市場全体の平均からすると、100 ～ 200 ミリ秒の時間消費が削減されますが、これは限界です。古いソリューションと比較すると、フレームワークはアプリケーションフェーズで10 個のタスクのみをスケジュールします。これは、後続のホームページ表示やその他の段階に非常に大きな操作スペースを提供し、完全な起動制御性を実現し、研究開発期間中にバヨネットを使用し、オンラインになった後に認識することができ、その後の柔軟な起動ソリューションの基盤を提供します。

ここに小さなヒントがあります: 起動イメージが大きな背景色 + ロゴまたはコンテンツの形式で Alibaba APP に似ている場合は、レイヤーリストを使用して実装することをお勧めします。背景色を変更し、ロゴまたはコンテンツに小さな画像を使用します。これにより、windowBackground のデコードにかかる時間が短縮され、変更は小さくなり、メリットは大きくなります。

ホームページ表示の最適化

まず、ホームページの基本構造を紹介します。

ホームページは、2 階のコンテナ、静的なメインページ (検索コンポーネント、マルチタブコンポーネントを含む)、動的に構築されたホームページタブ、および業界タブページ (CyberT コンテナで構築) で構成されます。

1688ホームページの特徴は、ビジネス形態が複雑、レスポンシブなタスクが多い、入れ子になったコンテナが多い、動的機能への要求が高いこと、さらに長年の開発を経て、ホームページのさまざまなマーケティング機能が充実していることです。ポップアップレイヤー/フローティングウィンドウ/フローティングバーなどが絡み合っており、ビジネスの能力やインタラクションに影響を与えることなく、ROI を考慮し、前の記事のYasuo スタートアップフレームワークが獲得した大量のスペースを借りています。最も当面の戦略的方針は、空間と時間を交換することです。

したがって、上記のコンテキストでは、Yasuo フレームワークによって提供される決定論的な起動フェーズとプログラム可能なタスクシステムに依存すると、起動時間を大幅に短縮することはできませんが、ホームページの最適化に多くの操作スペースが提供されます。マルチコア機能を最大限に活用して、ホームページの最適化にかかる時間を稼ぐことができるということです。

主な最適化の考え方は次の 3 点に分かれます。

起動時に干渉要因が多すぎないメインスレッド環境を確保** (時間のかかるタスクの前後)**
レンダリングコンテナ変換は、ホームページレンダリングのロジックの一部を実行のためのアプリケーション初期化ステージに置きます** (レンダリング時間の折りたたみ)**
起動時に多数の繰り返し操作がメインスレッドを占有することを防ぐためのレンダリングデータ制御/リフレッシュ制御(コンテンツのレンダリングを保証するため)

1. 起動時にメインスレッド環境を確認する

まず、アプリケーションの起動直後は CPU が最も忙しい時期であり、多数のセカンドパーティライブラリの初期化によりサブスレッドの数が急激に増加します。メインスレッドとタイムスライスの間の境界は非常に激しくなります。したがって、ホームページ表示段階まで実行する際には、メインスレッドが他のタスクに占有されないようにする必要があります。たとえば、メインスレッドの操作を必要とする WebView の初期化や Flutter の初期化などのタスクを適切に転用でき、ホームページがレンダリングされた後、またはアイドル状態になった後にタスクをトリガーできます。

WebViewの初期化タスクが事前に実行される問題：

ホームページに入ると、赤い封筒を提供したり、会場へのトラフィックを集めたりするためのマーケティングポップアップ機能がポップアップ表示されることがよくあります。この弾性層は H5 によって実装され、WebView 初期化タスクに依存します。祖先のコードをデバッグするときに、古いスタートアップの設計原則は、モジュールが実行される前に関連する初期化モジュールが実行されていることを「可能な限り」保証することであることがわかりましたが、その順序は保証されない可能性があります。 init は、古いコードが実行される前に呼び出されます。つまり、関連する初期化モジュールがまだ実行されていない場合、初期化タスクが強制的に起動されて実行されます。その結果、ホームページアクティビティに入る前にWebViewの初期化が行われることになり、WebViewの初期化作業に時間がかかり、ホームページ表示段階でCPUリソースを無駄に消費してしまいます。

したがって、この現象に対処するためにいくつかの改善を行いました。

WebView の初期化タスクを分割し、マーケティングエラスティックレイヤーに必要なモジュールを分離して、時間の消費を削減し、ステージのボトルネックにならないようにし、Activity onCreate ステージで事前に実行します。
マーケティングポップアップレイヤーのトリガーロジックをホームページの背後に配置し、80% のレンダリング後にコールバックをトリガーします。
マーケティングレイヤーのポップアップロジックの事前判断 ---- 初期化後にページが表示されないことによるリソースの無駄を防ぐために、ポップアップレイヤーを表示する必要があるかどうかのロジックを事前に実行し、マーケティングポップアップレイヤーの覚醒率とパフォーマンス消費時間のビジネス効果。(プログラムの開始後、市場に約 200 ミリ秒の改善をもたらしました)

2. ホームページの事前レンダリング

ホームページのレンダリングフレームワークは、1688 によって開発されたコンポーネント化されたページ配信システムである CyberT コンテナを使用します。このページは、コンポーネントテンプレート、スタイル、データを動的に配信することによって構築およびレンダリングされます。また、電子商取引ビジネスの強力なダイナミクスと、ホームページでのネイティブパフォーマンスのエクスペリエンス要件も満たします。ホームページタブと業界タブページは、CyberT コンテナを使用して構築されています。

ヤスオのオーケストレーション機能によってもたらされたスペースを最大限に活用するために、CyberT 上でレンダリング最適化ロジックを変換して沈殿させ、アプリケーションの初期化フェーズでロジックの一部を事前に実行し、それぞれ以下を実装しました。

CyberT プロトコル分析、事前生成の表示
レイアウトファイルの事前生成
ホームページコンポーネントのテンプレートの事前作成

CyberT プロトコル分析、事前生成を表示:

デバッグプロセス中に、プロトコル解析のメインスレッドコールバックがホームページ表示段階にあることが判明しましたが、メインスレッドがビジー状態のため、長時間アイドル状態となり、CyberT ページを生成できませんでした。 CyberT の初期化タスクが完了した後でのみページを実行できるようにするため、起動フェーズでボトルネックにならないように、アプリケーションの初期化フェーズでキャッシュされたプロトコルとコンポーネントのデータを使用して、プロトコルの解析とビューの作成を事前に実行して保存しますをメモリ内に保存し、ホームページのフラグメントが生成されるのを待つときに直接追加します。ビューツリーに入り、後続のレンダリングロジックを実行します。プロセス全体でアプリケーションコンテキストを使用してコンテキストを公開し、Use Once ロジックを実装し、メモリリークを防ぐために適時にリサイクルします。また、オンラインの成功率を監視し、モデルのスコアを成功率に関連付け、構成の切り替えを発行し、プログラムの利点を最大化するために異なるスコアを持つモデルの最適化戦略を調整します。(このソリューションの発売後は、150 ミリ秒から 200 ミリ秒の改善を市場にもたらすことができます)

レイアウトファイルの事前生成:

トレースファイルを解析したところ、メインスレッドではxmlの解析にある程度の時間がかかることが判明したため、ホームページ上で実行する必要があるActivity、Fragment、2階Viewのレイアウトファイルについても、事前にスレッドの中断を避けるために、アプリケーションステージでそれらを作成し、過剰な作成とインフレートによるアプリケーションロックの競合の問題を解決するために、シーケンシャル実行のためにシングルスレッドプールに配置しました。また、成功率の監視と最適化戦略の柔軟な調整にも優れた仕事をしています。

テンプレートの事前作成:

CyberT がページをレンダリングおよび構築するとき、多くの場合、最初にコンポーネントテンプレートをリクエストまたは読み取り、対応するブロックのビューを生成します。テンプレートの事前作成のための初期化タスクを策定し、テンプレートファイルとコンポーネントのキャッシュデータを事前に View に生成してキャッシュプールに配置することで、後続の IO 待機による更新によるリソースの無駄を削減し、コンポーネントを圧縮しました。生成時間はマイクロ秒です。

3. 描画データ制御・リフレッシュ制御

ユーザーができるだけ早く対話できるようにするという目的を達成するために、1688 は現在、キャッシュされたデータのレンダリングを優先し、ネットワークデータがコールバックされた後に差分リフレッシュを実行するレンダリング戦略を採用しています。ここでの制御は、実際にはコードの合理性をチェックすることです。コードロジックに、ページが頻繁に更新され、ユーザーが操作できなくなるような不当なコールバックはありませんか? まだレンダリングされていないキャッシュデータがあり、ネットワークデータが強制的に更新されて、ユーザーの操作時間が遅延していませんか? 私たちは上記の問題に対処し、インタラクティブ性の前後のレンダリングロジックを強力に制御して、レンダリングプロセス中の論理的不合理によって引き起こされるリソースの浪費を防ぎます。最適化の初期段階では、祖先のコードの不合理な側面を合理的な側面に変えると、予期せぬ利点がもたらされることがよくあります。

パフォーマンスのスケーリングを有効にする

前述したように、ホームページの表示最適化のプロセスでは、一部の戦略では成功率に問題があることがわかりましたが、オフラインモデルの観察とオンラインデータの比較により、CPU 能力が弱いローエンドモデルでは、前世代と前世代のモデルでは、作成ではキャッシュが失敗する可能性が高く、その結果、タイムスライスリソースが無駄になり、さらには最適化が低下することもあります。したがって、ロングテールユーザーのために、動的なパフォーマンススケーリングソリューションを設計しました。ソリューション全体の一般的なプロセスは、ユーザーモデルの評価/母集団の選択/ネットワーク環境などに基づいており、リモートプラットフォームによって発行された構成と組み合わせて、それをクライアントの意思決定エンジンに入力し、意思決定を保存します。次回の起動時に有効になるようにローカルで戦略を作成します。また、オンラインビューキャッシュの成功率、ローエンドマシンの起動時間、さまざまな人々のグループの起動時間、その他の指標を観察して、戦略的利点を検証します。

たとえば、ローエンドマシンでは、プリロードと事前生成機能をオフにする、同じ画面でのビデオ再生数を制御する、GIF アニメーションを制御する、WebView Init/Flutter Init などの時間のかかるタスクを延期するなどの戦略を採用しています。低コストのシナリオを優先するため、5 秒後にシナリオをアイドル状態にします。ハイエンドモデルで関連戦略を有効にし、最適化戦略の利点を確実に最大化するだけでなく、ユーザーの観点から、マーケティング戦略に迅速に対応する段階で時間のかかるボトルネックにならないようにマーケティング機能/マーケティングページをプリロードします。経験とビジネス変革のバランスポイントを見つけます。

予防と制御の方法

スターターコンテナ:Yasuo を沈殿させました。コンテナ側では、オンライン監視、研究開発バヨネット、テストプラットフォーム統合の機能を備えており、開発から起動までのすべての段階を制御してタスクの破損を防ぐことができます。ホームページ側では、最適化の一部は CyberT コンテナーの開発に基づいています。コンテナー側自体には銃剣があり、その一部はホームページ自体の最適化です。私たちが開発しているフルリンクログシステムの助けを借りて、主要な位置に横断的なポイントを設け、モニタリング機能を備えています。例外が発生した場合は、時間内に通知を受け取ることができます。

開発期間中はgitを利用してコードウェアハウスを管理し、スタートアップライブラリやスタートアッププールに関するウェアハウスの権限を強化し、オンライン化した際に変更が明確に認識できるようにするとともに、コードレビューの仕組みと合わせて、コアリンクの問題が軽減されます。同時に起動オーケストレーションクラスや起動プールクラスも対応するスクリプトで生成されるため、スクリプト内容がシンプルで保守が容易であり、保守コストも削減できます。

効果

この記事の執筆時点で、Alibaba APP の起動時間は、8 月と 9 月の約 3 秒から、現在の 1.9 秒に最適化され、36.67 %減少しました。

8 月と 9 月のデータと比較すると、コールドスタートの直帰率は75%減少しました。

タイプ B 購入者ユーザーと潜在的なタイプ B 購入者ユーザーのドリルダウン分析により、全体的なデータが市場より優れていることが判明し、将来的には群衆の最適化戦略が行われる予定です。

伸縮戦略と縮小戦略の開始により、マシンモデル、人々のグループ、および環境に基づいて戦略を発行することで、より良い結果が達成されます。

Androidの勉強メモ

Android パフォーマンス最適化の記事: https://qr18.cn/FVlo89
Android Framework の基本原則の記事: https://qr18.cn/AQpN4J
Android 車両の記事: https://qr18.cn/F05ZCM
Android リバースセキュリティ研究ノート: https://qr18.cn/CQ5TcL
Android オーディオとビデオの記事: https://qr18.cn/Ei3VPD
Jetpack ファミリーバケットの記事 (Compose を含む): https://qr18.cn/A0gajp
OkHttp ソースコード分析のメモ: https://qr18.cn/Cw0pBD
Kotlin の記事: https://qr18.cn/CdjtAF
Gradle の記事: https://qr18.cn/DzrmMB
Flutter の記事: https://qr18.cn/DIvKma
Android の 8 つの知識体系: https://qr18.cn/CyxarU
Android コアノート:https://qr21.cn/CaZQLo
過去の Android 面接の質問: https://qr18.cn/CKV8OZ
2023 年の最新の Android 面接の質問: https://qr18.cn/CgxrRy
Android 車両開発職の面接演習:https://qr18.cn/FTlyCJ
音声およびビデオの面接の質問:https://qr18.cn/AcV6Ap