アプリのパフォーマンスを継続的に計測する

by Daiki Katayama

Slide 1

Slide 1 text

継続的にアプリパフォーマンスを計測する iOSDC Japan 2020 kariad

Slide 2

Slide 2 text

自己紹介 ● kariad / 片山大樹 / @kariad_uu ● DeNA > SWET > Automation test iOS team ○ Software Engineer in Test ● ソフトウェアテスト、それを支えるプロセス改善

Slide 3

Slide 3 text

じめに今回発表で、SWETで取り組んでいるアプリパフォーマンス計測について話しますパフォーマンス計測に関する知見多くなく、試行錯誤しながら作っていったため、失敗もたくさんありますそうした失敗や今こうしているといった知見を紹介できたらと

Slide 4

Slide 4 text

アジェンダ 1. なぜパフォーマンス計測が必要なか? 2. iOSアプリにおけるパフォーマンス計測方法 3. 継続して計測する仕組み作成 4. 運用してみて 5. これからについて

Slide 5

Slide 5 text

なぜパフォーマンス計測が必要なか?

Slide 6

Slide 6 text

アプリパフォーマンスが悪いとひとくちにパフォーマンスと言っても様々 ● なかなか読み込みが終わらない ● 短時間利用で端末が熱くなる ● 動作が重い、カクカク、もっさり場合によってパフォーマンスが悪いことでクラッシュも起こりうる

Slide 7

Slide 7 text

アプリパフォーマンスが悪いとユーザーがアプリを快適に利用できない →ユーザー離脱可能性防ぐためにリリース前に機能が正しく実装されているかだけでなくパフォーマンス観点でもテストを行い、問題ないかを確認できると良い

Slide 8

Slide 8 text

iOSアプリにおけるパフォーマンス計測

Slide 9

Slide 9 text

iOSアプリにおけるパフォーマンス計測代表的な例 ● Instruments ● MetricKit ● 外部(Apple以外が提供している)サービスどような情報が取れるか、どように情報が取れるか、計測タイミングなど異なる

Slide 10

Slide 10 text

Instruments ● Xcode 一部として提供されているパフォーマンス計測ツール ● どこパフォーマンスが悪いか分析、特定する機能をサポート ● TimeProfiler, Leaks, Network等多くテンプレートを持ち様々な角度から計測が可能 ● 原因特定 dSYMがあれ実際コードどこ部分かというところまで特定できる

Slide 11

Slide 11 text

Instruments Templateが充実していて選ぶだけで簡単に計測ができる

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

Instruments GUIだけでなくCUIからでも計測が可能 instruments -t ${template} -w ${UDID} -l ${timeLimit} -D ${fileName}

Slide 14

Slide 14 text

Instruments GUIだけでなくCUIからでも計測が可能 instruments -t ${template} -w ${UDID} -l ${timeLimit} -D ${fileName} ※保存時に少し時間がかかるで注意 template名(e.g. Time Profiler) 計測に利用する端末 UDID 計測時間上限(ms) 保存時ファイル名 (xxx.trace)

Slide 15

Slide 15 text

MetricKit ● iOS13から利用可能 ● 実際にコードに埋め込んでデバイス上情報を取得できる ● 起動時間、CPU使用時間、バッテリー消費量、クラッシュなど ● ユーザ環境で計測し、24時間に一回サーバにデータが送られる WWDC セッションによるとMetricKitを用いてTestFlight ベータテスターや実際ユーザー手元で何が起こっているかを計測するべきだと述べられている詳しく知りたい方 WWDC 2020 「What’s new in MetricKit」がおすすめ https://developer.apple.com/videos/play/wwdc2020/10081/

Slide 16

Slide 16 text

外部サービス SDKとして組み込んで計測するタイプ ● Firebase Performance Monitoring デバイスファームとセットになったサービス ● HeadSpin → 計測できる指標サービスによりけり

Slide 17

Slide 17 text

継続して計測する仕組み

Slide 18

Slide 18 text

継続的な計測 ● 常に安定したアプリをリリースするに悪くなってからで遅い ● そために継続的にパフォーマンス計測が行える仕組みが必要 ○ 継続して計測することで改善も実施しやすくなる ● 毎回手動で実施する大変なで自動で実施したい

Slide 19

Slide 19 text

今回計測したかった内容 Pocochaで視聴者が多い配信で端末温度上昇とそれに伴うパフォーマンス低下が問題になっていたそため一定時間負荷をかけ続けたアプリ状態を配信/視聴画面まで移動してから計測対象とした ● 計測時間: 30分, 2時間 ● 計測内容: CPU使用率と端末温度（Thermal state）変化 ● 計測タイミング: 毎晩

Slide 20

Slide 20 text

継続的な計測で必要と考えたも ● 計測ツール ● 最新アプリ ● 実機 ○ 計測する内容にもよるが、端末温度など実機でしか計測ができない ● 定期的に実行させるため環境(CIサービス) ● アプリを操作するUIテスト ● アプリに負荷をかけるツール

Slide 21

Slide 21 text

計測ツール Instrumentsを採用 ● すでにパフォーマンスが問題になり始めているということもありリリース前、開発中に問題ないかを確認したかった ● 問題がある場合早く原因を特定したい ○ InstrumentsならdSYMがあれ原因まで調査できる

Slide 22

Slide 22 text

最新アプリ毎日変更に追従した最新アプリで計測(場合によって任意ブランチなど) デバッグ用にdSYMも必要なためCIでArtifactsとして残す必要さらにInstrumentsで正しく計測するために以下条件を満たす必要がある ● コンパイラ最適化を実際 releaseビルドと合わせる ● development 証明書でsignしている

Slide 23

Slide 23 text

最新アプリコンパイラ最適化問題 ● Xcode デフォルト設定で debugビルドとreleaseビルドで最適化設定異なっている ● 最適化差異がパフォーマンス計測に影響がでる可能性がある ● 実際にユーザが利用するreleaseビルドと同等最適化がされたアプリで計測する必要がある ● WWDC 2019 Getting Started with Instrumentsセッションが参考になる ○ https://developer.apple.com/videos/play/wwdc2019/411/

Slide 24

Slide 24 text

最新アプリ signする証明書問題 ● Instrumentsで計測するために development certificateでsignしたもでなくていけない(配布用で計測できない) release 最適化設定を利用しながらdevelopmentでsignが必要

Slide 25

Slide 25 text

最新アプリ ipa resign ● ipaに対して証明書を付け替えることができる ● releaseでビルドしたipaに対してdevelopment 証明書でresignできる ● fastlane resignを利用 ○ https://docs.fastlane.tools/actions/resign/

Slide 26

Slide 26 text

Slide 27

Slide 27 text

最新アプリ fastlane resign resign( ipa: ipa_path, signing_identity: "iPhone Developer: Xxxxxx Xxxxxxx(FFFFFFFFF)", provisioning_profile: { "com.swet.app" => provisioning_profile_path, "com.swet.app.notificationservice" => provisioning_profile_notification_path }, display_name: "SWET Debug" ) resign後 identity(今回例で release→development なでdevelopment を記載) 左側に今signしているBundle identifier(今回 release) 右側にresignするProvisioning profile path 後からわかるようにdisplay nameも変えられる

Slide 28

Slide 28 text

実機 Thermal stateを計測するために実機で計測が必要 ● 自前で管理コストが高い ○ テストが走っているタイミングで他テストが走らないようにする排他制御が必要 ○ OS バージョン管理 ○ 場所も取る ○ 問題が発生したときに出社が必要

Slide 29

Slide 29 text

実機クラウド型デバイスファーム Web等から実際実機と同じようにアクセス、操作できるサービス ● AWS Device Farm ● Remote Testkit ● HeadSpin

Slide 30

Slide 30 text

HeadSpin 様々なパフォーマンス計測もできるデバイスファーム端末単位契約で端末を他社と共有することない ● Xcodeから直接Runができる ● Wi-Fiだけでなく特定 SIMで4G回線で利用もできる ● 実機でできる大体ことできる ● AppiumサーバーがHeadSpin側で用意されている今回計測 Instrumentsを使うことにしたでHeadSpin 機能使っていない（将来的に計測項目が増えた際に使いたいと思っている）

Slide 31

Slide 31 text

HeadSpin Appiumについて補足 Appiumクライアント Appiumサーバー Web driver agent テストスクリプトテスト対象アプリ端末 Appium動かすにここが必要

Slide 32

Slide 32 text

HeadSpin

Slide 33

Slide 33 text

HeadSpin APIも充実していて例え ● ipa インストール、アンインストール ● スクリーンショット撮影 ● デバイスロック、アンロック ● OSアップデートポップアップを消す等々、他にも色々ある

Slide 34

Slide 34 text

HeadSpin Appiumから利用する場合 ● Capability server_urlにHeadSpin側に表示されるURLをセットするだけで Appiumサーバーを立てずに利用できる(UDID等必要) ● Appium DesktopからもHeadSpin Web Driver URLをセットするだけで利用できる ● Appium バージョンもCapabilityから指定できる(インストールされていない場合お願いしたらすぐ対応してくれる)

Slide 35

Slide 35 text

HeadSpin Appium以外から利用する場合 ● HeadSpin CLIを使ってbridgeする ● XcodeからRunできる、Instrumentsで計測もできる

Slide 36

Slide 36 text

CI 今回計測で 2種類用途がある ● 計測対象アプリをビルド、resignする ● 計測を行う（負荷ツールを動かす）元々Bitriseを利用していたでビルド Bitriseで問題ない計測最大2時間を想定していたためBitriseで不可能(現時点最大 90分) → 色々やりたいと考えるとひとまず選択肢として Jenkins

Slide 37

Slide 37 text

CI Jenkins ● Jenkins自体管理が必要 → SWET CI/CDチームが管理してくれているJenkinsに相乗り Xcode 新しいバージョンも簡単にインストールできる仕組みが整っている (Jenkinsに詳しいメンバーが周りにいるで困ったら気軽に質問できる) ただし最終的に脱Jenkinsを考えている

Slide 38

Slide 38 text

アプリ操作用 UITestフレームワーク目的画面までアプリ操作が必要 ● Appium x Ruby(RSpec) ● XCUITest HeadSpinを利用する予定だったでAppiumサーバーを用意する必要がなく、Appium が相性が良かった AppiumからInstrumentsを利用することもできたも◯

Slide 39

Slide 39 text

Appium Insturmentsで計測がAppium コード経由で実行することができる # Rubyで例 # 計測開始 @driver.start_performance_record( timeout: ENV['TIMEOUT'], profile_name: 'Time Profiler' ) # 計測完了 @driver.get_performance_record( save_file_path: "fine_name", profile_name: 'Time Profiler' )

Slide 40

Slide 40 text

Appium Capabilityで注意点 ● 実機場合 bundleId 指定が必須 ● 待ちが発生するためnewCommandTimeout 設定をしてTimeoutを防ぐ ● HeadSpin Appiumサーバーを利用する場合 serverUrlに設定する

Slide 41

Slide 41 text

アプリに負荷をかけるツール必ずしも必要なもと限らないが、今回要件で必要だった ● SWET 他チーム(Goチーム) メンバーと協力して作成 ● 変更が入った場合でも常に最新もを利用するためGitHub Release Assets からDLできるように

Slide 42

Slide 42 text

こ構成で起きた問題必要なもすべて揃った、後組み合わせるだけ... そう上手いこといくわけなかった起きた問題一例として ● Appium server 問題 ● Instruments データ取得問題

Slide 43

Slide 43 text

Appium server 問題最初Appium server HeadSpin もを使う想定だったいくつか理由からAppium serverをJenkins上で持つ形に ● Xcode バージョン ● traceファイル保存先 Appium serverをHeadSpin側もを利用するということ、Instruments バージョン (Xcode バージョン)も向こうに依存してしまう新しくしたりビルドと合わせたりと柔軟性がほしかった

Slide 44

Slide 44 text

Appium server 問題 traceファイル保存先 Instrumentsで計測自体 HeadSpin サーバーで実行されている → traceファイルを転送する必要がある ● 転送先を考える必要性 ○ 転送仕組み自体 Appiumで実装されている Xcode バージョン問題とを考慮してJenkins上でAppium serverを建てる方法を採用 → HeadSpin 端末み利用に

Slide 45

Slide 45 text

Instruments 問題 Instruments 問題点として計測結果を定量的な数値で取得する方法がない (実際にある程度とれるも * あったがこ時点で存在知らなかった) そため、結果確認 Instruments appを開いてGUIで結果を確認する必要がある ● 30分計測ともなるとファイルサイズ(150〜200MB程度)も大きく、開くに時間がかかる ○ 1分くらいかかることも ... ● 毎回手動で結果を確認するかなり面倒 *TraceUtility(https://github.com/Qusic/TraceUtility )

Slide 46

Slide 46 text

Nominal → Fair → Serious → Critical

Slide 47

Slide 47 text

Nominal → Fair → Serious → Critical 各state 開始時間と終了時間が表示される

Slide 48

Slide 48 text

CPU使用率推移グラフでみ表示される詳細に表示されるど処理が何％CPUを利用しているかグラフ最大値がそ回一番使用率が高い値になってしまう（全く同じグラフだったとしても同じ使用率と限らない）

Slide 49

Slide 49 text

Instruments 問題 XCUITestを用いた強引な解決策 ● XCUITest Instrumentsを操作することもできる ● XCUITestでtraceファイルを開いてThermal stateとCPU使用率部分でスクリーンショットを撮影、Slackに投稿させた ● Thermal stateについて文字列で情報も取れるためSeriousまで行ったら失敗させるといったこともできる ● CPU使用率について厳しかった

Slide 50

Slide 50 text

Instruments 問題 Slackへ投稿

Slide 51

Slide 51 text

検討した上で今回構成 ● 計測ツール: Instruments(Appiumから利用) ● 最新アプリ: Bitriseでビルド ● 実機: HeadSpin ● CI(計測): Jenkins ● アプリ操作用 UITestフレームワーク: Appium ● 負荷をかけるツール: お手製複数ツールに跨っていて終わったら次、といった感じにピタゴラスイッチみたいにになってしまった

Slide 52

Slide 52 text

Bitrise 1. releaseビルドでipaを生成 2. development証明書でresign

Slide 53

Slide 53 text

Bitrise 5. Jenkins jobトリガーAPIを実行 Jenkins 3. dSYMをArtifacts化 HeadSpin 4. HeadSpin APIを使ってipaを配布

Slide 54

Slide 54 text

Bitrise 7. 負荷ツール DL、Appiumサーバー起動等準備 Jenkins HeadSpin 6. HeadSpin 端末に接続 Appium サーバー

Slide 55

Slide 55 text

Bitrise 8. 計測開始 9. 計測完了 Jenkins HeadSpin Appium サーバー

Slide 56

Slide 56 text

Bitrise 10. traceファイルをXCUITestで操作して結果を取得 Jenkins HeadSpin Appium サーバー trace ファイル

Slide 57

Slide 57 text

Bitrise 11. traceファイル Artifacts化 12. 結果 Slackへ投稿 Jenkins HeadSpin Appium サーバー

Slide 58

Slide 58 text

処理流れ(概要) 1. Bitriseでreleaseビルドでipaを作成 2. ipaに対してdevelopment証明書でresign 3. 最終的なipaをHeadSpinにAPI経由で配布、dSYMをArtifacts化 4. BitriseからJenkins トリガー実行 5. Jenkinsで負荷ツール DL、起動、HeadSpinへ接続等準備 6. 計測開始 7. 計測完了 8. 結果 traceファイルをXCUITestを用いて結果 SSを撮影 9. 結果をSlackに通知、traceファイル等 Artifacts化

Slide 59

Slide 59 text

そしてJenkinsfileが長くなる処理が多くJenkinsfileがどうしても長くなってしまうで可読性等が低い前述流れ中でさらにいろいろやっているデバッグもしづらくメンテナンスがしづらい問題ある

Slide 60

Slide 60 text

実際に運用してみて

Slide 61

Slide 61 text

実際に運用してみて実際に運用をしていく中で想定していた問題や、新たな問題が発生 ● Appium 不安定さ ● 実行パターン増加 ● 季節 ● インカメラへ利用 ● 結果確認方法

Slide 62

Slide 62 text

Appium 不安定さ負荷をかけ続けた状態で一定時間経つと、connection errorが発生する最後最後でInstrumentsが完了できないということも ● 本来使い方でないで仕方が無いといえ仕方がないかもしれない ● Appium serverとクライアントで通信をしながら操作しているため起きた問題かも ● 詳細な原因わからずじまい

Slide 63

Slide 63 text

Appium 不安定さ採用理由がHeadSpinでAppiumサーバーが用意されていて便利だったから HeadSpin Appium serverを利用しなくなった時点でAppiumである必要性がほぼなくなっていた → であれ XCUITestでもいいでないか ● 現在 XCUITestに移行済み ● InstrumentsもCUIで実行している

Slide 64

Slide 64 text

実行パターン増加最初 1パターンx2(30分, 2時間)で計測新機能追加に伴う色々な状態で計測が求められるように ● 端末温度が上昇するためそまま次を計測してしまうと、前回結果に引きづられる正しい計測ができない ● 環境にもよるが、最低でも30分間隔を空けないと実機で前回影響を受けずに正しい計測できない

Slide 65

Slide 65 text

実行パターン計測クールタイム計測計測クールタイム計測端末A 端末B 端末数を増やして対応(ど端末が何分待ったかという調整必要)

Slide 66

Slide 66 text

季節外部気温変化によるThermal stateへ影響 ● 実装時冬〜春 ● 運用中に夏に ● 同じ条件でも外部気温影響でよりやく端末温度上昇が起きたただこれユーザーにも同じことが言えるため、夏でも問題ないようにパフォーマンスを良くするべき

Slide 67

Slide 67 text

インカメラ利用計測パターンでインカメラに人顔を写した状態で計測する必要が出てきた HeadSpin 場合同一端末を契約単位で利用しているインカメラに特定画像を写し続けるといった特別な対応も行ってくれる → HeadSpin おかげで解決

Slide 68

Slide 68 text

結果確認フロー問題 Slackに投稿しているといえCPU使用率に関して実際に開いてみないとわかりづらい問題がやりある ● 結果として毎回100MB超えファイルをDLして、起動に時間がかかり...を手動でチェックする必要があった ● CPU使用率に関して GUIですら明確な数値が出せない ● グラフも最大値に合わせて上下してしまう ○ 定量的に判断が難しい ● まだ未解決

Slide 69

Slide 69 text

運用した結果変更 ● 計測ツール: Instruments CLI ● 最新アプリ: Bitriseでビルド ● 実機: HeadSpin(端末数が増えた) ● CI(計測): Jenkins ● アプリ操作用 UITestフレームワーク: XCUITest ● 負荷をかけるツール: お手製そ他細かいところ調整している

Slide 70

Slide 70 text

これから展望

Slide 71

Slide 71 text

xctrace Xcode12からInstrumentsコマンドがdeprecatedとなりxctraceが追加された ● 基本的にInstrumentsコマンドでできていたことできる ● traceファイルからXML形式でデータが取得可能 ● Thermal stateが取得できること確認済み ● CPU使用率について現時点で難しいかもしれない

Slide 72

Slide 72 text

Bitrise(MacStadium)へ移行当初2時間で計測も考えていたが、今 30分計測みに変わった ● 結果として90分制限に縛られなくなったためBitriseへ移行も考えている ● Instrumentsで計測にそれなりスペックがないと不安定なでそこだけ心配一方でJenkinsもオンプレからMacStadiumへ移行している ● Mac miniを借りれるクラウド ● MacStadiumだと再起動が出社なしで可能

Slide 73

Slide 73 text

他項目計測今計測している項目以外でも計測したいもが出てきているそため現在、FPSなど新たな項目で計測準備をしているそちら Big Queryにデータを入れてData studio等で可視化を検討しているこパフォーマンス計測もそこに合わせてデータを可視化したい

Slide 74

Slide 74 text

さいごに今回紹介した計測方法あくまでも一例アプリ特性や何を計測したいかでも変わってくるアプリ特性にもよるが、パフォーマンスがまだ問題になっていないであれ MetricKitから導入してみるがいいかもしれないそこから改善サイクルを回していきましょう

Slide 75

Slide 75 text

DeNA Tech Twitter アカウントで、 DeNA エンジニアリングに関する登壇資料やブログを紹介しています！後日ブログで紹介しきれなかったところを書くでそ告知もあります

Slide 76

Slide 76 text

ありがとうございました！