Warum sollten wir alle UI-bezogenen Aufgaben im Hauptthread ausführen?

Question

Können wir nicht einen anderen Thread erstellen und einen Runloop starten, der auf Berührungsereignisse oder irgendetwas in Bezug auf die Benutzeroberfläche wartet? Gibt es Forschungsarbeiten zur Behandlung von UI-Tasks in Multithread-Umgebungen?

Answer 1

UIKit ist nicht intern threadsicher.

Ich fühle mich wie ich weiter erklären sollte, aber das ist wirklich die ganze Antwort. Es gibt keine Forschung in diesem Bereich außerhalb von Apple, weil nur Apple UIKit unterhält. Es ist unwahrscheinlich, dass sie UIKit massiv umschreiben würden, um es threadsicher zu machen, ganz zu schweigen von der erheblichen Leistungseinbuße, die sie dadurch erzwingen würden. Sie müssen alle Ihre UI-Ereignisse und Hauptkontextzeichnungen für den Hauptthread ausführen, sofern in den Dokumenten nicht explizit anders angegeben.

Vielleicht lohnt es sich, ein bisschen weiter zu gehen: Es gibt sehr begrenzte Wert zu einem Multi-Thread-UI. Jedes Pixel kann nur jeweils eine Sache anzeigen. Die kapazitiven Berührungssensoren können immer nur ein Signal senden. Es gibt nur eine Benutzeroberfläche. Das Versprechen von concurrency and/or parallelism ist, dass ich entweder gleichzeitig besser über das Problem sprechen kann, oder dass ich parallele Hardware besser nutzen kann. Ich kann nicht eigentlich zeichnen zwei Dinge zur gleichen Zeit. Es gibt nur einen Bildschirm. Letztendlich zeichne ich eine Sache. Ein Bündel Kurven, am Ende des Tages, ist immer noch ein "Bild". Es ist zusammengesetzt und gezeichnet als eine einzige Sache. Dies steht im Gegensatz zur Berechnungsarbeit. Ich kann eigentlich berechnen zwei Bezier-Kurven zur gleichen Zeit, vollständig parallel, und machen mehr Gebrauch von der Hardware. Und das kann ich heute auf anderen Threads tun.

Das soll nicht heißen, dass es in UIKit keine Parallelität gibt. Es gibt sowohl Software als auch Hardware. Es ist jedoch nicht von großem Wert, die hohe Komplexität und die hohen Leistungsausgaben einer reentranten API für die UI-Verarbeitung zu berücksichtigen. Darüber hinaus handelt es sich bei UIs um die statusbehaftetsten Dinge, die Sie haben können, und der veränderliche Status ist der eingeschworene Feind von Multithread-Code. Selbst wenn es wertvoll wäre, ist der UI-Code besonders herausfordernd, um reentrant und Thread-sicher zu machen. Dies gilt mehr oder weniger für viele Plattformen, wie Sie bemerken.