iphone - メイン スレッドで UIKit 操作を実行する必要があるのはなぜですか?

Question

複数のスレッドを使用して UI 操作を実行できない理由を理解しようとしています。これは、OpenGL や cocos2d などの他のフレームワークでも必要ですか?

C# や JavaScript などの他の言語はどうですか? Google で検索してみましたが、人々は私が理解できない POSIX スレッドについて言及しています。

Answer 1

から: https://www.objc.io/issues/2-concurrency/thread-safe-class-design/

UIKit をスレッドセーフにしないのは、Apple 側の意識的な設計上の決定です。スレッドセーフにしても、パフォーマンスの面ではあまりメリットがありません。実際、多くのことが遅くなります。また、UIKit がメイン スレッドに関連付けられているという事実により、並列プログラムの作成と UIKit の使用が非常に簡単になります。UIKit への呼び出しが常にメイン スレッドで行われるようにするだけです。

したがって、これによれば、メイン スレッドで UIKit オブジェクトにアクセスする必要があるという事実は、パフォーマンスを優先するための Apple の設計上の決定です。

Answer 2

C# も同じように動作します (たとえば、こちらを参照してください: UI スレッドの応答性を維持する)。UI の更新は UI スレッドで行う必要があります。他のほとんどのことは、可能な限りバックグラウンドで行う必要があります。

そうでない場合は、UI で実行する必要があるすべての更新の間に同期地獄が発生する可能性があります...

Answer 3

すべてのシステム、すべてのライブラリは、スレッドの安全性を考慮する必要があり、スレッドの安全性を確保するために何かを行う必要があります。同時に、正確さとパフォーマンスにも注意を払う必要があります。

iOS と MacOS X のユーザー インターフェイスの場合、メイン スレッドでの UI メソッドの呼び出しと実行のみを許可することで、UI スレッドを安全にすることが決定されました。以上です。

完全な混乱が発生するのを防ぐために、少なくともシリアル化が必要な複雑なことがたくさん起こっているため、バックグラウンド スレッドで UI を許可することで得られるものはあまりありません。

Answer 4

UI の変更が発生したときにユーザーがそれを確認できるようにするためです。バックグラウンド スレッドで UI の変更を実行し、完了時に表示できるようにすると、アプリの動作が正しくないように見えます。

すべての非 UI 操作 (または、少なくとも、ダウンロードやデータベース クエリの作成など、非常にコストのかかる操作) はバックグラウンド スレッドで実行する必要がありますが、UI の変更はすべて、ユーザーのスムーズな操作を提供するために、常にメイン スレッドで実行する必要があります。体験可能。

Windows Phone アプリの C# がどのようなものかはわかりませんが、同じになると思います。Android では、メイン スレッドでのダウンロードなどを行うことさえできないため、バックグラウンド スレッドを直接作成する必要があります。

経験則として、メインスレッドを考えるときは、「ユーザーが見るもの」を考えてください。