ブルーシフトまたはiOSアプリケーションの起動時間を最適化します。 ヤンデックス講義

アプリケーションをダウンロードすると、1、2秒は許容できるようです。 しかし、あなたのプログラムが頻繁に使用され、競合他社で使用されると、OS自体のメーカーのアナログが起動時間にさえ影響し始めます。 Yandexの開発者Viktor Bryksin bobermaniacは、Mail.Ruの同僚のオフィスで開催されているCocoaHeadsコミュニティの会議で講演し、iOSアプリケーションをより高速に実行する方法について話しました。





-長い間、Yandex.Browserの開発に従事していました。 実際、このアプリケーションの開始時間の最適化から、私のレポートが生まれました。



ブラウザで解決した問題は、すべてのiOSアプリケーションに共通です。 電話に出て何かを実行すると、おそらく2〜3秒間スプラッシュ画面が表示されます。 私の個人記録保持者は7秒です。アプリケーションを呼び出しませんが、驚くべきことです。あなたが開いて美しい写真を見ているとき、あなたはすでにこのアプリケーションでやりたいことを忘れていました。



ブラウザはこれを買う余裕がありませんでした。 ブラウザには、アプリケーションがすぐに応答することを必要とする多くのシナリオがあります。 ユーザーは、実行中にすばやく、ブラウザを開き、検索行に何かを入力し、回答を取得したり、実行中に何かを読んだりできる必要があります。 おそらく、あなたは走り回っています、地下鉄の通路で、時間に余裕がないので、いくつかの記事をぴったりと始めて読んでいます。



当然のことながら、ブラウザには削除できない機能があります。そのため、ユーザーは製品を使用します。



さらに、競合他社もいます。 そして、私たちの主要な競争相手の1つは、iOSに組み込まれたSafariブラウザです。これは100トンの重さで私たちにかかっており、覚えているなら、WindowsのIEと同じ支配的な位置を占めています。 また、競合する必要があるため、ブラウザの起動時間を常に短縮する必要があります。



かつて、すべての開発者に内在する素朴さでこの問題に取り組みました。 彼らの意見では、何かを最適化するには、プロファイラーと個人的な経験で十分です。



ある時点で、マネージャーが私たちのところに来て、アプリケーションが愚かで、速度が落ち、すべてが悪いと言いました。 開発者は言った-さて、見てみましょう、最適化、すべてがうまくいくでしょう。



最適化。 その結果、アセンブリが完成しました。テストはストップウォッチで行われました。これは、すべてが正しく行われ、どこでも修正されず、すべてが速く起動することを確認する必要があるためです。 ストップウォッチを使用して、彼らは開始時間を測定し、それが短くなったことを確認し、すべてがうまくいきました。



このアプローチはさらに進化しました。 テスターを植えてストップウォッチを与える代わりに、ビデオの使用を開始しました。 最適化の前と後にビデオを撮影し、お互いにオーバーラップし、フレームごとに見て、どのブラウザ要素が表示されるか、どのように反応するか、すべてがうまくいくかどうかを確認しました。



将来、マネージャーはビデオ編集者のように感じました。 彼はチャンスに関連する効果を平準化するために、前に5つのビデオを撮影し、後に5つのビデオを撮影し始めました。 開始時間は火星の天気に依存することがあり、これでは何もできないことが誰もが知っています。



マネージャーはビデオエディターのスキルを習得しましたが、これは役に立ちませんでした。 このアプローチには多くの問題がありました。



まず、すべてが遅くなり始めたときにのみ最適化を思い出しました。 最適化を行い、しばらくするとこれらすべてが低下しました。 誰かが他の変更を加え、新しい機能が登場し、時間が経つにつれて再びすべてが非常に悪くなります。 そして、これを制御するツールがありませんでした。 また、効果を失いたくない場合は、継続的な監視を行う必要があります。 残念ながら、私たちが使用したビデオオプションは、常に使用するのに十分な労力を必要とします。 彼は私たちに合わなかった。



したがって、本日は、何らかの種類の効果を実際に取得し、長期間維持する場合に、起動時間を最適化するプロセスを適切に構築する方法について説明します。



まず、メトリックについて説明します。メトリックがないと、特に最適化などのプロセスはまったく不可能です。



私たちは、他人の経験から自分自身に適応することができたものについて話します。 Fake UIプロジェクトについてお話しましょう-それのおかげで、文字通りユーザーの顔を飛び回り、「私と一緒に仕事をもっと早く」と言うインターフェイスを構築することができました。



ホットスポットの削除について簡単に説明します。 これは、少なくとも1回は最適化を行ったすべての人が少し理解しているトピックです。 多くの問題をもたらした怠zyなサービスと、最終的に得られる評価について。



メトリックから始めましょう。 このレポートから出てくる最初で最も重要なことは次のとおりです。 便利なメトリックがない限り、サポートされる便利な最適化を行うことはできません。 ビデオの例。 マネージャーは動画の統計情報を取得するために多くの時間を費やす必要があり、常に撮影することはできませんでした。 その結果、これが何らかの形で行われ、すべてが失われ、最も重要なことには、この最適化が失われた間隔で見つけることができませんでした。 したがって、写真を撮る頻度が高いほど、私たちにとって良い結果になります。



メトリックは、多くの場合、簡単で理解しやすいものにする必要があります。 ブラウザについては、選択したすべてのメトリックを2つの大きなグループ（プライマリとセカンダリ）に分割しました。 主なものは、ユーザーが直接感じるものであり、ブラウザの感覚に影響を与えるものと、彼が見るものです。 それらは定量的である必要があり、数値を扱うのは簡単です。平方根を加算、減算、減算することもできますが、私は個人的には試していません。 そして最も重要なことは、それらは客観的でなければなりません。 ストップウォッチ付きのテスターの例が示したように、あまりにも多くの確率的要因は、もたらされた改善の効果を示すのではなく、メトリックが窓の外の温度を示し始めるという事実につながります。



基本的な指標は、製品開発プロセスで改善したいものです。 補助メトリックがあります。 これらは、開発者の世界にすでに存在していることを除いて、メインのものと非常に似ています。 これらはユーザーには表示されないものですが、開発者は通常の数よりもはるかに多く、製品で何が起こっているかを通知されます。



Yandex.Browserでは、4つのメトリックを選択しました。 それらのうちの2つは補助的であり、開発者のために存在し、2つはメインです。



これらのメトリックはすべて、ユーザーがアプリケーションアイコンを突いた瞬間から経過する秒数を条件付きで示す数値です。



最初に取るポイントは、Mainが開始する瞬間です。 2つ目は、RootViewControllerがウィンドウ階層に表示され、すぐにビューが表示されるとすぐに。 ViewWillAppearが実行されているポイントを取得します。



3番目のメトリックはViewDidAppearです。 4番目に興味深いのは、ViewDidAppearの最後に、Dispatch Asyncブロックを使用してメインスレッドで実行することです。 そして、それが完成した瞬間、これは4番目のポジションであり、これをUI Readyと呼び、最も重要です。 将来的に頻繁に使用します。 そして、それに関する基本的な見積もりを行います。



これらの各数字の意味について簡単に説明します。 メインは最も理解しやすいものを示しています-これはアプリケーションを起動した瞬間で、画像全体がメモリに起動され、ロード、初期化が行われ、動的にロードされたライブラリに関するすべてがそこにあります。 プロジェクトにロードしたライブラリの効果を示しています。



その後、自然にapplication：didFinishLaunchingWithOptionsが実行されます。 将来使用されるいくつかのサービスが構成され、その後、ViewDidAppearの瞬間が来ます。



したがって、ViewDidAppearの2番目の数字は、構成された独自のカスタムユーザーサービスの効果を示しています。



ViewDidAppearは、メインメトリックが、ユーザーが最終的に画面上で作業しようとしているアプリケーションのインターフェイスを見た瞬間を示しているためです。



そして最後に、UI Ready。 インターフェイスが表示された時点で、メインスレッドで実行する必要がある大量のコードによってブロックされる可能性があります。 このため、ユーザーは見ることができますが、触れることはできません。



メインスレッドをブロックする予定の4番目のUI準備完了メトリックは、最終的にアンロードされるタイミングを示し、ユーザーはアプリケーションと対話できます。



私たちが先送りした主な仮説は、UI Readyメトリックス、つまりユーザーがアプリケーションで作業できる瞬間を減らすと、ユーザーはこれに気づき、それが彼にとって良いことだと理解し、製品をより楽しむことができるということです。 これは、収益率などの製品メトリックが増加することを意味します。 つまり、グラフの相関関係を確認する必要があります。UIReadyの開始時間が短くなり、製品のメトリックが高くなります。



最適化の効果を評価するために、開発者からメトリックを収集します。 開発者が何かを行うとすぐに、そのアセンブリを取得します。プルリクエストがマスターに参加した後、マスターからアセンブリを絶えず収集し、特別なテストスタンドに送信します。 これは通常のMacで、デバイスが接続されているネットワークに接続されています。iOS8ベースのiPad Miniが当時最もブレーキがかかったデバイスでした。 アセンブリがインストールされ、数百回起動します。 4つのすべてのメトリックの数値を取得するたびに、それらを収集し、平均化して特別なスタンドに送信します。そこで、これらの数値から時間の経過に伴う美しい変化のグラフが作成されます。 後でこれらのグラフを表示します。



これらの数値を使用して、プロジェクトに加えている変更が何につながるのかをすばやく理解します。



当然、ユーザーに対してこれを行い、ユーザーメトリックも収集します。 匿名統計の送信を許可したユーザーは、これらの番号を取得して自分自身に送信します。 当然、ユーザーにアプリケーションを200回実行するように依頼することはできませんが、ユーザーの数は基本的にランダム性の影響を排除します。



メトリックが重要であることをご理解ください。 そして、そのようなタスクが発生したとき、あなたはこのアドバイスを受けます。



私たちが他の人々から採用した経験については、まず、同僚のニコライ・リホグルドのレポート 「iOSアプリケーションの起動時間の最適化」を参照したいと思います。



まず、動的ライブラリのロードなど、システムの起動時間に関するものです。最初に述べたように、メインのメトリックはイメージをロードします。 ここではすべてが非常によく説明されています。また、彼のアドバイスを活用し、ブラウザーに動的ライブラリを捨て、すべてが統計的にリンクされています。



当然、Swiftを放棄しましたが、これをすべて行った後もiOS 7が残っていたため、Swiftのサポートはメトリックに大きく影響し、すべての数が大幅に増加しました。 私たちはそれを使おうとしましたが、成長を見て、この考えをすぐに放棄しました。



驚くべきことに、パフォーマンスの向上は、単に未処理のリソースからリソースを転送することを示しただけです。 そして、長い歴史を持つプロジェクトでは、誰もそれを必要としないという事実のために何も触れない場合、プロジェクトに未加工のリソースがまだある場合、これは関連する可能性があり、xcassetsにそれらを転送することをお勧めしますパフォーマンスの向上。



残念ながら、開始時間に悪影響を与えるライブラリがあります。 どうやら、複数の負荷と同様のものがあるという事実のために。 まず、Facebook SDKの使用時にこれに遭遇しました。FacebookSDKでは、遅延読み込みと遅延バインディングを使用しました。このライブラリでは、このライブラリと直接対話せず、Dial Dなどを使用します。



同僚ほどハードコアな人はいません。 多くの美しい写真があります。



ブラウザの最初の問題はカーネルの問題です。 多くの人は、ブラウザーがChromiumコアに基づいていることを知っているか、疑っています。私たちのコードがあり、デスクトップブラウザーとモバイルブラウザーの間を行き来し、多くの機能を提供しますが、それなしではブラウザーはあまり役に立ちません。



iOSバージョンの問題は、iOSのコアがモノリスであることです。 これは大量のコードであり、同時にロードされ、しばらく動作しますが、最終的にロードされて初めてユーザーに何らかの機能を提供できます。



これに耐えることは不可能でした。 ユーザーはすでにインターフェイスを見ているようですが、カーネルは起動せず、インターフェイスはロックされているため、何もできません。



私たちはそれについて何かをすることにしました。



私たちが最初に考えたのは、それを見た場合はどうでしょうか？ カーネルの速度が低下した場合は、破棄するだけで問題はありません。すべて問題ありません。



試しさえしませんでした カーネルが大量の再利用機能を提供する場合、それを捨てることはゼロからそれを書くことを意味することは明らかですが、あなた自身で。 それを行うのは無意味であり、動作するコードを捨てて、動作が悪い別のコードを書きます。



私たちは反対に行きました。 それなしでは何もできないカーネル依存のUIがある場合、ユーザーに別のUIを提供してください。 おそらくすべてができるわけではありませんが、カーネルがなくても完全に動作することができ、アプリケーションをすばやく開いてその中で何かをする必要があるときに、ユーザーはモードに固有のスクリプトのセットを実行できます。



当然、対話型であり、書き込みが可能であり、カーネルがロードされるとすぐに透過的に大きなUIに切り替える必要があります。

_{^{deviantartへのリンク}}

Omniboxのようなコンポーネントの例でこれをどのように行いましたか？



ブラウザは、WebViewとリクエストを入力するためのテキストフィールドで構成されていることを誰もが知っているか疑っています。 当然、これはそうではありません。 要求を入力するフィールドは、Omniboxと呼ばれます。 カーネルは、推測、きれいにフォーマットされたURL、プログレスバーを使用した作業など、多くのものを提供しました。それなしでは、Omniboxはあまり機能しませんでした。 しかし、私たちはユーザーに開始前に何か​​を入力する機会を与えたいと本当に望んでいました。



大きなOmniboxを2つに分けました。 古いOmniboxモデルはまったく同じままで、コアでも機能しました。 次に、完全に切り離された新しいモデルを配置し、キャッシュされたデータを処理し、それらを1つの大きなコンポジットに結合して、カーネルがロードされたかどうかに応じて呼び出しをルーティングしました。



カーネルがロードされるまで、私たちの呼び出しはキャッシュされたOmniboxに行き、そこから答えが来ました。 カーネルが起動するとすぐに切り替えました。



ユーザーがブラウザをアンロードしたときに何かが壊れていると感じないように、再び起動して空のOmniboxを確認しましたが、それがいっぱいだったため、小さなキャッシュを作成しました。 カーネルに依存する大きなOmniboxがこのキャッシュに書き込み、キャッシュされたOmniboxは、上昇するとすぐにこのキャッシュから読み取り、ユーザーにキャッシュの状態を与えました。



シームレスな切り替えをサポートするために、カーネルが最終的に起動したときに、Omniboxのキャッシュ状態を実際に通常と同期させる小さなコンポーネントを作成しました。 そして、ユーザーにとっては、すべてが彼がブラウザを起動したように見え、ブラウザで何かを開始し、ブラウザは機能します。 彼は切り替えの瞬間にさえ気づきません。



同時に、インターフェースははるかに速く起動し始めました。 先ほど言ったように、カーネルの開始前に、UserInteractionEnabled = nullを実行しましたが、いいえ、親愛なるユーザー、あなたは何もしません。 これでUserInteractionが有効になり、問題が残っていることがわかりました。



残念なことに、カーネルに加えて、私たちは独自のサービスを作成しました。 それらのいくつかはカーネルにも依存しており、カーネルが最終的に実行されていることを示すコールバックを購読するのが非常に好きでした。



カーネルが起動した時点で、これらのすべてのサービスは喜んで初期化され、メインスレッドを詰まらせました。その結果、インターフェースがあるため、それとやり取りすることは可能ですが、メインスレッドは詰まり、単一のメッセージは渡されません。



こんな感じでした。 これらの条件付きサービスは2ダースあり、そこで何かを行い、時には多くのことを行いました。 1つまたは2つありましたが、これは問題ではありませんでしたが、機能の数の増加に伴い、それらの数は常に増加していました。



Chromium.performAfterStartup自体は何もしませんでした。Chromium.performAfterStartupはサブスクライブしたすべてのコールバックを取得し、大きなパケットでメインストリームに記録しました。 メインスレッドで20のサービス-残念ながら、何かをしなければなりませんでした。



そのため、すべてのサービスを一度に起動することを拒否しました。 最初に行ったのは、一部のサービスがChromiumの待機を停止し、後日延期されたことです。



基本的に、これはユーザーが必要としないか、すぐに必要としない統計やその他のものに関連するすべてです。 延期できるものはすべて、延期しました。



延期できないサービスについては、一度に1つずつ開始することにしました。メインスレッドにサービスの起動間隔で何かをクランクする機会を与えるだけです。 したがって、ユーザーは遅れたインターフェースさえ持っていましたが、同時に彼は彼と対話する機会がありました。 そして彼は少し幸せに近づいた。



あいにく、怠zyなサービスが登場したため、幸福は短命でした。



遅延サービスの問題は、起動時間が定義されていないことです。 一方では、これは問題ではありませんが、遅延サービスを使用できるため、本当に必要な時点までその起動を延期する必要があるため、それらの利点です。 しかし、怠referringなサービスは、お互いを参照し、互いに触れ合い、巨大なバンドルに集まり、群衆の中を走り始めます。この場所には、この怠serviceなサービスに誤って触れた場合に別の場所に移動できるホットスポットがあります。 , , — , , .



, , . , - , .



, , , . , - . , , .



, , , Promise. , .



.



. , . — . ? , , , , - . , , — , , - — , 7- .



50%, 70% 90%. , .



, , . , .



, .



, . , . , , , , .



, .



Swift , . , Main. , — , , Swift. Swift, .



. , . , : , , pull request, . , . , , , , , . - - , , .



結論として、最初の指標、そして次に最適化のみ。メトリックがなければ、すべての最適化は遅かれ早かれ失われ、これは間違いなくあなたとあなたのユーザーが望むものではありません。同じ作業を数回行うのは無意味であり、ユーザーはアプリケーションがすぐに起動するのが本当に好きで、7秒間スプラッシュ画面を見たくないのです。ありがとう