モバイルアプリのインターフェイスは製品の顔です。インターフェイスの応答性が高いほど、製品の喜びは大きくなります。ただし、アプリケーションの使用に対する満足度は、主にその機能の量に依存します。タスクの数と複雑さが増すにつれて、より多くの時間が必要になります。アプリケーションのアーキテクチャがすべてがメインスレッドで実行されると想定している場合、ビジネスロジックのタスクは、インターフェースのレンダリングタスクと時間の経過とともに競合し始めます。このアプローチでは、遅かれ早かれスクリプトが必然的に検出され、その実行はアプリケーションの固着につながります。この惨劇と戦うために、3つの根本的に異なるアプローチがあります：

問題シナリオの実行に関係するアルゴリズムとデータ構造の最適化。
メインスレッドから問題のあるシナリオを削除します。
実際のユーザーインターフェイスレンダリングを除き、すべてのアプリケーション機能のメインスレッドからの削除。

SchedulableObjectパターンを使用すると、3番目のシナリオを正確に実装できます。ネコの下では、最初の2つのアプローチと比較した場合の長所と短所だけでなく、Swiftでの実装例を含むその部分も考慮されます。

問題の声明

1秒間に少なくとも60回更新できるこのようなインターフェイスはスムーズであると見なされます。これらの図は、反対側からも表示できます。

各イベント処理サイクルには16.7ミリ秒で完了する時間が必要であることがわかりました。ユーザーが10ミリ秒で描画できるウィンドウを監視するとします。つまり、すべてのビジネスロジックタスクは6.7ミリ秒で完了する必要があります。

例として、クラウドにファイルを追加するビジネスロジックを考えます。これは多くの段階で構成されており、この記事の文脈ではその本質は私たちの興味を引くものではありません。

重要なことは、それらがすべて一緒に2.6ミリ秒かかることです。 1つのファイルを追加して、ビジネスロジックの作業に割り当てられた最大時間を分割すると、3が得られます。したがって、このシナリオを実行するときにアプリケーションが応答性を維持したい場合、一度に3つ以上のファイルを追加することはできません。ユーザーにとっては幸いですが、開発者にとっては残念なことに、一度に3つ以上のファイルを追加する必要があるクラウドアプリケーションの場合があります。

上記のスクリーンショットはそれらのいくつかを示しています：

デバイスのシステムギャラリーからのファイルの複数選択。
ギャラリーから新しいファイルを自動的にダウンロードします。

現時点では、アプリケーションの長時間の中断を避けるために、スタートアップサービスによるダウンロードのためにキューにファイルを追加する速度は、恥ずべき定数の方法によって人為的に制限されています。以下にそのうちの2つを示します。

//     static uint const kMRCCameraUploaderBatchSize = 1000; static NSTimeInterval const kMRCCameraUploaderBatchDelaySec = 5;

これらのセマンティクスは次のとおりです。新しい写真をギャラリーでスキャンした結果に応じて、サービスはそれらを5秒間隔で1000個以下のバッチでダウンロードキューに追加する必要があります。しかし、この制限があっても、5秒ごとに1000 * 2.6 ms = 2.6秒のハングが発生します。ビジネスロジックの帯域幅の人為的な制限は、SchedulableObjectパターンに注目する必要があることを示すまさにその症状です。

SchedulableObjectとアルゴリズム

問題を解決するためにアルゴリズムとデータ構造を最適化する問題を解決してみませんか？私は、より良いアプリケーションに値する忍耐力で、すべてが本当に悪くなったとき、アップロードキューに写真を追加する特定の手順を最適化します。ただし、これらの努力の可能性は意図的に制限されています。はい、何かをひねってパックのサイズを2から4千個に増やすこともできますが、これは根本的に問題を解決しません。第一に、最適化のためには、その効果全体を排除するデータストリームが必ず存在します。クラウドに関連して、これはギャラリーに2万枚以上の写真があるユーザーです。第二に、管理者は間違いなくスクリプトをさらにインテリジェントにすることを望みます。これは必然的にロジックの複雑化につながります。以前に実行した最適化を最適化する必要があります。第三に、スループットが人為的に制限されるシナリオはロードだけではありません。ボトルネックをアルゴリズムで調整するには、各シナリオに個別のアプローチが必要です。さらに悪いことに、「パフォーマンス」属性は、私の意見では「サポート」と呼ばれる別のより重要なアンタゴニストです。多くの場合、必要なパフォーマンスを実現するには、アルゴリズムのさまざまなトリックに進むか、より複雑なデータ構造を選択するか、その両方が必要です。クラスのパブリックインターフェイス、または少なくともその内部実装のいずれにおいても、いずれの選択もマイナスに減速することはありません。

別のスレッドでのSchedulableObjectとスクリプトの割り当て

各シナリオが個別のストリームに分離することの適切性について独自の決定を行うアプローチの欠点を考慮してください。この目的のために、特定のビジネスアプリケーションのアーキテクチャの進化を追跡し、「ブレーキ」問題を解決するためにこの原則に導かれます。ここではスレッドが特に興味深いため、オブジェクトのメソッドが呼び出されるコンテキストでは、スレッドはそれぞれ独自の色でエンコードされます。最初は、重いシナリオがまだ登場していない場合、すべてがメインスレッドで発生するため、すべての接続とエンティティは同じ青色になります。

オブジェクトの1つが非常に多くの時間を消費し始めたシナリオが現れたとします。このため、ユーザーインターフェイスの応答性が低下し始めます。問題のあるデータフローを太い矢印で示します。

リソースを集中的に使用するクラスをリファクタリングしないと、別の赤いストリームでそのクラスを呼び出すことはできません。

その理由は、クライアントが1つではなく2つであり、2つ目がメインの青いスレッドから呼び出しを行っているためです。これらの呼び出しがオブジェクトの共有状態を変更すると、データ競合の古典的な問題が発生します。それから保護するには、スレッドセーフな方法で赤いオブジェクトを実装する必要があります。

プロジェクトが進行するにつれて、別のコンポーネントがボトルネックになります。幸い、彼にはクライアントが1つしかなく、スレッドセーフな実装は必要ありませんでした。

このアプローチをマルチスレッドアーキテクチャの設計に外挿すると、遅かれ早かれ次の状態になります。

少し複雑になると、それは完全に嘆かわしくなります。

コード名Thread-Safe Architectureを使用したアプローチの欠点は次のとおりです。

メソッドまたはクラスのシングルスレッド実装をスレッドセーフに（およびその逆に）タイムリーにリファクタリングするには、オブジェクト間の接続を常に監視する必要があります。
適用されるロジックに加えて、マルチスレッドプログラミングの仕様を考慮する必要があるため、スレッドセーフメソッドを実装するのは困難です。
同期プリミティブを積極的に使用すると、最終的にアプリケーションの速度がシングルスレッド実装よりも遅くなる可能性があります。

SchedulableObjectパターンの原理

サーバー、デスクトップ、さらにはAndroid開発の世界において、重いビジネスロジックは、多くの場合、個別のプロセスに分離されます。各プロセス内のサービス間の相互作用はシングルスレッドのままです。さまざまなプロセスのサービスは、さまざまなプロセス間通信メカニズム（COM / DCOM、Corba、.Net Remoting、Boost.Interprocessなど）を使用して互いに対話します。

残念ながら、iOS開発の世界では、1つのプロセスのみに制限されており、現状のままではこのアーキテクチャに適合しません。ただし、別のプロセスを別のスレッドに置き換え、プロセス間相互作用のメカニズムを間接呼び出しに置き換えて、ミニチュアで再現できます。

より正式には、変換の本質は次のとおりです。

1つの個別のワークフローを開始します。
イベント処理サイクルとそれにメッセージを配信するための特別なオブジェクトであるスケジューラ（英語のスケジューラから）に関連付けます。
各可変オブジェクトをスケジューラーの1つに関連付けます。ワークフロースケジューラに関連付けられるオブジェクトが多いほど、メインスレッドがその主な責任であるユーザーインターフェイスのレンダリングに要する時間が長くなります。
プランナーとの関係に応じて、オブジェクトが相互作用する正しい方法を選択します。スケジューラが一般的な場合、直接的なメソッド呼び出しによって相互作用が発生し、そうでない場合は、特殊なイベントの送信を介して間接的に発生します。

提案されたアプローチは、すでにiOSコミュニティで採用されています。これが、Facebookの人気のあるReact Nativeフレームワークの高レベルアーキテクチャの外観です。

すべてのJavaScriptコードは個別のスレッドで実行され、ネイティブコードとの対話は、非同期ブリッジを介してメッセージを送信することによる間接的な呼び出しを通じて行われます。

SchedulableObjectパターンコンポーネント

SchedulableObjectパターンは、5つのコンポーネントに基づいています。以下では、それらのそれぞれについて、その内部構造を最も明確に示すために、責任範囲が決定され、素朴な実装が提案されます。

イベント

iOSのイベントの最も便利な抽象化は、必要なオブジェクトメソッドが呼び出されるブロックです。

 typealias Event = () -> Void

イベントキュー

キュー内のイベントは異なるスレッドからのものであるため、キューにはスレッドセーフな実装が必要です。実際、アプリケーションコンポーネントからのマルチスレッド開発のすべての困難を処理するのは彼女です。

 class EventQueue { private let semaphore = DispatchSemaphore(value: 1) private var events = [Event]() func pushEvent(event: @escaping Event) { semaphore.wait() events.append(event) semaphore.signal() } func resetEvents() -> [Event] { semaphore.wait() let currentEvents = events events = [Event]() semaphore.signal() return currentEvents } }

メッセージ処理サイクル

キューからのイベントの厳密な順次処理を実装します。コンポーネントのこのプロパティにより、コンポーネントを実装するオブジェクトへのすべての呼び出しが、厳密に定義された1つのスレッドで行われます。

 class RunLoop { let eventQueue = EventQueue() var disposed = false @objc func run() { while !disposed { for event in eventQueue.resetEvents() { event() } Thread.sleep(forTimeInterval: 0.1) } } }

iOS SDKには、このコンポーネントの標準実装であるNSRunLoopがあります。

流れ

メッセージ処理ループのコードが実行されるオペレーティングシステムのカーネルオブジェクト。 iOS SDKの最低レベルの実装はNSThreadクラスです。実用的には、NSOperationQueueやGrand Central Dispatchのキューなどの高レベルのプリミティブを使用することをお勧めします。

プランナー

目的のキューにイベントを配信するメカニズムを提供します。クライアントコードがオブジェクトメソッドを実行するメインコンポーネントであるため、SchedulableObjectマイクロパターンとSchedulable Architectureマクロパターンの両方に名前を付けます。

 class Scheduler { private let runLoop = RunLoop() private let thread: Thread init() { self.thread = Thread(target:runLoop, selector:#selector(RunLoop.run), object:nil) thread.start() } func schedule(event: @escaping Event) { runLoop.eventQueue.pushEvent(event: event) } func dispose() { runLoop.disposed = true } }

SchedulableObject

間接呼び出しの標準インターフェイスを提供します。ターゲットオブジェクトに関しては、以下の例のように集約として機能し、 POSSchedulableObjectライブラリのように基本クラスの両方として機能します。

 class SchedulableObject<T> { private let object: T private let scheduler: Scheduler init(object: T, scheduler: Scheduler) { self.object = object self.scheduler = scheduler } func schedule(event: @escaping (T) -> Void) { scheduler.schedule { event(self.object) } } }

すべてをまとめる

以下のプログラムは、コンソールでコンソールに入力された文字を複製します。メインスレッドから引き出したいビジネスロジックの層は、Assemblyクラスによって表されます。次の2つのサービスへのアクセスを作成して提供します。

プリンターは、コンソールに供給する行を印刷します。
PrintOptionsProviderを使用すると、プリンターサービスを構成できます。

 // // main.swift // SchedulableObjectDemo // class PrintOptionsProvider { var richFormatEnabled = false; } class Printer { private let optionsProvider: PrintOptionsProvider init(optionsProvider: PrintOptionsProvider) { self.optionsProvider = optionsProvider } func doWork(what: String) { if optionsProvider.richFormatEnabled { print("\(Thread.current): out \(what)") } else { print("out \(what)") } } } class Assembly { let backgroundScheduler = Scheduler() let printOptionsProvider: SchedulableObject<PrintOptionsProvider> let printer: SchedulableObject<Printer> init() { let optionsProvider = PrintOptionsProvider() self.printOptionsProvider = SchedulableObject<PrintOptionsProvider>( object: optionsProvider, scheduler: backgroundScheduler); self.printer = SchedulableObject<Printer>( object: Printer(optionsProvider: optionsProvider), scheduler: backgroundScheduler) } } let assembly = Assembly() while true { guard let value = readLine(strippingNewline: true) else { continue } if (value == "q") { assembly.backgroundScheduler.dispose() break; } assembly.printOptionsProvider.schedule( event: { (printOptionsProvider: PrintOptionsProvider) in printOptionsProvider.richFormatEnabled = arc4random() % 2 == 0 }) assembly.printer.schedule(event: { (printer: Printer) in printer.doWork(what: value) }) }

必要に応じて、コードの最後のブロックを簡略化できます。

 assembly.backgroundScheduler.schedule { assembly.printOptionsProvider.object.richFormatEnabled = arc4random() % 2 == 0 assembly.printer.object.doWork(what: value) }

スケジュール可能なオブジェクトと対話するためのルール

上記のプログラムは、スケジュール可能なオブジェクトと対話するための2つのルールを示しています。

同じスケジューラーがオブジェクトのクライアントと呼び出されたオブジェクトに関連付けられている場合、メソッドは通常の方法で呼び出されます。そのため、PrinterはPrintOptionsProviderと直接通信します。
オブジェクトのクライアントと呼び出されたオブジェクトに異なるスケジューラが関連付けられている場合、イベントを送信することで間接的に呼び出しが行われます。上記の例では、whileループはユーザー入力を読み取り、アプリケーションのメインスレッドで実行するため、ビジネスロジックオブジェクトに直接アクセスできません。彼は間接的に彼らとやりとりします-イベントを送ることを通して。

アプリケーションの完全なリストは、ここで入手できます。

SchedulableObjectパターンの欠点

パターンのすべての優雅さに対して、それは暗い側面も持っています：高侵襲性。このデモアプリケーションのように、初期設計中にSchedulable Architectureが敷設された場合はすべて順調であり、生命が既存の膨大なコードベースにそれを埋め込むことを余儀なくされた場合、ケースは完全に異なる順番を取ります。パターンのNスレッドの性質により、2つの厳しい要件が生じ、広範囲に及ぶ結果が生じます。

要件No. 1：不変モデル

スレッド間を移動するすべてのエンティティは、不変またはスケジュール可能でなければなりません。そうでなければ、その状態の競争的変化の問題の全範囲が遅くなることはありません。現在、不変モデルオブジェクトの使用には明確な傾向が見られます。その最前線には、ビジネスロジックをメインストリームから分離する必要性に直面している企業があります。このトピックに関する最も印象的な資料のリストを次に示します。

しかし、今日のコードベースでは、可変モデルに遭遇する可能性があります。さらに、Core DataやRealmなどの永続化フレームワークを使用する場合、readwriteプロパティはそれらを更新する唯一の方法です。 Schedulable Architectureの導入により、それらを放棄するか、モデルを操作するための特別なメカニズムが提供されます。したがって、Realmチームは以下を提供します。したがって、Realmの唯一の制限は、スレッド間でRealmオブジェクトを渡すことができないことです。別のスレッドで同じデータが必要な場合は、他のスレッドでそのデータを照会するだけです。 Core Dataには回避策もありますが、私の意見では、これはすべて非常に不便であり、「側面にあるもの」のように見えます。これを設計段階でアーキテクチャに組み込むことは絶対にしたくないです。 Facebookが「 iOSでニュースフィードを50％近く高速化する」という記事で、Core Dataの放棄を発表しました。 LinkedInは、Core Dataの同じ欠点を引用して、永続データストレージのフレームワークを最近導入しました。「 Rocket Dataは、速度と安定性が保証され、可変モデルではなく不変モデルで動作するため、Core Dataに適したオプションです。」

要件2：サービスのクラスター

別のストリームへの移行は、オブジェクトのクラスター全体がこれに対応できる場合にのみ意味があります。さまざまなシナリオに参加しているサービスがさまざまなストリームに存在する場合、それらの間の豊富な間接呼び出しにより、信じられないほどの割合のコードブラストが引き起こされます。

現在、Mail.Ru Cloudでは、製品開発の一環として、メインストリーム以外のビジネスロジックを徐々に準備しています。そのため、リリースごとに、SchedulableObjectパターンを実装するサービスの数を増やしています。それらの数が「困難な」シナリオの実装に十分なクリティカルマスに達するとすぐに、ワークフロースケジューラが同時に設定され、ビジネスロジックによるブレーキは過去のものになります。

POSSchedulableObjectライブラリ

POSSchedulableObjectライブラリは、Mail.Ru Clouds iOSアプリケーションのSchedulable Architectureパターンを完全に実装するための重要な要素です。コードベースはシングルスレッド状態から2スレッド状態に移行する準備が整ったばかりですが、リファクタリングは既に有益です。 POSSchedulableObjectはすべての管理対象オブジェクトの基本クラスとして使用されるため、そのプロパティの一部は現在アクティブに使用されています。重要なものの1つは、「敵」であるストリームからオブジェクトメソッドへの不正な直接呼び出しを追跡することです。 1回または2回以上POSSchedulableObjectが、特定のワークフローからビジネスロジックサービスにアクセスしようとしているという断定を通知しました。一般的な理由は、iOS 9でiOS SDKからのクラスメソッドの完了ブロックがアプリケーションのメインスレッドで作動する場合、iOS 10でこのコントラクトが変更されないという無駄な希望です。

不正なストリームからの呼び出しを検出するメカニズムの実装の特定の機能は、POSSchedulableObjectクラスとは別に使用できることです。このプロパティを使用して、ViewControllersへのメソッド呼び出しがメインスレッドでのみ発生することを確認しました。次のようになります。

 @implementation UIViewController (MRCApp) - (BOOL)mrc_protectForMainThreadScheduler { POSScheduleProtectionOptions *options = [POSScheduleProtectionOptions include:[POSSchedulableObject selectorsForClass:self.class nonatomicOnly:YES predicate:^BOOL(SEL _Nonnull selector) { NSString *selectorName = NSStringFromSelector(selector); return [selectorName rangeOfString:@"_"].location != 0; }] exclude:[POSSchedulableObject selectorsForClass:[UIResponder class]]]; return [POSSchedulableObject protect:self forScheduler:[RACTargetQueueScheduler pos_mainThreadScheduler] options:options]; } @end

ライブラリの詳細については、 GitHubのリポジトリの説明を参照してください。 iOS 7のサポートを停止するとすぐに、Swiftのバージョンをすぐに処理します。その概要は、パターンのコンポーネントのリストの一部として示されました。

おわりに

SchedulableObjectパターンは、メインスレッドからアプリケーションのビジネスロジックを取り出すための体系的なアプローチを提供します。結果として生じるスケジューリング可能なアーキテクチャは、2つの理由でうまくスケーリングします。まず、ワークフローの数はサービスの数に依存しません。次に、マルチスレッド開発の複雑さ全体が、アプリケーションクラスからインフラストラクチャクラスに移行します。アーキテクチャには、興味深い隠れた可能性もあります。たとえば、1つのスレッドではなく、複数のスレッドでビジネスロジックを取り出すことができます。それらのそれぞれの優先順位を変更することにより、マクロレベルで、オブジェクトの各クラスターによるシステムリソースの使用強度を変更します。これは、たとえば、アプリケーションにマルチアカウントを実装する場合に役立ちます。現在のアカウントのビジネスロジックメッセージ処理サイクルが実行されるストリームの優先度を上げることにより、ユーザーに最も関連性のあるタスクの実行を強化できます。

SchedulableObjectパターンを使用して、ビジネスロジックを個別のスレッドに分離する