史上最も完全な Android パフォーマンス最適化ソリューションの分析

Android でのパフォーマンスの最適化は、次の側面に分けられます。

レイアウトの最適化

ネットワークの最適化

インストール パッケージの最適化

メモリの最適化

カトン最適化

最適化を開始

……

1. レイアウトの最適化

レイアウト最適化の本質は、View の階層を減らすことです。一般的なレイアウト最適化スキームは次のとおりです。

• LinearLayout と RelativeLayout の両方がレイアウトを完成できる場合は、LinearLayout が優先され、View のレベルを下げることができますが、同じコンポーネントが RelativeLayout を描画するのに時間がかかる場合があることに注意してください。

• <include> タグを使用して、よく使用されるレイアウト コンポーネントの共通部分を抽出して再利用します。

• < ViewStub > タグを使用して未使用のレイアウトを読み込み、遅延読み込み (必要に応じてアクティビティに読み込まれます)

• < Merge > タグを使用してレイアウトのネスト レベルを減らす

2. 図面の最適化

描画の最適化とは、View の onDraw メソッドが多数の操作を実行することを避ける必要があることを意味します。これは、主に次の 2 つの側面に反映されます。

1. onDraw で新しいローカル オブジェクトを作成しないでください。

onDraw メソッドは頻繁に呼び出される可能性があるため、大量の一時オブジェクトが瞬時に生成され、大量のメモリを消費するだけでなく、システムがより頻繁に gc を実行し、プログラムの実行効率が低下します。

2. onDraw メソッドで時間のかかるタスクを実行しないでください。

何千ものループ操作を実行することはできません. 各ループは非常に軽量ですが、多数のループが CPU タイム スライスを占有するため、ビューの描画プロセスがスムーズではなくなります。

Google が公式に示したパフォーマンス最適化モデルの基準によると、View の描画周波数は 60fps が最適であることが保証されており、これには、各フレームの描画時間が 16ms (16ms = 1000/60) を超えないようにする必要がありますが、プログラムが 16ms の時間を保証することは困難ですが、onDraw メソッドの複雑さを最小限に抑えることは常に実用的です。

3. ネットワークの最適化

一般的なネットワーク最適化スキームは次のとおりです。

• ネットワーク リクエストを最小限に抑え、可能な限りマージする

• DNS 解決を回避します。ドメイン名のクエリには数百ミリ秒かかる場合があり、DNS ハイジャックのリスクがある場合があります。ビジネスのニーズに応じて動的 IP 更新を追加する方法を使用するか、IP 方式のアクセスが失敗したときにドメイン名アクセス方式に切り替えることができます。

• 大量のデータがページング方式で読み込まれる

• ネットワークデータ転送はGZIP圧縮を採用

• ネットワーク データのキャッシュに参加して、頻繁なネットワーク リクエストを回避する

• 写真をアップロードするときは、必要に応じて写真を圧縮します

4. インストール パッケージの最適化

• インストール パッケージの最適化の核心は、apk のサイズを縮小することです。一般的な解決策は次のとおりです。

• 写真などのアプリケーション内の不要なリソース ファイルを減らし、特定の効果がある APP の効果に影響を与えずに写真を可能な限り圧縮します。

• SO ライブラリを使用する場合は、最初に SO ライブラリの v7 バージョンを保持し、他のバージョンの SO ライブラリを削除します。その理由は、2018 年には v7 バージョンの SO ライブラリが市場の要件のほとんどを満たすことができるためです.8、9 年前の携帯電話では不可能かもしれませんが、時代遅れの携帯電話に適応する必要はありません。 . 実際の開発でapkボリュームを削減する効果は非常に大きく、例えばSOライブラリのバージョンが合計10Mの場合、多くのSOライブラリを使用する場合は、v7バージョンのみを保持し、armeabiとv8を削除しますSO ライブラリのバージョン、合計で 20M ボリュームを削減できます。

• res リソースの最適化

  (1) 写真は 1 セットのみ使用し、高解像度の写真を使用してください。

  (2) UI 設計 ps に TinyPNG プラグインをインストールして、写真を無損失で圧縮します。

  (3) svg 画像: 一部の画像の記述は、スペースを節約するために CPU の計算能力を犠牲にします。使用される原則: シンプルなアイコン。

  (4) 画像は WebP (https://developers.google.com/speed/webp/) 形式を使用しています (Facebook、Tencent、Taobao が使用しています)。 短所: PNG より読み込みが非常に遅い。しかし、構成は比較的高いです。ツール: http://isparta.github.io/

  (5) tintcolor (android - プログラムで描画可能な色を変更) を使用して、ボタンの反転効果を実現します。

• コードの最適化

  (1) 機能モジュールのロジック簡素化を実現

  (2) Lint ツールは不要なファイルをチェックし、「UnusedResources: 未使用のリソース」に不要なリソースを一覧表示して削除します。

  (3) 不要な依存ライブラリを削除します。

• lib リソースの最適化

  (1) 動的にダウンロードされたリソース。

  (2) 一部のモジュールのプラグインが動的に追加されます。

  (3) so ファイルのクリッピングと圧縮。

• アセット リソースの最適化

  (1) opus、mp3 などのオーディオ ファイルには非可逆圧縮形式を使用することをお勧めしますが、可逆圧縮音楽形式は使用しないことをお勧めします。

  (2) ttf フォント ファイルを圧縮するには、FontCreator ツールを使用して、必要なテキストのみを抽出します。例えば、日付表示を行う場合はデジタルフォントのみでよいのですが、独自のフォントライブラリを使用すると10MB程度の容量が必要になる場合があり、必要なフォントだけを抽出すると10KB程度のフォントファイルしか生成されません。

• コードの難読化。

• 縮小、最適化、難読化などを含む proGuard コード難読化ツールを使用します。

• プラグイン

• 機能モジュールをサーバーに配置し、必要に応じてロードできます。

• 7z エクストリーム コンプレッション

5. Android メモリの最適化

1. Android のメモリ管理メカニズム

Android アプリケーションは Android 仮想マシン上で実行され、メモリ割り当てとガベージ コレクションは Android 仮想マシンによって実行されます。

2. 一般的なメモリ リーク

実際、メモリ リークの本質は、ライフ サイクルの長いオブジェクトがライフ サイクルの短いオブジェクトを参照することです。

2.1 メモリリーク

メモリ リークの原因: ヒープに割り当てられたオブジェクトは使用されなくなりますが、GC コレクターはそれをリサイクルできず、このオブジェクトは強力なアプリケーションによって参照されます。

• 静的変数が原因のメモリ リーク

  解決策: 内部クラスを静的内部クラスとして設定するか、分離して、context.getApplicationContext() を使用します。

• シングルトン モードによるメモリ リーク

  解決策: パラメータ context.getApplicationContext() を渡します。

• プロパティ アニメーションによるメモリ リーク

  解決策: Activity.onDestroy() で Animator.cancel() を呼び出して、アニメーションを停止します。

• Handler によるメモリリーク

  解決策: 静的内部クラス + WeakReference 弱参照を使用し、外部クラスがそのライフ サイクルを終了するときにメッセージ キューをクリアします。

• スレッドが原因のメモリ リーク

  解決策: AsyncTask と Runnable を静的な内部クラスとして設定するか、それらを分離します。弱参照を使用して、コンテキスト参照をスレッド内に保存します。

• 閉じられていないリソースによるメモリ リーク

  解決策: アクティビティが破棄されたら、時間内に閉じるかログオフします。例えば：

  ① BroadcastReceiver: unregisterReceiver() を呼び出してログアウトします。

  ②カーソル、ストリーム、ファイル：close()で閉じる。

  ③ビットマップ: recycle() を呼び出してメモリを解放します (バージョン 2.3 以降は手動で行う必要はありません)。

• アダプタが原因のメモリ リーク

  詳細: キャッシュを使用して getView() のみに依存してアイテムを毎回再インスタンス化する代わりに、gc に圧力をかけます。

  解決策: Adapter を作成するときに、キャッシュされた convertView を使用します。

• WebView によるメモリ リーク。

  詳細: WebView は特殊で、destroy メソッドが呼び出されてもメモリ リークが発生します。

  解決策: 実際には、WebView によって引き起こされるメモリ リークを回避する最善の方法は、WebView が配置されているアクティビティを別のプロセスに作成することです. このアクティビティが終了したら、WebView が配置されている現在のプロセスを強制終了します. Ali Dingding の WebView はは別のプロセスです。開いているプロセスも、このメソッドを使用してメモリ リークを回避する必要があります。

• コレクションクラスのリーク

  詳細: たとえば、グローバル マップなどの静的アプリケーションがありますが、それらは最終的に削除されません。

  解決策: onDestry 中に不要なコレクションをリサイクルします。

2.2 メモリを拡張する

大手メーカーの SDK はメモリ リークが少ない可能性がありますが、一部の小規模メーカーの SDK の品質は信頼性が低くなります。変えることのできないこの状況に対処する最善の方法は、メモリを拡張することです。

通常、メモリを拡張するには次の 2 つの方法があります。

• 1 つは、マニフェスト ファイルの Application の下に属性 largeHeap="true" を追加することです。もう 1 つは、同じアプリケーションに対して複数のプロセスを開いて、アプリケーションの合計メモリ領域を拡張することです。

• 2 番目の方法は、実際には非常に一般的で、たとえば、私は Getui の SDK を使用しましたが、Getui の Service は実際には別の別のプロセスにあります。

• Android でのメモリの最適化は、一般的にオープン ソースとスロットリングです. オープンソースとはメモリを拡張することであり、スロットリングとはメモリ リークを回避することです.

2.3 メモリ リークを検出および分析するためのツール

• MemoryMonitor: 経時的なメモリ使用量の変化

• MAT: 入力 HRPOF ファイル、出力解析結果

• a. ヒストグラム: さまざまな種類のオブジェクトとそのサイズを表示します

• b.DominateTree: オブジェクトが占有するメモリとその参照関係

• c.MAT チュートリアル

• LeakCanary: メモリ リークをリアルタイムで監視するためのライブラリ (LeakCanary 原則)

6.カトン最適化計画

• メイン スレッドで大きなファイルに対してネットワーク アクセス/IO 操作を実行しない

• UI を描画するときは、UI の描画レベルを下げるようにしてください; 不要なビューのネストを減らしてください, 階層ビューアー ツールを使用してそれを検出できます.これについては後で詳しく説明します.

• レイアウトで FrameLayout を使用している場合は、それをマージするように変更できます。これにより、独自のフレーム レイアウトとシステムの ContentFrameLayout フレーム レイアウト (メジャーとレイアウト) の間で計算が重複することを回避できます。

• 表示速度を向上させるには、ViewStub を使用します。これは、読み込み時にのみ占有されます。ロードされていないときは非表示になり、スペースを占有するだけです。

• 同じビュー レベルの場合は、RelativeLayout の代わりに LinerLayout を使用してみると、RelativeLayout は 2 回測定し、LinerLayout は 1 回測定するため、ソース コードが表示されます。

• コントロール内の不要なプロパティを削除します。

• レイアウトの再利用. たとえば、listView レイアウトの再利用

• オーバードロー (overdraw) を避けるようにしてください。たとえば、背景はオーバードローを引き起こしやすいことがよくあります。レイアウトで背景が設定されているため、同時に使用される MaterialDesign テーマはデフォルトで背景になります。この時点で、テーマによって追加された背景を削除する必要があります。

• XML のオプションの背景

• カスタム ビューの最適化。canvas.clipRect() を使用して、システムがこれらの可視領域を識別できるようにします。この領域内のみが描画されます。また、過度の描画は避けてください。

• 起動の最適化、起動速度の監視、起動速度に影響する問題の発見、起動ロジックの最適化、およびアプリケーションの起動速度の改善。たとえば、スプラッシュ スクリーン ページ、合理的なレイアウトの最適化、ロード ロジックの最適化、データの準備などです。

• 妥当なリフレッシュ メカニズム、リフレッシュの回数を最小限に抑える、バックグラウンドで CPU 使用率の高いスレッドが実行されるのを回避する、およびリフレッシュ領域を減らす。

7. 消費電力の最適化

電力消費には実際には多くの理由があります. ここでは、いくつかの最適化スキームについて説明します. 最適化スキームの反対が理由です. いくつかの最適化スキームは次のとおりです:

• wake_lock ロックの合理的な使用、wake_lock ロックは主にシステムのスリープに関連しています (ここでは電力を節約するため、それが行われます)、つまり、私のプログラムはこのロックを CPU に追加し、システムはスリープしません。目的は、私たちのプログラムの運営に全面的に協力することです。場合によっては、これを行わないと、画面がオフになった直後に WeChat やその他のインスタント メッセージングのハートビート パケットがネットワーク アクセスを停止するなどの問題が発生します。したがって、WeChat で使用される wake_lock ロックが多数あります。

• jobScheduler2 を使用して一部のネットワーク要求を集中的に処理します。画像処理、APP のダウンロードと更新など、適時に処理する必要のないものは充電中に処理できます。

• 計算の最適化、浮動小数点演算の回避など。

• データがネットワーク上で送信される場合、送信前にデータを圧縮してみてください. JSON よりも何倍も効率的な FlatBuffer シリアル化テクノロジを使用することをお勧めします. FlatBuffer を知らない場合は、情報を検索して学習することをお勧めします. .

「パフォーマンスの最適化」の重要なポイントを目指して、「360° All-round Android Performance Optimization Analysis」を皆さんと共有したいと思います.この学習マニュアルでは、Android のパフォーマンスの最適化を段階的に探ることができます。製品の性能はあらゆる面で向上させることができます. , 気に入っていただければ幸いです.
このドキュメントは合計 721 ページ、4 つの主要なポイント、および 25 の小さな章で構成されており、基礎となる原則の詳細な分析だけでなく、特別な実践例も含まれています。

「360° オールラウンド Android パフォーマンス最適化の分析」

第 1 章 設計のアイデアとコード品質の最適化

1. 六原則

• 単一責任の原則

• リスコフ置換原理

• 依存性逆転の原則

• インターフェース分離の原則

• ……

2. デザインパターン

• 構造モード: ブリッジ モード、アダプタ モード、デコレータ モード、プロキシ モード、ファサード (外観) モード...

• 作成パターン: ビルダー パターン、シングルトン パターン、抽象ファクトリ パターン、ファクトリ メソッド パターン...

• データ構造: 配列、スタック、キュー、リンク リスト、ツリー...

• アルゴリズム: ソートアルゴリズム、検索アルゴリズム...

第 2 章 プログラムのパフォーマンスの最適化

1. 起動速度と実行効率の最適化

• コールドスタートとホットスタートの分析

• アプリの起動時の白黒画面の解決策

• アプリのフリーズ問題の分析と解決策

• 起動速度と実行効率を最適化する StrictMode

• ……

2.レイアウトの検出と最適化

• レイアウト レベルの最適化

• オーバーレンダリング

• ……

3. メモリの最適化

• メモリのスラッシングとメモリ リーク

• 大きな記憶

• ビットマップ メモリの最適化

• プロファイル メモリ監視ツール

• 大型オブジェクトのマットと漏れ検出

• 消費電力の最適化

• ネットワーク伝送とデータストレージの最適化 ネットワーク伝送とデータストレージの最適化

• APK サイズの最適化

• 画面適応

• ……

4. 消費電力の最適化

• Doze&Standby

• バッテリー歴史家

• ジョブスケジューラ

• ワークマネージャー

5. ネットワーク伝送とデータストレージの最適化

• Google シリアル化ツール protobuf

• 7z エクストリーム コンプレッション

• ……

6. APK サイズの最適化

• APK痩身

• WeChat リソース混同の原則

• ……

7. 画面適応

• 適応の原則

• 画面解像度修飾子と leastWidth 修飾子の適応原理

• 適応のために leastWidth 修飾子を選択する理由

• 他のモジュールへの適応方法

• よくある質問

  ……

8. OOM問題原理の分析

• adj メモリ管理メカニズム

• JVM メモリ リサイクル メカニズムと GC アルゴリズム分析

• ライフサイクル関連の問題のまとめ

• ビットマップ圧縮方式のまとめ

• ……

9. ANR の問題分析

• AMS システム時刻調整の原則

• 番組待ち原理の分析

• ANR の問題解決

• ……

10. 衝突監視ソリューション

• Java レイヤー監視ソリューション

• ネイティブ層監視ソリューション

• ……

第3章 開発効率の最適化

1. 分散バージョン管理システム Git

シナリオ Enterprise Efficient Continuous Integration Platform の導入

GIT 分散バージョン管理システム

• GIT ブランチ管理

• ……

2. 自動ビルドシステム Gradle:

• Gradle と Android プラグイン: gradle と android gradle プラグインの関係、Gradle Transform API の基本的な使い方...

• Gradle Transform API の基本的な使い方: Transform とは何か、Transform の使用シナリオ、Transform API の学習、入力の種類...

• カスタムプラグイン開発: Gradle プラグインの紹介、準備、実践、カスタム Gradle プラグイン、buildSrc モジュールメソッド...

• プラグイン戦闘: マルチチャンネル パッケージング、自動バージョン リリース...

第 4 章 APP パフォーマンス最適化の実践

1.起動速度

• アプリ起動の大まかな流れ

• コールドスタートとウォームスタート

• 起動速度の測定

• ウィンドウの最適化を開始

• スレッドの最適化

• システム スケジューリングの最適化

• GC の最適化

• I/O の最適化

• リソースの再配置

• ホームページのレイアウトの最適化

• クラスローディングの最適化

• 適切なスタートアップ フレームワークを選択する

• アクティビティのジャンプレベルを下げる

• ベンダーの最適化

• バックグラウンドキープアライブ

• ……

• 2.流暢さ

• パフォーマンスの問題を分析するためのツールとルーチン

• パフォーマンスデータによるデータ分析

• Android プラットフォームのパフォーマンスに起因するパフォーマンス ケース

• Android アプリ自体に起因するパフォーマンスの問題

• 低メモリのデータおよび動作特性

• アプリの宝物

• Xunfei入力方式のバリアフリーサービスによるマシン全体のフリーズ解析

• バイトダンス: 今日の Toutiao のグラフィックとテキストの詳細ページが数秒で開きます

• ……

• 3. APK パッケージサイズのリソース最適化における Douyin の実践

• 画像圧縮

• webp 非侵入型互換性

• マルチ DPI 最適化

• 重複リソース統合

• ShrinkResource 厳密モード

• リソースの混乱 (aab モードと互換性あり)

• ARSC痩身

• ……

• 4. Youku レスポンシブ レイアウト テクノロジーの完全な分析

• Youku APP レスポンシブ レイアウト テクノロジーの概要

• Youku APP レスポンシブ レイアウト Android ランディング

• 配信シーンに上陸

• 消費シーンへの着地

• Youku APP レスポンシブ レイアウト テスト スキーム

• ……

• 5. ネットワークの最適化

• ネットワーク内のモバイル淘宝網の最適化

• ディープ ネットワーク最適化における Baidu APP の実践

• ……

• 6. モバイル タオバオのダブル イレブン パフォーマンス最適化プロジェクトの秘密を明らかにする

• 1秒ルールの実現

• 起動時間とページ フレーム レートが 20% 増加

• Android スマートフォンのメモリを 50% 節約

• ……

• 7. AutoNavi APP フル リンクのソース コードの依存関係の分析

• Gaode APP プラットフォーム アーキテクチャ

• 実現の基本原理

• プロジェクト構造

• アプリケーションのシナリオと実装の原則

• ……

• 8. OOM を完全に殺す実際の経験を共有する

• メモリ リークのトラブルシューティング

• 収益戦略

• メモリのピークが高すぎる

• 特大画像のトラブルシューティングと最適化

• ……

• 9. WeChat Android 端末メモリ最適化の実践

• アクティビティリークの検出

• ビットマップの割り当てと割り当て解除の追跡

• ネイティブ メモリ リーク検出

• スレッド監視

• メモリーモニター

• ……

要約する

パフォーマンスの最適化は、1 つまたは 2 つのバージョンを更新するだけでは解決できません. これは、継続的な要件、継続的な統合、および反復的なフィードバックです. 実際のプロジェクトでは、プロジェクトの開始時は、人員とプロジェクトの完了時間の制約により、パフォーマンスの最適化の優先度は比較的低く、プロジェクトが使用されるようになると、優先度を上げる必要があります。 、パフォーマンスの最適化ポイントも早期に考慮する必要があります。これは、プログラマーの技術的スキルを反映しています。この「360° オールラウンド Android パフォーマンス最適化分析」がお役に立てば幸いです。

この記事の情報は、以下の CSDN 公式認定カードをスキャンすることで無料でスキャンできます。