🧝🏾 🤷🏾 🌿 iOSアプリのパフォーマンスのオーバークロック ⛹🏻 🕶️ 👀

戦艦USSインディアナBB-1、1910年のブレーキ。 この仕掛けは10453トンの排水量で船の速度を落とすはずです。

オリジナル： iOSアプリのパフォーマンス：楽器とその先

投稿者：イゴールM

ユーザーは待ちたくない。彼らは、アプリケーションが初期化する必要のあるものを気にせず（そうすべきではありません）、できるだけ早くタスクを完了したいだけです。アプリケーションはほぼ瞬時に起動し、インターフェイスはスムーズに移行して美しくなければなりません。アプリケーションのパフォーマンスは、競争の激しいソフトウェア市場における重要な利点の1つです。

開発者としても、アプリケーションを誇りに思っています。

ただし、パフォーマンスの最適化は複雑な問題です。ほとんどのボトルネックは常識に反しています。適切な測定値がない場合、アプリケーションの速度が低下する原因を理解することは非常に困難です。

アプリケーションのパフォーマンスを最適化するには、データベースに基づいた意思決定を行う必要があります。このパートでは、アプリケーションのさまざまな部分のパフォーマンスを測定して、このデータを取得する方法を示します。

触れるツール：

アプリケーションによるCPU、GPU、メモリ、電力消費の分析。
アプリケーションの応答性;
開始時間;
ユーザーから収集されたパフォーマンスメトリック。

アプリケーションによるCPU、GPU、メモリ、電力消費の分析

最初のタスクは、プロファイラーを使用して、CPU、GPU、またはメモリを乱用している非効率的なコードを見つけることです。 Appleには、これを達成するための優れたツールがあります：“ Instruments ”。

最初に使用する必要がある4つの主要な領域があります。

CPU（「タイムプロファイラー」ツール）;
GPU（「コアアニメーション」ツール）;
メモリ使用量（「割り当て」ツール）;
消費電力（「エネルギー診断」ツール）。

WWDCビデオは、Instrumentsを使用してアプリケーションのプロファイルを作成するための最適な情報源です。

始めるためのいくつかのオプションがあります。

アプリの応答性

次に測定する重要なことは、ユーザーインターフェイスの応答性です。感覚処理はメインストリームで発生します。そこに長時間の操作があると、アプリケーションが遅くなります。

プロセッサを使用しない場合でも、一部の操作には時間がかかる場合があります。メインスレッドに同期呼び出しがある場合は、これらの呼び出しにかかった時間を測定する必要があります。

測定には、例を使用できます。

CFAbsoluteTime startTime = CFAbsoluteTimeGetCurrent(); // Your method NSUInteger milliseconds = (NSUInteger)((CFAbsoluteTimeGetCurrent() — startTime) * 1000); NSLog(“Done in %lu ms”, milliseconds);

別のアプローチがViber開発者によって説明されました。メインスレッドを監視し、400ミリ秒以上ブロックされていないことを確認する特別なスレッドを作成します。

詳細については、プレゼンテーション（PDF、7MB）をご覧ください。

このデータを使用して、時間がかかりすぎる呼び出しを検出し（400ミリ秒が適切なしきい値です。詳細についてはこの本を読むことができます）、それらを最適化するか、メインスレッドから移動します。

打ち上げ時間

次に測定する重要なことは、アプリケーションの起動速度です。一般的なユーザーは、アプリケーションに数分しかかかりません。起動時間が長いとフラストレーションが発生します。

アプリケーションを起動するには2つのオプションがあります。

コールドスタート：アプリケーションのプロセスはまだ開始されていません。最初にOSから開始されます。
ウォームスタート：アプリケーションは最小化されましたが、 強制終了されませんでした。バックグラウンドから復元されます。

このセクションではコールドブートについて説明します。これはより多くのリソースを必要とし、大変な作業です。

iOSアプリケーションからの起動シーケンスがあります。アプリケーションの起動フェーズ（ドキュメントから）

1.開始にかかった合計時間を測定する

main（）の開始からapplicationDidBecomeActiveの終了までの時間を測定する必要があります。

main.m

 int main(int argc, char * argv[]) { // Save the initial time for startup [[StartipTimeMonitor sharedMonitor] appWillStartLoading]; @autoreleasepool { return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); } }

AppDelegate.m

 - (void)applicationDidBecomeActive:(UIApplication *)application { // Your code // We assume that the app is loaded then the main thread become free // after this callback is finished. dispatch_async(dispatch_get_main_queue(), ^{ [[StartipTimeMonitor sharedMonitor] appDidFinishLoading]; }); }

コードを追加した後、アプリケーションに新しい機能を追加してもコードが悪化しないことを確認してください。コールドスタート時間を最大1秒に維持してください。

2.起動時にフェーズ時間を測定します

原則として、起動にかかった合計時間だけを知るだけでは十分ではありません。起動シーケンスのどの段階で速度が低下するかを知ることも重要です。

最も重要な手順は次のとおりです。

[AppDelegateアプリケーション：didFinishLaunchingWithOptions：]-このメソッドは、ブートイメージまたはストーリーボードが表示されるときに呼び出されます。実行ポイントがこのメソッドから戻るとすぐに、ユーザーインターフェイスの実際の読み込みが開始されます。
[UIViewController loadView]-アプリケーションが独自のUIViewを作成する場合、これは初期化される場所です。
[UIViewController viewDidLoad]-UIViewがロードされました。最終初期化の時間。
[AppDelegate applicationDidBecomeActive：]-ユーザーインターフェイスは既に初期化されていますが、このメソッドの呼び出しが完了するまでロックされたままです。このメソッドは、アプリケーションがバックグラウンドから回復しているときにも呼び出されます。

一部のメソッドに時間がかかりすぎる場合は、それらを最適化する必要があります。

3.「圧力下」で開始時間を測定する

現実の世界と典型的なテスト環境の間には、1つの重要な違いがあります。

アプリケーションは、現実の世界では孤立して存在しません。ユーザーは通常、別のアプリケーションからアプリケーションにアクセスします。別のアプリケーションは非常に難しい場合があります。

別の重いアプリケーションが同時にバックグラウンドに移動してデータを保存しようとしている間に、アプリケーションが起動する条件で起動時間を測定することは非常に重要です。このテストにより、いくつかの予期しない結果が明らかになる場合があります。これまで完全に無害だったコードは、これらの条件でアプリケーションの速度を大幅に低下させる可能性がありました。

4.アプリケーションは既に開始されていますが、まだ役に立たない

ユーザーインターフェイスが読み込まれた後にアプリケーションが機能しない場合は、実際には起動フェーズがまだ完了していないと想定する必要があります。読み込まれたユーザーインターフェイスが応答していても、ダウンロードする必要があるデータがある場合でも、これはスタートアップフェーズの一部と見なされる必要があります。

ユーザーが組み立てるパフォーマンスメトリック

テスト環境では、以前のすべての測定が可能です。それらは必要ですが、十分ではありません。アプリケーションが人気がある場合、ユーザーベースが世界中に分散している場合、一部のユーザーは予想とは非常に異なる環境を持っている可能性があります。

それらは異なる場合があります：

ネットワーク条件;
ハードウェア
ソフトウェア（OSバージョン、脱獄...）;
デバイスの空き容量。
など

彼らは通常とは異なる方法でアプリケーションを使用する場合があります。

苦情のあるレビューから「1つ星」の評価を得ることができます（「アプリケーションが遅い！」）。実験室で測定するすべての測定基準が安全な領域にある場合でも。

それをどうしますか？

一連のパフォーマンスインジケーター（KPI）を定義し、実際のユーザーから収集します。これを行うには、ほぼすべての分析パッケージを使用できます。

ユーザーから取得できる主要業績評価指標の例を次に示します。

総コールドスタート時間;
総ウォームスタート時間;
段階的な起動時間;
サーバーから必要なデータをダウンロードするのにかかった時間。
メインスレッドが400ミリ秒を超えてブロックされた回数。
メモリ不足アラートの数。
FOOMSの数。
インターフェイスがロックされている、または使用できない場合の操作の期間。

分析パッケージを使用すると、デバイス、国、またはネットワークオペレーターのタイプとともに、これらのインジケーターをセグメントに配布できます。これにより、ユーザーがどのようなパフォーマンスの問題を抱えているか、どのように修正するかを知ることができます。

結論

ご覧のとおり、パフォーマンスの測定は、Instruments.appを起動するだけではありません。分析する他の重要なポイントがあります。説明されている分析方法には、迅速かつ簡単に実装できるものと、より多くの時間と労力が必要なものがあります。ただし、アプリケーションのパフォーマンスを監視して問題を見つけて修正し、アプリケーションをより使いやすくするのに役立ちます。

Facebookアプリケーションを例として使用して、高いスクロールパフォーマンスを実現する

オリジナル：高いスクロールパフォーマンスを提供

投稿者：ClémentGenzmer

Facebookでの目標の1つは、iOSアプリケーションを使用するユーザーの利便性を最大化することです。タスクの1つはニュースフィードがスムーズにスクロールするようにすることですが、非常に多様なコンテンツを持つ複雑なUIScrollViewでは、現在、フレームレートが低下した理由を判断する良い方法はありません。実際に非常にうまく機能し、高いスクロールパフォーマンスを維持するのに役立つ識別戦略を開発しました。次に、これがどのように機能するかを詳細に説明します。

デバイスでのスクロールパフォーマンスの測定

ほとんどのジョブの最初のステップは、パフォーマンス測定および測定機器です。 Appleのツールを使用すると、アプリケーションのフレームレートを測定できますが、アプリケーションの実行中に発生するすべてのインタラクションをシミュレートすることは依然として困難です。別のアプローチは、デバイスで直接スクロールのパフォーマンスを測定することです。

AppleのCADisplayLink APIを使用して、デバイスのフレームレートを測定します。フレームの概要を説明するたびに、かかった時間を測定します。 60分の1秒（16.6ミリ秒）以上かかった場合、フレームレートは低く、スクロールはぴくぴくしました。

[CADisplayLink displayLinkWithTarget:self selector:@selector(_update)]; 
      

        
        
        
      

     [_displayLink addToRunLoop:[NSRunLoop mainRunLoop] forMode:NSRunLoopCommonModes];

回帰の検出と固定

ビデオゲームとは異なり、FacebookアプリケーションはGPUをあまり使用しません。主にテキストと画像を表示するため、ほとんどのフレームはプロセッサの負荷のために落ちます。高いプロセッサパフォーマンスを維持するために、ニュースフィードでのデータレンダリングを構成するすべての操作が16.6ミリ秒未満で完了するようにする必要があります。実際には、フレームのレンダリングはいくつかのステップで構成され、通常、アプリケーションはフレームレートが低下するまでメインスレッドに8〜10ミリ秒しかありません。

メインスレッドがCPUのほとんどの時間を費やす場所を知ることで、最高のスクロールパフォーマンスを得ることができます。タイムプロファイラツールを使用して、メインスレッドがほとんどの時間を費やす場所を評価できますが、フレームレートが低下したときにデバイスの正確な状態を再現することは困難です。

もう1つの方法は、アプリケーションの実行中にデータを収集して、フレームドロップの最も可能性の高い原因を特定することです。つまり、アプリケーションがそれ自体をプロファイルすると言うことができます。これを行うには、信号を使用する必要があります。取得したデータは正確ではない場合がありますが、これにより、隔離された環境でプロファイリングデータを取得できます。これは、InstrumentsやDTraceなどの標準ツールを使用した従来のiOSプロファイリングでは不可能です。

デバイス上の信号とプロファイリング

スレッドが何をするかを理解するために、シグナルにシグナルを送信して一時停止します。シグナルにはコールバック関数が登録されています。

 static void _callstack_signal_handler(int signr, siginfo_t *info, void *secret) { callstack_size = backtrace(callstacks, 128); } struct sigaction sa; sigfillset(&sa.sa_mask); sa.sa_flags = SA_SIGINFO; sa.sa_sigaction = _callstack_signal_handler; sigaction(SIGPROF, &sa, NULL);

信号を操作するときに安全な操作は非常に限られています。たとえば、メモリの割り当ては安全な操作ではないため、シグナルハンドラで行うことは、現在のスタックトレースをキャプチャすることだけです。

信号トリガー

信号を設定したら、信号をトリガーするメカニズムが必要です。このストリームを追跡しようとしているため、これをメインスレッドから送信することはできません。 GCDは、実行の流れを制御するための優れた抽象概念です。ただし、実行ユニットをサポートする標準メカニズムである送信元は、10ミリ秒ごとの一時的な解像度で実行されます。 NSThreadは、より高い時間分解能で必要な粒度を提供します。

メインスレッドの負荷が大きくなり、その結果、フレームレートが低下すると、プロセッサの実行時間のほとんどを消費します。残念ながら、これは、メインスレッドがすべての労働集約的な操作を完了したときにレポートスレッドが起動されることを意味します。この問題を回避するために、レポートスレッドにメインスレッドよりも高い優先度を与えます。これにより、メインスレッドが可能な限りビジーである場合でも、トレースをキャプチャできます。

 _trackerThread = [[NSThread alloc] initWithTarget:[self class] selector:@selector(_trackerLoop) object:nil]; _trackerThread.threadPriority = 1.0; [_trackerThread start];

パフォーマンス測定ではよくあることですが、測定行為はアプリケーションに影響を与え、アプリケーションのパフォーマンスに追加の影響を与える可能性があります。 iPhone 4Sでのキャプチャのトレースには約1マイクロ秒かかります。16ミリ秒しかない場合は、かなり時間がかかるように思われます。さらに、メインスレッドを中断する（信号を送信する）動作により、スレッド間でコンテキストスイッチがより多く生成され、アプリケーション全体の速度が低下する可能性があります。

したがって、どうしても必要な場合にのみ理想的な測定ポリシーを選択することが重要です。私たちの場合、測定の際にいくつかの最適化を行いました。たとえば、ユーザーがスクロールしたときにのみ信号を送信する必要があります。私たちが行った別の変更は、従業員のみが使用する内部アセンブリでのみパフォーマンスを測定することです。そのため、測定はプログラムの公開バージョンに影響しません。

レポートとシンボル化

トレースがキャプチャされた後、デバイスでこのデータを収集し、バッチモードでサーバーに送信します。もちろん、トレースは読み取り不可能です-アドレスのコレクション-シンボル化する必要があり、そのためのツールがいくつかあります。 Apple Atos API、Google Breakpad、およびatosl Facebookはその例です。シンボル化後、データ視覚化ツールを使用してコールスタックを集約し、スクロールの効率を引き続き向上させながら、回帰を防ぐための取り組みに焦点を当てるシステムの部分を特定します。

以下は、Facebookアプリケーションの2つのバージョンのプロセッサ消費量を示す例です。

これを試して

この戦略により、リリースバージョンに到達する前に非常に多くのリグレッションを検出できました。この実装のサンプルをGitHubに投稿しました。それがあなたのプロジェクトで役立つことを願っています。

続きを読む

EDISON Softwareのポートフォリオには、Androidの開発に関連する8つのプロジェクトとiOSの開発に関連する4つの主要なプロジェクトが含まれています。

iOSアプリのパフォーマンスのオーバークロック