Почему мы должны выполнять все связанные с UI задачи в основном потоке?

Question

Не можем ли мы создать другой поток и запустить runloop, который будет прослушивать события касания или что-либо, связанное с пользовательским интерфейсом? Проводятся ли какие-либо исследования по работе с задачами пользовательского интерфейса в многопоточной среде?

Answer 1

UIKit не является внутренним поточно-безопасным.

Мне кажется, что я должен объяснить дальше, но на самом деле это весь ответ. Нет исследований в этой области за пределами Apple, потому что только Apple поддерживает UIKit. Маловероятно, что они будут массово переписывать UIKit, чтобы сделать его потокобезопасным, не говоря уже о существенном снижении производительности, которое они наложили, сделав это. Вы должны выполнить всю работу вашего интерфейса и основного контекстного рисования в основном потоке, если в документах явно не указано иное.

Возможно, стоит пойти немного дальше: существует очень ограниченное значение значение для многопоточного пользовательского интерфейса. Каждый пиксель может отображать только одну вещь за раз. Емкостные сенсорные датчики могут отправлять только один сигнал за раз. Существует только один интерфейс. Обещание concurrency and/or parallelism заключается в том, что я могу либо лучше рассуждать о проблеме одновременно, либо что я могу лучше использовать параллельное оборудование. Я не могу фактически нарисовать две вещи одновременно. Существует только один экран. В конечном итоге я рисую одно. Куча кривых, в конце концов, по-прежнему остается одной «картиной». Он составлен и составлен как одна вещь. Это в отличие от вычислительной работы. Я могу на самом деле вычислить две кривые безье в то же время, полностью параллельно и больше использовать аппаратное обеспечение. И это то, что я могу сделать сегодня на других потоках.

Это не означает, что внутри UIKit нет параллелизма. Существует как программное обеспечение, так и аппаратное обеспечение. Но нет большой ценности для того, чтобы взять на себя высокую сложность и производительность за счет предоставления ретентатного API для обработки пользовательского интерфейса. Кроме того, пользовательские интерфейсы - это самые сдержанные вещи, которые вы можете иметь, а изменчивое состояние - заклятый враг многопоточного кода. Даже если бы это было ценно, код пользовательского интерфейса особенно сложно сделать реентерабельным и потокобезопасным. Это более или менее верно для многих платформ, как вы заметили.