iPhone、遅れないでください。 パート1：開業医向けのマルチスレッド

私の名前はマキシムです。私は7年以上にわたってiOS開発を行っているアルコール依存症です。

応募者をきっかけに、企業のモバイル開発者とのインタビューを定期的に行っています。

候補者の中には、Skypeのインタビューで水ギセルを吸うショット、外出先でグーグルの質問をする、3ヶ月の経験のためにZP 180kを望む、通りで（適切な用語で）私を停止したかのように振る舞うショットなどがあります。

しかし、ほとんどの場合、適切なミドルスペシャリストでさえ共通のギャップがあります。それは、iOSでの非同期タスク実行とハードウェアアクセラレーションの原則の理解不足です。

この記事では、iOSでのマルチスレッドの適用について簡単な言葉で説明することにしました。そのため、最初に読んだ後、実際に得た知識を簡単かつ完全に理解することができました。

（読むのが面倒な場合は、 ビデオが添付されます）

2つのマテリアルがあります。1つはマルチスレッド専用、もう1つはハードウェアアクセラレーションに関するものです。完全にスムーズなインターフェイスを得るために、CPUとGPUの間で負荷を均等に分散する方法です。

テクニックの適用方法を学ぶだけでなく、Zenを理解することに興味がある人のために、素晴らしい記事があります。 確かに、それはまだSwift 3用ですが、本質はこの期間中に変更されていません。

簡単な実用理論

実践理論は、それなしでは結果志向の実践者ではなく、単に教育のない野av人である理論です。

そして、非同期性、スレッド、その他のトリックについて空想を始める前に、次の質問に答える必要があります。なぜ何かを並列化する必要があるのですか？ これがメインストリームです。すべてをオンにしてみませんか？ 私は多くの明白な答えを期待しています：すべてが遅くなるからです、エール。

そして、メインストリームは何がそんなに特別なのですか？ その排他性は、外部からアプリケーションと対話することです：タッチ処理、通知、システムメッセージなど。

そして、私たちの場合の主なことは、レスポンダーチェーン全体がメインスレッドでハングすることです。
UIApplication-> UIWindow-> UIViewController-> UIView。



すべての画面タップ、すべてのユーザーインタラクションは、まさにそこにあります。

しかし、大丈夫、メインスレッドでクリックが処理されるようにしましょう。しかし、Apple、くそ、クリントイーストウッドのように、両手で描画できないのはなぜですか。

はい。複数のストリームの通信では、同期のためにギズモの厚いレイヤーで自分をカバーする必要があります。これは、不要なジャンクであり、すでに乏しいリソースへのプレッシャーです。 Appleは、メインスレッドの非人道的な取り扱いによって引き起こされるあらゆる種類のエキゾチックなバグを回避するために、メインスレッドチェッカーを導入しました。

一般に、最初のルールはUIのメインスレッドとメインスレッドのUIを残すことです。

さて、残りはどこでしますか？

IOSには、スレッド、posixスレッド、gcd、操作キューなど、これらの目的のための多くのツールがあります。
それぞれに独自のアプリケーションがありますが、日常生活では、サーバーへの移動、持ち込み、保存、表示、十分なgcdおよび操作キューのタイプの通常のタスクで構成されています。

GCDは、並列タスク用のAppleライブラリです。 これは、実行された操作（タスク）とこれらの同じ操作を含むキューで構成されます。 タスクを含む最も一般的なFIFOコレクション。 もちろん、まだ多くのオプションがありますが、まだ必要ありません。

NSOperationQueue-同じキュー、高レベルおよびOOP指向のみ。 しかし、実際には、gcdの単なる美しいラッパーであり、以前は機能的な利点はありませんでした。

ほとんどの場合、どちらを選択するかは好みによって異なりますが、まれな例外があります。 あなたにとってより便利なもので作業してください。 個人的には、gcdのほうが扱いやすく、追加のオーバーヘッドがないため、gcdを好みます。

ちなみに、NSOperationQueueはもはやGCDに基づいていないが、iOS向けに特別に再設計されているため、より速く/より高く/より強くなるという開発者の間では、このような不明瞭さが頻繁に発生します。 しかし、これは事実ではありません。リンゴを引用させてください： Apple ：



したがって、GCDに対するNSOperationQueueの特別な利点はありません。

GCDおよびNSOperationQueueの優先度

主なコンポーネントを見ていきましょう。

各キューには、リソースを受け取る優先度などの概念があります。 これはサービス品質と呼ばれ、最もよく頭字語「qos」またはサービス品質で使用されます。
優先度が高いほど、このキュー内のタスクにより速く、より多くのCPU時間が割り当てられます。 はい、はい、それも高速です、あなたは正しいと聞きました。 システムはプロセッサの覚醒を最適化し、それによりエネルギーを節約できます。 これは、ユーザーがバッテリーを使い果たしたときに低電力モードで作業するときに覚えておくと便利です。

私は本当にYandex.Taxiの作者に調べてもらいたいです。 結局のところ、このような簡単な方法でバッテリーを節約でき、iPhoneで「ビットコインマイニング」を手配する必要はありません。

優先順位は何ですか？ それらのいくつかがあります、そして、それが無限に傷つけないように、我々はすべてを覚えていなければなりません。 そして、多くの人は、それはおそらくどこにも聖化されていないと言っており、それはまったく必要ではありません。

そのため、優先順位はuserInteractive 、 userInitiated 、 default 、 utilityおよびbackgroundです。

Mainは優先順位ではなく、メインスレッドの個別のキューであるため、Mainは考慮されません。 ちなみに、彼女には優先順位があります：userInteractive。 そのため、たとえば、userInteractive優先度の別のキューで写真を使用してシャーマニズムを実行すると、リソースの競合が始まるため、偽の遅延は発生しません。 メインで実行する場合よりも小さな問題ですが、遅延が不安定になるため、デバッグが難しくなります。
（まだ特定されていませんが、これは一般的に野avであり、遭遇することはほとんどありません）

操作がキュー間でどのようにスローされるかを正確に理解したい場合は、上記のリンクを引用しました。

それで、いつ何を使うのですか？

• userInteractive-まったく適用する必要はありません。 上で書いたように、メインスレッドによって予約された舞台裏です。 Appleは、アプリケーションの範囲を次のように定義しています。ユーザーとの対話に不可欠な操作で、1秒もかかりません。 UIにとってささいなことのようですね。 実際には、1つのタスクしかありませんでした。このタスクは、インターフェースの速度と競合し、外科的精度を必要とするはずでしたが、gcdで解決されませんでした。 要するに、userInteractiveはAppleの神々のためのものであり、私たちのような単純な働き者ではありません。
• userInitiated-即時の結果を必要とするローカル操作。 たとえば、次の画面に移動する前に何かをデータベースに保存します。 しかし、同時に、それはブロッキングUIではありません。 特に、ローカルオペレーションであることに注目しました。 ネットワークは含まれていません。
  
  画面の中央でダウンロードインジケータをオンにし、コンテンツを表示するために緊急に何かをする必要があるとします。 明らかに、guiが失敗し始めるため、これはメインスレッドでは実行できませんが、インターフェイス全体から1つのツイストターンが発生するため、バックグラウンドに深く入りすぎても意味がありません。 この場合、userInitiatedが使用されます。
• デフォルト -デフォルトの優先順位。 Appleは、使用する必要がないと述べているドキュメントで意見が異なりますが、WWDCでは、これは写真やその他のネットワーク通信をダウンロードするための最優先事項であると反対しています。 さまざまなQoSを試してみたところ、アプリケーションのユーザーの認識に影響を与える画像または小さなファイルをダウンロードするには、デフォルトが最適であると言えます。 utlity（次のレベル）とデフォルトの違いは、画像を操作するとき、特にプリレンダリングするときに特に感じられます。 デフォルトははるかに高速に実行されますが、同時にリソースのインターフェースと競合しません。 私の推奨事項は、すべてのネットワークビジネスロジックとイメージをデフォルトのままにすることです。
• 実用性 -優先度は高くないが、近い将来必要なもの。 たとえば、巨大なファイルの処理や、データベースでの複雑な操作、メディア変換など。 簡単に言えば、アプリケーションの緊急タスクを実行する必要があるが、数秒余分に待機する場合、その役割は果たしません。 ちなみに、このような操作は、低電力モードで作業するときにバックグラウンドモードに移行する最初の候補です。
• 背景はすべての中で最も野菜的なモードです。 彼らが言うように、人生を知っていて、急いでいない人のために。 エネルギーを節約しながら、または非常に重い操作のために使用する必要があります。 シックファイル、バックアップなどの読み込みのタイプ。 そして、ユーザーが突然低電力モードをオンにし、操作がすでにバックグラウンドの優先順位にあった場合、多分すぐにナフィグでしょうか？

現実世界で実践する

アプリケーションについて言えば、何らかのタスクにサードパーティのフレームワークを使用する場合、ほとんどのツールは、呼び出されたキューで作業を行うか、明示的な言及をサポートします。 5分以内に優先順位を明示的に示す方法を見つけることができなかった場合、単純に単純にdispatch_asyncで操作をラップし、心配する必要はありません。

主な注意点は、多くの場合、いくつかの歴史的な理由からメインスレッドでコールバックが呼び出されることです。 場合によっては、デフォルトのQoSでリクエストを作成し、完了ブロックでデータベースに保存をプルして、すでに家にいることを忘れます。 そして、このアプリケーションがかろうじて乗る理由をカブにひっかきます。

そのため、確実性がない場合は、ブロックにブレークポイントを設定し、コールスタックを調べます。 そのような場合は、プロファイラーを使用して遅延を検索するよりも、再確認する方が適切です。 インタビューでプロファイラーについて質問するのが大好きです。

メインストリーム：



その他：



一般に、アクションがどのフローにあるかに注意を払うことが不可欠です。 後で多くの神経と時間を節約してください。

非同期に遭遇したときに生じる別のニュアンス：別々の操作でどれだけ実行する必要がありますか？ 国境はどこですか？ その意味は何ですか？

哲学的に、何かが非同期である場合、非同期にすることができます。 しかし、より実用的にアプローチします。アプリケーションが多くの1秒前の操作で構成されている場合、これらのささいなことを大きなタスクで確実に組み合わせることができるかどうかをまず考えるべきでしょうか くしゃみごとに別々の操作を行うと、ラグが増えるだけです。

たとえば、ストアに製品がある特定のテーブルがあります。 各セルは、価格、アバター、複数行の説明です。 価格はローカライズ（ルーブル記号+フォーマット）、説明も（特定の言葉の接頭辞があります）。 原則として、ローカライズされた文字列のコンパイルは、対応するラベルに値を設定した瞬間に行われます。

しかし、これは非同期で実行できますか？ 最初にバックグラウンドでローカライズしてから、ラベルに配置します。
だから、このくだらない決断。 製品アイテムごとに最適なオプションは、サーバーへのリクエストの直後にローカライズされた値をコンパイルし、エンティティの対応するフィールドにデータを書き込むことです。

モデルに書き込むことにより、これらの同じフィールドのサイズを事前に計算することも特に役立ちます。 はい、これは異常に見えますが、これは正常です。

私たちのチームは、サーバーからデータを受信するときに明らかにセルの高さを計算し、それらをデータベースに保存するという、このような手法を長い間採用しています。 または、データベースを使用しない場合、これが以前およびバックグラウンドでのみ発生する場合、配列に。 フリーズに感心するよりも、ユーザーに余分な数秒間スピンするスピナーを見せることをお勧めします。

そして、ストレージの量を心配する必要はありません。 現在の現実では、iPhone上のメモリは安価なリソースであり、プロセッサ時間は高価です。 覚えておく価値があります。

結論 ：インターフェースのデータを事前に準備します。 とても安くて美しい。

そして、あなたはすでに半分を忘れてしまったので、ナンセンスを書くのをやめるためにあなた自身に尋ねるべき質問があります：

1. バックグラウンドで事前に操作を行い、結果をキャッシュすることは可能ですか？
2. どの優先順位がタスクに最適ですか？
   
   • userInitiated ：軽度および緊急のアクション
   • ユーティリティまたはデフォルト ：ネットワークタスク、レンダリング
   • 背景 ：長いプロセス
3. どのスレッドでコールバックが呼び出されますか？ メインスレッドに余分な負荷がかかりますか？ （ブレークポイントの呼び出しスタックで簡単に確認できます）

次のシリーズでは、ハードウェアアクセラレーションについて説明します。 怖いですが、簡単です。

PSビデオに関するフィードバックに感謝します。 最初の経験は、毎分文字通り1時間かかりました。