見出し画像

Appleの公式ドキュメント「Improving Your App's Performance」の紹介

はじめに

以前、Appleの公式ドキュメントから次を紹介しました。

今回は数あるAppleの公式ドキュメントの中からパフォーマンスに関するドキュメントについて紹介したいと思います。

パフォーマンス周りについては昨今Appleが力を入れているであろうものの1つと思っています。

近年、XCTestにもパフォーマンス計測に関するAPIが追加され続けています。 また、XcodeのメトリクスオーガナイザーにMetrics周りの情報も追加されています。

私も、パフォーマンス計測周りについてまとめた次のような登壇もしました。 今回紹介する記事も参考にして用意した資料なので、併せて読んでもらえるとより分かりやすくなるかもしれません。


また、WWDC 2020では次のようにパフォーマンス周りでまとめられた動画も公開されています。

今回紹介する記事

今回は、パフォーマンスに関するAppleのドキュメントの中で最初に読むべき資料として、「Improving Your App's Performance」について紹介をしていきます。

この公式ドキュメントの内容としては次のような感じです。

- Overview
- Gather Data About Your App's Current Performance
- Determine the Most Important Aspect to Improve
- Profile Your App
- Make the Next Change
- Compare the Changed Behavior with Your Original Data

本稿では、これらの内容について書かれている内容を少し紹介しつつ、私からの補足情報を追加していきます。
※ 記事の内容(の一部)は引用扱いとして、私の補足は通常の書体で書くこととします。

Overview

ここではパフォーマンスの重要性とどのように改善するか、改善することによるメリットについて書かれています。

アプリによっては「起動に時間がかかる」「操作の反応が遅い」「大量にネットワークアクセスがありデータの使用量が多い」といったものがあります。

これらがあると、ユーザーをイライラさせて、アプリをアンインストールさせてしまうかもしれません。

このような問題に対して、パフォーマンスの改善を次のようなサイクルでおこなっていきます。

- 問題を把握するために情報を収集する
- 問題の原因を見つけるためにアプリの動作を測定する
- 問題を改善するための変更を計画する
- 変更を実際におこなう
- パフォーマンスがよくなったかをチェックする

パフォーマンスに限らずアプリの現状を把握することが大事です。

しかし、かんたんに取れる指標(例えばアプリのファイルサイズ)と違って、アプリのパフォーマンスは把握することがたいへんです。

Appleでは把握するためのツールなどを提供してくれていて、それらについては後述します。

しかし、これらがあれば解決というわけではなく実際に問題を手元で再現できることが重要です。

手元で(軽く)動作確認をしている場合はパフォーマンスの問題は見つからず、問題なく動いているというケースも多くあります。

また、ここで述べたサイクルはパフォーマンスが問題になったとき「だけ」におこなうのではなく継続的におこなうことが重要です。


改善することによって得られるメリットとしては次のようなものがあります。

- アプリの起動時間が短縮するとユーザ体験が向上し、iOS Watchdog Timerによってアプリが終了される可能性が低くなる

- 全体的なメモリ使用量を減らすことで、iOSがバックグラウンドでアプリのメモリを開放する可能性が減り、ユーザーがアプリに戻ったときの応答性が向上します

- ディスクの書き込みを減らすと、アプリの全体的なパフォーマンスが良くなり、ユーザーのデバイスストレージの消耗が軽減します

- ハングする割合や時間を減らすと、アプリの応答性がよくなります


次から、ここで述べた改善のサイクルをまわすためにおこなうそれぞれの行為についての内容を説明していきます。

Gather Data About Your App's Current Performance

アプリのパフォーマンスを知るための方法について紹介をしています。

アプリのパフォーマンスを徹底的に理解するには、次のような複数のリソースからの情報を活用します。

- Metrics organizer in Xcode
MetricKit
TestFlight
一般ユーザー

それぞれについて次に説明をしていきます。

Metrics organizer in Xcode

メトリクスオーガナイザーを使用して、「起動時間」「ハングレート」「ストレージの書き込み」「メモリ使用量」「エネルギー消費量」のメトリクスを表示してくれます。

オーガナイザーでは、デバイスのモデルとアプリのバージョン毎に測定値を見ることができます。

Xcodeのメニューにある「Window > Organizer」からメトリクスオーガナイザーを起動することができます。

ここにある情報を取得してくれるOSSもあります。


MetricKit

MetricKitを使ってメトリクスを収集し、独自のツールに記録します。

これらのメトリクス情報は1日の間に観察された値の頻度を記録するヒストグラムの形をしています。

MetricKitはメトリクスオーガナイザに表示されるメトリクスだけでなく、平均ピクセル輝度、ネットワークの状態、アプリ内に実装したOSSignpost イベント(mxSignPost)に関連付けられた持続時間なども含めることができます。

MetricKitのAPIは次のとおりです。

MetricKitはまだ情報が少ないですが、WWDC 2020で↓のような動画も公開されています。


TestFlight

TestFligtのテスターから、アプリのベータ版を使用してもらった際のフィードバックを得ることができます。

ベータ版のテスト情報ページに必要事項を記入し、テスターにアプリのパフォーマンスに関するフィードバックを提供するように依頼します。

そして、テスターが発見したこを報告できるように、Eメールアドレスを記入しておきます。

TestFlightに限らず、アプリ配信サービスを利用して触ってもらった際のフィードバックは重要です。

ただしこれらは、定量的な話ではなく定性的なフィードバックになります。

そのため、フィードバックされたユーザーのログなどを確認できるようにしておき、定量的な情報として確認できるようにしておくことも重要です。

一般ユーザー

リリースされたバージョンのアプリでユーザーからのフィードバックを調査します。

メールまたはアプリ内の専用インターフェースを使って、フィードバックを送信するようにユーザーに伝えます。

なにがうまくいったのか、なにが問題があったのかなどをアプリを使ってみての感想を聞いてみましょう。


今回紹介しているのは、実際にアプリを利用したユーザーからの情報がメインとなっています。

これらの以外にも「HeadSpin」などパフォーマンス計測をすることができるサービスもあります。
それらを活用するのも1つの手だと思います。


Determine the Most Important Aspect to Improve

改善すべきもっとも大事な箇所を決めます。

複数の情報源からえられた情報をもとに対象となるアプリの目的とユースケースを理解した上で、改善をおこなうためのポイントを見つけます。

パフォーマンスの問題の中には、対象とするアプリの種類に関係なくすべてにおいて対応したほうがいいものもあります。

たとえば、「起動に時間がかかったり」「ユーザーがアプリを操作しようとしても反応がない」といったアプリは、ユーザーにとっていいものではありません。

どのようなアプリにおいても問題と判断できるポイントもありますが、アプリのユースケースによって見るべきポイントも変わってきます。

「ooという指標が高いから問題」というわけではなくて、「ooという指標が高くなるようなユースケースがこのアプリにはないので問題」となります。

メトリクスオーガナイザやMetricKitに表示されるメトリクスの値が、アプリが期待どおりに使用されていることを示している場合、対処すべき最も重要な問題を示しているとは限りません。

たとえば、バックグラウンドでのオーディオ再生に関連するエネルギー消費は、ユーザがバックグラウンドで再生することを期待しているポッドキャストプレイヤーのアプリでは、問題ないでしょう。

しかし、アプリがバックグラウンドで動作すべき機能を持たないようなゲームの場合、この指標が高いとしたら問題です。

メトリックスレポートでこの指標が高いということは、改善できることを可能性があることを示しています。
これはアプリの主な機能ではない補助サービスの使用である可能性があります。

たとえば、ポッドキャストプレイヤーがリスナーに地元の面白いポッドキャストを推薦するために位置情報を使用していて、これによるエネルギー消費があるのであれば、変更すべき箇所かもしれません。

実際、想定外の箇所でなにかが使われていてそれによってパフォーマンスに影響を与えていたというケースは見たことがあります。

それらを見つけるためにも計測は重要ですし、アプリの目的とユースケースも把握しておくことが大事です。


Profile Your App

馴染みのある方も多い「Instruments」を使ってのプロファイリングの話です。

Instrumentsを使用してアプリをプロファイリングします。

Instrumentsでは複数のテンプレートを用意しています。
それぞれ問題に対して利用すると良いテンプレートは次のような感じです。

- 無反応、ハング:Time Profilerテンプレート
- メモリの問題:AllocationsとLeaksテンプレート
- 消費電力の問題:Energy Logテンプレート
- I/Oの問題:File Activityテンプレート
- ネットワークに関する問題:Networkテンプレート

プロファイリングするときは、Simulatorではなくて、実機でおこないます。これにより正確性の高い測定をすることができます。

Instrumentsも登場したのはだいぶ昔ですが、改善され続けておりいろいろと変わってきています。
パフォーマンス計測をする上では必ずといっていいほど利用するものだと思います。

Instrumentsについては次のWWDC 2019の動画が参考になります。

また、次の記事も参考になります(お世話になりました)。


収集した情報から特定のクラスや特定のモデルの端末でアプリのパフォーマンスが低いことが分かった場合は、そのデバイスでプロファイルを作成します。

パフォーマンスの問題の原因になっているコードをみつけ、それを改善するための計画を作成します。

変更が特定の行やメソッドに限定されず、アプリのアーキテクチャを大幅に変更する必要がある場合もあります。

たとえば、ネットワークリソースを同期的にダウンロードすることで発生するハングを軽減するためには、ネットワークを処理するためのバックグラウンド操作を導入し、ダウンロードが完了したときにメインスレッドでUIアップデートを実行します。

Instrumentsを利用しても、必ずしもかんたんに問題となっている箇所を見つけられるとは限りません。

ユーザー環境によってのみ起こる問題(の一部)は、実際の本番環境のデータ数の多さなどにも起因することもあります。

その点にも考慮しつつ計測をおこなうことが重要です。

Make the Next Change

今までにおこなったことにより分かったことを元に実際に改善策をおこないます。

Instrumentsを使い変更前後の情報を比較して、今回おこなった改善策によってパフォーマンスが改善されたことを確認します。

また、将来的にパフォーマンスが劣化することを防ぐために、XCTestでパフォーマンステストを実装することも検討してください。

改善策をおこなった場合は、実際に改善されたかを確認する必要があります。

今後のパフォーマンス劣化を防ぐ手段(劣化を事前に見つける手段)として、XCTestのパフォーマンステストについて言及をしていますが、これをうまく活用できるかは難しいところです。

XCTestのパフォーマンステストでは、テストコードを複数回実行し、その値が事前に指定した値より悪くなっていればテストは失敗となります(単純な。

実行環境(端末、OS、そして場合によっては接続先のサーバやネットワーク状態などなど)によって値は変わるだけでなく、実行したい環境も状況によって変わってきます。
それらを考慮した上でテストを実装していくことになります。

そういうこともあり、このパフォーマンステストをどこでも導入できるわけではなく、ポイントを絞る必要があると思っています。

Compare the Changed Behavior with Your Original Data

プロファイルしたパフォーマンスの問題の対処をしたあとに、この変更が効果があったかどうか、改善のレベルが求めているレベルだったかを確認する必要があります。

Xcodeのメトリクスオーガナイザーで、アプリの各バージョンの情報を確認し、変更が改善につながったのかどうかを確認できます。

手元で確認した情報だけでなく、すでに説明したXcodeのメトリクスオーガナイザーを使って、ユーザーからの情報も確認しておきます。


さいごに

今回のドキュメントにあるのは、パフォーマンス計測をする上でまず最初に知るべき情報といえます。

実際にどのようにパフォーマンス計測をおこない改善をしていくかに参考になるドキュメントもいろいろと用意されています。

このように用意されているドキュメント以外にも、WWDCのセッションにはXcodeやInstrumentsを使用してアプリのパフォーマンスを計測し、改善するための詳細な情報があります。

まず、このドキュメントを読んだのち、自分たちにとって必要なドキュメントをさらに読んでいくのが良いと思います。

私もドキュメントを読みつつ、実際にプロダクトと向き合い日々試行錯誤していますので、この手の情報をみなさんと共有できればと思います。


この記事が気に入ったらサポートをしてみませんか?