この記事はCommune Advent Calendar 2024シリーズ2、18日目の記事です。QAチームの三木が担当します。
https://qiita.com/advent-calendar/2024/commune
コミューンにはモバイルアプリがあり、Flutterで開発されています。 私は普段モバイルアプリのQAを担当しており、今回はアプリエンジニアの方と協力してモバイルアプリの性能測定に取り組んだので、そのことについて共有します。
背景
ある時期のOKRで、「当たり前の品質を担保するために、パフォーマンス面での異常を検知できる体制を作る」という目標が掲げられました。その一環として、今回の性能測定を実施しました。
異常検知のタイミングは、リリース前かリリース後かによってアプローチが異なります。 今回は「リリース前に性能面で問題のあるアプリのリリースを未然に防ぐこと」を目的に、現状の性能把握と今後の運用方法を検討しました。
やったこと
- 現在の性能を確認
- 性能指標の選定
- Flutter DevToolsで測定可能な指標の調査
- 具体的な測定方法の確立
- 性能確認のスコープ決め（対象機能の選定）
- 測定・基準値の設定
- 運用について検討
1. 現在の性能を確認
a. 性能指標の選定
アプリエンジニアの方に、モバイルアプリで一般的に確認される性能指標をリストアップしていただきました。
主に、デバイスリソース関連の指標（CPU使用率、メモリ使用量など）と処理時間関連の指標（フレームレートなど）を対象としました。
b. Flutter DevToolsで測定可能な指標の調査
Flutter開発のデファクトスタンダードであるFlutter DevToolsを使用することにしました。 リリースに近い状態で測定するため、Profileモードでビルドし、iOSおよびAndroidの実機で測定しました。
まず、選定した指標をFlutter DevToolsで測定可能か調査し、公式ドキュメント *1 を参照しながらツールを動かしました。その過程で、ツール内の各要素や目盛りの意味を確認し、測定方法をドキュメント化しました。
c. 具体的な測定方法の確立
Flutter DevToolsでは測定可能な指標が多くありましたが、一部測定が難しいものもありました。
調査の結果、XcodeのInstruments*2 やAndroid StudioのProfiler*3 を使用することでスムーズに測定できる場合もあると分かり、必要に応じてこれらのツールも活用しました。
また、実際の測定時に「どの操作でどの指標を見るか」を事前に定義しました。
例：
- アプリ起動時 → 〇〇と✗✗を確認
- 画面遷移時 → △△を確認
d. 性能確認のスコープ決め（対象機能の選定）
全機能の性能を確認するのは現実的ではないため、以下の基準でスコープを設定しました。
- 対象
- 社内で定義されている重要な機能
- アクセス数の多い画面
- 対象外
- 性能リスクの把握が価値に直結しない機能や画面
- 抜本的な改修が必要な箇所など、性能向上の優先度が低いもの
また、サポートページで明記されているファイルサイズや個数の上限値での確認も対象にしました。
e. 測定・基準値の設定
エンジニアやQAマネージャーの方にも情報を提供いただき、以下のようなページを参考に各指標で目指すべき数値を検討しました。
このタイミングで一度測定を実施し、一般的な数値と実際に測定した結果の数値を比較しながら、最終的に「この基準値を超えると異常と判断するライン」を設定しました。
2. 運用について検討
一通り実施した結果、手動での測定にはコストがかかると感じました。
また、以下の点も踏まえてQAがリリース時に毎回測定する運用にはしないことを決めました。
- 一度測定して基準値付近であることが確認できた
- 別の取り組みで、Datadogというモニタリングツールを使っており、リリース後の性能指標はモニタリングできる
現在、以下の場合は性能を手動確認し、基準と大きな差がないか確認する運用としています。
- Datadogで異常が検知された場合
- 性能に影響を与える可能性がある修正やアップデート、大きな機能開発があった場合
学んだこと
1. お互いの役割を認識して進める
今回、アプリエンジニアと協力しながら進めましたが、初めは「エンジニアの方が詳しい内容」を自分でも調べようとして時間を使いすぎる場面がありました。
時間は有限であるため、得意分野を活かしながら苦手分野を補い合うことが重要だと感じました。 途中からはこの点を意識できたので、スムーズに進めることができました。 （例えば「対象機能の選定」はQAの方が広く把握しているので、選定に必要な情報を提示できる、など）
2. 初期段階で運用面に悩みすぎない
最初から「定期的に性能テストを実施する前提」で考えすぎて、タイミングやテストの範囲について悩んでしまったことがありました。
初めての取り組みではやってみないと分からないことが多いため、まず測定を進め、後で見直す方がスムーズだと学びました。
3. 問題点を整理しながら進める
ツールの使い方や指標の情報収集中に次々と新しい疑問が出てくることがありました。
調べる目的を明確にし、必要な情報を整理してから調べ始めることで不要な脱線が減り効率的だと感じています。
おわりに
今回はモバイルアプリの性能測定とその運用について検討した話について、一例を紹介させていただきました。性能測定の計画や運用について検討している方の参考になれば幸いです。
Communeでは、私たちと一緒に働く仲間を募集しています！少しでもコミューンの開発組織や職場環境に興味をお持ちの方、ぜひカジュアル面談でお話ししましょう。
*1:https://docs.flutter.dev/tools/devtools
*2:https://developer.apple.com/tutorials/instruments
*3:https://developer.android.com/studio/profile/inspect-app-live
*4:https://www.datadoghq.com/ja/blog/mobile-monitoring-best-practices/
*5:https://www.browserstack.com/docs/app-performance/app-performance-guides/perf-metrics-list
*6:https://developer.android.com/topic/performance/vitals/launch-time?hl=ja#warm
*7:https://android-developers-jp.googleblog.com/2021/12/improving-app-startup-facebook-app.html
