バッテリー駆動時間とパフォーマンスを向上させる

(音楽)

(拍手) ありがとう WWDCへようこそ フィリップ･アーザルです 今日はバッテリーとパフォーマンスの 向上についてお話しします

アプリケーションなくして ユーザが様々な体験を 実現することはできません そのためには― バッテリーとパフォーマンスの 向上が必要不可欠です そこで今日は 皆さんが使用することができる アプリケーション最適化のツールを ご紹介します これらのツールを使って メトリックスを収集し バッテリーとパフォーマンスへの影響を 定量化します アプリケーションでの ツールの使用については いくつかデモを行い 詳しく説明していきます その後 全体のまとめを行います

まず ツールの話をする前に―

開発プロセスについて 理解を深めましょう 開発プロセスには ３つの段階があります まずは開発とテストです ここでは最適なアプリケーションの 提供のために アイデアの観念化と創出を くり返し行います

次はベータ版の公開です アプリケーションの機能を 具体的に決めたら 数名のユーザにテストを 行ってもらいます

アプリケーションが 納得のいく状態になったら リリース版の公開となります App Storeから入手可能となります

どの段階も非常に重要なステップです バグを修正し― 顧客に最善のものを提供するのに 必要な作業です iOS 13とXcode 11の前にも パフォーマンスへの影響を測るツールが 提供されています 開発とテストの段階ではXcode内の Instrumentsなどが役立ちます ベータ版では直接トレースが収集でき Instrumentsで開くことができます これにより 電波が悪い時など 実際の状況で発生する問題に 気付くことができます そしてリリース版で発生した クラッシュなどのログは Organizerで確認できます 特定の地域やユーザで起こり得る― 問題の見極めに役立ちます

我々はここ数年 埋められるギャップがあるのではと 考えてきました 多くの人がギャップであると 話してくれたのは メトリックスでした バッテリーとパフォーマンスを 定量化するには？ ＡとＢの比較後の最終判断は？ 今日はXcode 11とiOS 13の機能として このギャップを埋められる ３つのツールをご紹介します まずはXCTest Metrics Xcode 11に追加される新機能で XCTestから直接メトリックスの 収集が可能になります XCTestで特定の機能による影響を 見極める上で 利点となり得ます

次にMetricKit メトリックスを収集する際の フレームワークです 各ユーザによる アプリケーション使用時の状況を 理解するのに役立ちます 最後にXcodeのOrganizerを強化した Metrics Organizer コードを変更することなく Organizerから 集約されたデータの確認ができます アプリケーションの状態を ハイレベルで確認できるのです

ご紹介したツールは 開発プロセスに うまく適合しています XCTest Metricsは 開発とテスト段階で使います MetricKitで 詳細なメトリックスを ベータ版とリリース版から 収集します

そしてMetrics Organizerを使って リリース版で生じた問題を 確認します

このように各開発段階で 定量化のためのメトリックスが 得られます すばらしいですね

詳細については この後 同僚が説明します その前に影響を測る上で必要な メトリックスについてお話しします タイプは２種類

バッテリーとパフォーマンスです 意外ですか？

バッテリーには― 今年 いくつかのメトリックスが 追加されます

プロセッサ 位置情報 ディスプレイ ネットワーク Bluetoothとアクセサリ マルチメディア そしてカメラ どれも強力なメトリックスですが 重要なものだけ紹介します まずはプロセッサ これはCPUやGPUのメトリックスで アプリケーションの負荷を 定量化できます 例えば 特定地域での CPU処理時間などです 想定外のレンダリングも確認が可能です このメトリックスは バッテリーの消耗を比較する時など ２つの機能の効率性を 比較するのに使えます

次は位置情報です このメトリックスは 位置情報の累積使用量といった 使用量の定量化に役立ちます

バッテリーの観点では 見落としがちな点です 想定外の場所で 位置情報が起動する場合や バケットの精度を検証したい という場合があるかもしれません これらの測定に活用できます

次はディスプレイです ここでは特にAverage Pixel Luminance についてお話しします OLEDを使ったデバイスでは UIの色がディスプレイの 消費電力に直接影響を及ぼします そこでこのメトリックを活用します

つまりUIで明るい色を使うほど OLEDでの消費電力が高くなります 逆にUIで暗い色を使用すると 消費電力は低くなります 覚えておいてください

次はネットワークです ご想像いただけると思いますが Wi-Fiなどの接続に関する メトリックスです

ネットワークには 電力を多く消費しますから 接続回数を検証する際などに 活用できます 想定外の接続が 行われている時などです

データ転送をする際の 接続への影響も重要な点で これにも多くの電力が消費されます 接続状態の悪い環境で 役立つメトリックスです

これらは― バッテリーへの影響を 定量化するのに役立つでしょう

次はパフォーマンスです ハングアップ ディスク アプリケーション起動 メモリ カスタムインターバル バッテリー同様 これらも重要なメトリックスです まずはハングアップ

これはアプリケーションが 応答しない時間を表示します 想像してみてください アプリケーションが 突然動かなくなったら？

このメトリックスは ディスパッチやキューを活用し ハングアップ率を 低減するのに役立ちます

次はディスクです 今年は Disk Logical Writesに注目します

ディスクは必要な時だけ 使用されるべきなので 使用量の定量化は必須です 想定外の書き込みの インスタンスを特定したり コアレッシングの戦略を 考えたりする際にも活用できます

次はアプリケーション起動です

これは起動時間と 再開時間を表示する― 非常に優れたメトリックスです

これによりパフォーマンスへの影響を 定量化できます

データベースの更新などは 起動や再開時間に影響を及ぼすので 影響をよく把握しておく必要があります

起動と再開の違いについても 理解しておいてください 詳細については 明日のOptimizing App Launchの セッションでご紹介します

次はメモリについてです 今年はAverage Suspended Memoryと Peak Memoryが追加されます

メモリ管理には負荷がかかるので これらのメトリックスを使って 使用量を管理してください

予想以上にメモリが使用され 上限に達している場合は メモリリークなどの問題が 想定されます

メモリが停止する割合を低減できれば 起動時間を短縮することも 可能になります

これらのメトリックスは― デバイスにおける パフォーマンスの理解に役立つでしょう

ここまでバッテリーと パフォーマンスの定量化に使える 既存のツールを紹介しました また さらに一歩進んで 今年 提供する 新しいツールも紹介しました これらはアプリケーションの向上に 活用できるでしょう ここからは各ツールを 詳しく説明していきます まずはサストリーから XCTest Metricsの話をしてもらいます サストリー (拍手)

こんにちは ソフトウェア･エンジニアの サストリーです まず 開発とテスト段階で使える ツールを振り返ります XcodeのDebug Navigatorでは CPUやMemoryなどの概要が見られます ここで問題の原因究明に活用できるのが Instrumentsです 次の原因究明に役立ちます メモリの問題 応答しないシステム ディスク使用量の超過 バッテリーの問題 パフォーマンスの測定には XCTestも使えます これはXcodeに組み込まれている UIやユニットテストを書く際の プログラムです

リグレッションを見つけることも できますが―

測定できるメトリックスは World Clock Timeだけでした そこで今年 新しいパフォーマンスの メトリックスを追加しました

詳しく見ていきましょう これはパフォーマンスの XCTestの一例です まず measureメソッド内に 一連のコードを渡すことで 実行にかかる時間を 測定することができます では 詳細を得るために 新しい形式に変換してみます ClockやMemory CPUオブジェクトを パラメータとして measureメソッドに渡します このように少しの変更で テストが様変わりします

新しいUIテストの各ターゲットには アプリケーションの起動テストが 自動で追加されます コードを書かなくても 起動時間を測定できるのです

デモをします

このセッションのために Awesome Photo Appを作成しました

いくつかの機能を説明するために 写真を撮ります

撮り終わったら― ジオタグを画面下に表示させます 次にエフェクトを適用させましょう このツールはデモ全体で参照します 撮った写真を保存し Serverにアップする標準機能もあります では Xcodeからテストをしてみます 作成したUIテストのターゲットには アプリケーションの起動テストが 追加されるんでしたね セッションの前に テストを実行しておきました これがその結果です アプリケーションの起動には 約0.2秒かかっています イテレーションについても どれもほぼ同じ秒数です ここで基準値を設定します 基準値とはパフォーマンスの ガイドラインとなる値です この値を超えると リグレッションがあるということです 平均と標準偏差を設定しておき― 結果がこの条件を超えてしまうと テストは失敗となります ではコードを変更し 起動時間が超過していないか 確認してみます 再度 テストしましょう

パフォーマンステストの注意として 負荷がかかるので デバッガーは加えないようにします すべての診断オプションも 切っておきます 独立したスキームを作成するか テストプラン機能を使うことで 簡単にオフにできます テストに失敗した原因を 見ていきましょう 先ほどは0.2秒だった平均値が 1.2秒になってしまっています 起動時間が超過した原因を探るには Instrumentsの Time Profilerを使います 実際にやってみましょう ここではデータベースの更新を 確認していますが 最善の方法ではありません 正しくは バックグラウンドキューに送ります 問題が修正されるか見てみましょう 値が基準値内に収まっているか 確認します

XCTestでは測定だけでなく リグレッションの確認もできます 書いたテストのことを忘れて 実行し続けていても パフォーマンスが 低下することはありません ご覧のとおり テストに合格しました (拍手) このように既存のXCTestを 変換させることは簡単で― テストを様変わりさせます 必要な作業は 測定したいオブジェクトを渡すだけです ここでは撮影時間を測定する テストを行いました

エフェクトも適用しています 以前は時間を測定するだけでした 今は MemoryMetricの オブジェクトを渡すだけで メモリも測定できます

XCTestはユニットテストにも 使うことができます では 例をお見せしましょう applyEffectsでは １枚または複数の写真が選択できます 特別な機能とは言えませんが 負荷が低い場合には有効です ここではエフェクトを適用した １枚の写真のメモリ使用量を測定します 結果は約1000KBです 複数の写真を追加した場合の 影響を測定するには filtersの値を変更するだけで 簡単にできます テスト実行後すぐに結果が反映されます 結果が反映されたら― 影響を確認できます 見てみましょう ご覧のとおり テストは失敗してしまいました 使用量が2000KBになってしまったので １枚の方がいいですね

まとめましょう ここではメモリのデモを行いましたが ストレージやCPU OSSignpostのメトリックスもあります また 独自のメトリックスの実装もでき レポート機能を使って リグレッションの確認ができます 詳細はドキュメントをご覧ください また XCTestで A/Bテストのようなこともできます 低コストかつ簡単な方法で 比較をすることができます 最後にユニットテストも行いました

XCTestはXcodeや Xcode Serverと相性がいいので 開発とテスト段階で 活用することができます またアプリケーションの リグレッションの確認もできます 以上がXCTestを使った新機能です 次はアシシュから 実機での影響について紹介します (拍手)

ありがとう 開発とテスト後の段階にも メトリックスを収集することの 利点が多くあります 例えばベータ版やリリース版を 利用するユーザの活用です

公開されたアプリケーションは 異なるネットワークやデバイス 異なる場所などで使用されます このデータは新たな問題の特定に 役立ちます

また 前OSとの メトリックスの比較もできるので リグレッションや問題の 見極めが可能です

新たな機能による影響を把握したり A/Bテストを行ったりもできます

この問題解決に活用できるのが MetricKitで データ収集のための オンデバイスフレームワークです またクリティカルセクションの データ収集も可能です データを収集する際の ユーザプライバシーも保護されています

MetricKitの導入はとても簡単です

必要なコードはこれだけです MetricKitフレームワークを取り込み アプリケーション内に クラスを作成します

クラス内にあるサブスクライブが メトリックスの受信を承認すると データ収集が開始されます

最後にdidReceiveを実装しておき ペイロードを伝送するかどうかの 判断を行います 受信後のアクションは皆さん次第です ファイルへの保存や Serverへのアップロードが可能です

MetricKitを導入することで １日のアプリケーションの使用状況を 収集できます

24時間経つと過去24時間の メトリックスのサマリが生成され デバイスに返されます

クリティカルセクションでの 影響を測定します

Awesome Photo Appを例に 実行できるアクションを説明します 例えば 撮影した写真に エフェクトを適用します これが気に入れば デバイスに保存します MetricKitでは 各アクションによる影響を 把握することができます

実際にやってみます MetricKit内に新たに導入した― mxSignpostを使います クリティカルセクションを mxSignpostで囲むだけです 例をお見せします

mxSignpostを使うには MetricKitのmakeLogHandleを使用して LogHandleを作成します そしてクリティカルセクションを mxSignpostで囲みます では写真を保存した際の影響を 測定してみます コードをmxSignpostで囲むと― 自動的にMetricKitが メトリックスを収集します

では MetricKitのデモを お見せしましょう

Xcodeプロジェクトにアクセスし ViewController.swiftを表示します MetricKitフレームワークのクラスには MXMetricManagerSubscriber があります また ペイロードの有無を確認する didReceiveも加えてあります オンデバイス処理のために データはファイルに保存します 出力コードも加えたので ペイロードの内容もお見せします 最後にデータを Serverにアップロードし 複数ユーザのデータを 収集できるようにします

このメソッドは１日に１回実行され ペイロードの確認を行います では この新機能を使って テストをしてみます まず アプリケーションを実行します

次にDebugから MetricKit Payloadsを選択します これはダミーペイロードを送信し コードのテストを行います では中身を見ていきましょう これはビルドバージョンや デバイスタイプなどの メタデータです その下には起動 再開 ハングアップなどのヒストグラム アプリケーション使用率のメトリックス これはCPUとGPU時間 そして位置情報の使用量や ネットワーク メモリなどもあります こちらはmxSignpostの サマリとなります 様々なメトリックスがありますので 詳細はドキュメントをご確認ください スライドに戻ります

MetricKitを使った メトリックスの収集は 難しいことではありません

もう少し踏み込んで アプリケーションで撮った 写真のメトリックスを収集します

MetricKitを使った翌日になると デバイスのペイロードが Serverにアップロードされます

このデータを使って 問題のある場所を特定しましょう

このデータには フォアグラウンドやバックグラウンド また位置情報の総時間が表示されます 位置情報は714秒で フォアグラウンドとほぼ同じです これは想定外で― 位置情報は写真のジオタグに 使用しただけです 確認してみると 位置情報を閉じ忘れていたようです このように ビヘイビアの特定に MetricKitが活用できます また位置情報の精度が高いほど バッテリーを使用するので 使用量の低減にも活用できます

次はハングアップ時間のデータです ５秒以上かかるインスタンスが多く 使い勝手が悪いですね メインフレームでの ブロッキングの呼び出しが短くなれば 問題は解決するでしょう

次は問題のある場所を 特定するための mxSignpostデータの使い方です

LoadPhotosやApplyEffect SavePhotosやUploadPhotosを mxSignpostで囲みました これにより インスタンスの実行回数が割り出せます また CPU時間の累積や総時間なども 割り出すことができます

このデータを見ると ApplyEffectのCPU使用率は 50％以上です ここを最適化すれば バッテリーへの負荷を減らせますね

覚えておいてほしいのは― iOS 13からはMetricKitを使って メトリックスが収集できること

また複数のユーザ群から 問題のある場所を特定するのに MetricKitが活用できること

シングルユーザからの データ収集も紹介しましたが 複数のユーザから収集すれば アプリケーションの向上に役立ちます

次はアンシュールから テレメトリーの紹介をしてもらいます (拍手) ありがとう ではMetrics Organizerについて お話しします これはXcode 11に追加される 新しいツールです

Metrics Organizerは 画期的なソリューションで アプリケーションの分析を表示できます バッテリーとパフォーマンスの状態を 確認できるというわけです Xcode 11に追加されるので アプリケーションの変更は不要です Serverにデータを集約するので データを収集する上での プライバシーにも配慮しています なので 今日から使用が可能です

機能としては ユーザがアプリケーションを使用すると ツールがデータを収集します 集約されたデータは Serverに送信されます その後 Serverで分析が行われた 詳細な分析結果が Metrics Organizerに表示されます

ただし アプリケーションの使用量が しきい値を満たしている場合のみです

この画期的なソリューションは アプリケーションや 開発プロセスの変更を必要としません 話をするよりも― デモをしましょう (拍手)

Metrics Organizerは Window内のOrganizerから開きます

ArchivesやCrashesに加え Metricsタブが追加されています Metricsをクリックすると 左側には公開されている アプリケーションが表示されます 仮にAwesome Photo Appを 公開済みとして Appをクリックすると メトリックスが表示されます バッテリー状況や起動時間 ハングアップ率など このアプリケーションで 考慮すべきメトリックスです Memoryをクリックすると 現バージョンでの メトリックスの詳細が表示されます 前バージョンとの比較も可能で Ｘ軸はバージョン Ｙ軸はメトリックスの値です

Batteryをクリックすると ２種類のデータが表示されます １つ目のデータは ユーザがスクリーン上で使用した場合の バッテリー消費量が示されています もう１つはバックグラウンドでの バッテリー消費量です 各メトリックスは システムコンポーネントごとに 細かく見ることもできます 電力消費量が高いコンポーネントが 特定できるのです

フォアグラウンドのみで起動されている Awesome Photo Appを見ていきます バックグラウンドを見ると 約10％のバッテリーが 毎日使用されているようです 処理には５％を使用しており ネットワークには3.66％使用しています バッテリーの消費量が高い原因を特定し デバッグする必要があります

では最新バージョンを見ていきます オンスクリーンの状態では 前バージョンと比較すると 約10％の悪化が認められます ディスプレイでは ほぼ変化はありません 他にも多少の増減はありますが 主な要因は処理の部分です 90パーセンタイルと50パーセンタイルの ユーザを確認してみて ユーザによる違いなのかを見てみます iPhoneやiPadカテゴリー またはデバイスごとのデータを 見ることも可能です では iPhone 6のデータを見てみます バッテリーの消費量は ほとんど変わりません 1.0.7と比較すると 1.0.8では少し減少しているようです 次に最新のiPhone Xを見てみます iPhone Xでは大きな変化がありますね 前バージョンと比較すると 14.4％増加しており 主な要因は処理にあります デバッグ方法はいくつかあります コードにアクセスするか Energyタブにアクセスするかです ここには消費電力の 例外レポートが表示され スタックフレームから 消費している場所を特定できます 先ほどアシシュが説明したように 新機能が最新のデバイスや 1.0.8バージョンに追加されています その機能を使ってデバッグを行います これは先ほどのメトリックスで Energyタブから問題を修正します

他のメトリックスも見てみます ユーザを落胆させないためにも Launch Timeは重要な要素といえます 数秒で起動することが理想的で iPhoneでのAwesome Photo Appの 起動時間は６秒です デバッグをするには サストリーが紹介したツールを使います

Hang Rateはアプリケーションが 応答しない時間の表示で ユーザを満足させるには ０秒であるべきです

Memoryには最大値と 平均値が表示されます メモリは必要とされる時にのみ 使われるべきです

Disk Writesは 論理書き込みのデータなので 書き込み回数を 知っておく必要があります デバッグにはInstrumentsが使えます

以上がバッテリーと パフォーマンスの分析を表示する Metrics Organizerです このツールを使ってバッテリーの消耗や 起動時間の問題を デバッグすることができます バージョンごとのデータを 比較することで 基準値を作成することができます アプリケーションや開発プロセスを 変更することなく 今日から使用できます ぜひ試してみてください ありがとうございました (拍手) ありがとう

今日ご紹介したツールの おさらいをしましょう まず 影響を把握するための 提供済みのツールをご紹介しました 影響の定量化に役立つ 強力な新しいツールも いくつかご紹介しました 収集されたメトリックスは コードのデバッグに役立ちます

今回デモを行った ３つの新しいツールについて ぜひ意見を聞かせください これらのツールは 影響の定量化に役立つはずです これにより ユーザに満足してもらうための 適切な判断が下せるでしょう

詳しくは ドキュメントを見ていただくか 明日のセッションにご参加ください ツールの導入方法や最適化に向けた 活用方法をご紹介します Optimizing App Launchの セッションもお忘れなく ありがとうございました (拍手)