Android(Go バージョン)向けに最適化する
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Android(Go バージョン)のユーザーベースは急速に拡大しているため、このような低 RAM デバイスでのパフォーマンスを高めるために既存のアプリを最適化する必要があります。この種の開発に関する最も一般的な課題として、アプリの機能を制限する必要性、起動時間を短縮する必要性、アプリ内でのメモリ負荷に対処する必要性などがあります。そのような場合に、アプリを Android(Go バージョン)向けに最適化することが役立ちます。
アプローチ
アプリ最適化のアプローチを開始する前に、以下の手順を行います。このガイダンスは、改善の余地がある領域を特定し、その領域を解決する方法のベースラインを確立するのに役立ちます。
段階 |
説明 |
定義 |
最適化を開始する前に、アプリで対象としている改善領域に関しての重要業績評価指標(KPI)を定義することが重要です。一般的な改善領域としては、アプリの起動レイテンシ、アプリのクラッシュ発生率、アプリケーション応答なし(ANR)などがあります。
これらの KPI を定義したら、最小限のユーザー エクスペリエンスとベンチマークの観点から目標のしきい値を設定して、ユーザー エクスペリエンスと技術的な複雑さのバランスを取ります。
|
分割 |
これらの改善領域を個別のシグナル指標に分割することを推奨します。たとえば、アプリのクラッシュ発生率は、未処理のエラー、高メモリ使用量、ANR など、クラッシュの理由ごとに細かく分類できます。 |
ベンチマーク |
次に、目標とする改善領域のベンチマークを作成して現在のパフォーマンスを特定できます。目標が達成されていない場合は、個々の内訳を調べてボトルネックを特定します。 |
プロセスの繰り返し |
特定のボトルネックを最適化した後、ベンチマーク プロセスを繰り返して、改善の可能性を確認します。事前定義された KPI 目標を満たしていない場合は、プロセスを 2 回目の反復で繰り返すことができます。 |
定期的な回帰テストを追加する |
定期的な回帰テストでは、KPI に対する回帰を特定するために必要となる任意の頻度でテストを実行できます。回帰やバグを、コードベースに侵入する前に特定して排除する方が効率的です。KPI 目標を更新することにした場合を除き、KPI 目標を満たさない変更を公開しないでください。 |
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-27 UTC。"],[],[],null,["# Optimize for Android (Go edition)\n\nAndroid (Go edition) has a rapidly growing user base, and with that comes the\nneed to optimize existing applications to perform well on these low-RAM devices.\nSome of the most common challenges around this type of development requires\nlimiting some app features or capabilities, improving startup time, and handling\nmemory pressure within your app. That's where optimizing your app for Android\n(Go edition) can help.\n\nApproach\n--------\n\nFollow the steps below before beginning your app optimization approach. This\nguidance helps establish a baseline for identifying potential areas for\nimprovement and how to resolve your findings.\n\n| Phases | Description |\n|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Define | Before starting any optimization effort, it's important to define Key Performance Indicators (KPIs) around areas of improvement that you're targeting for your app. Some common improvement areas include app startup latency, app crash rate, or application not responding (ANRs). \u003cbr /\u003e Once these KPIs have been defined, you should establish target thresholds from a minimum user experience and benchmarking perspective, balancing user experience and technical complexity. |\n| Breakdown | It's recommended to break these improvement areas into individual signal metrics. For example, app crash rates can be categorized granularly into reasons for the crash --- such as unhandled errors, high memory usage, or ANRs. |\n| Benchmark | Next, you can benchmark the targeted improvement area to identify current performance. If your targets aren't met, try to identify the bottlenecks by looking at individual breakdowns. |\n| Repeat the process | After optimizing certain bottlenecks, repeat the benchmarking process to view potential improvements. If your pre-defined KPI targets aren't met, then you can repeat the process for a second iteration. |\n| Add regular regression tests | Regular regression tests can run at any frequency you desire for your app to identify regressions against your KPIs. It's more efficient to identify and cut off any regressions or bugs before they make their way into your codebase. Don't publish any changes that fail your KPI goals unless you make the decision to update your KPI targets. |"]]