Pourquoi devrions-nous faire toutes les tâches liées à l'interface utilisateur sur le thread principal?

Question

Ne pouvons-nous pas créer un thread différent et démarrer un runloop qui serait à l'écoute des événements tactiles ou de tout ce qui touche à l'interface utilisateur? Des recherches sont-elles en cours pour gérer les tâches de l'interface utilisateur dans un environnement multithread?

Answer 1

UIKit n'est pas un thread-safe interne. Je pense que je devrais expliquer plus loin, mais c'est vraiment la réponse entière. Il n'y a pas de recherche dans ce domaine en dehors d'Apple, car seul Apple maintient UIKit. Il est peu probable qu'ils réécrivent massivement UIKit pour le rendre sécuritaire pour les threads, sans parler de la pénalité de performance significative qu'ils imposent en le faisant. Vous devez effectuer tout votre travail d'interface utilisateur et de dessin de contexte principal sur le thread principal, sauf indication contraire dans les documents.

Peut-être que cela vaut la peine d'aller un peu plus loin: il existe une valeur très limitée à une interface utilisateur multithread. Chaque pixel ne peut afficher qu'une seule chose à la fois. Les capteurs tactiles capacitifs ne peuvent envoyer qu'un seul signal à la fois. Il n'y a qu'une seule interface utilisateur. La promesse de concurrency and/or parallelism est que je peux soit mieux raisonner sur le problème en même temps, ou que je peux faire un meilleur usage du matériel parallèle. Je ne peux pas effectivement dessiner deux choses en même temps. Il n'y a qu'un seul écran. En fin de compte, je dessine une chose. Un bouquet de courbes, à la fin de la journée, est encore une "image". Il est composé et dessiné comme une seule chose. Ceci est en contraste avec le travail de calcul. Je peux effectivement calculer deux courbes Bézier en même temps, entièrement en parallèle, et faire plus d'utilisation du matériel. Et c'est quelque chose que je peux faire sur d'autres threads aujourd'hui. Cela ne veut pas dire qu'il n'y a pas de parallélisme à l'intérieur d'UIKit. Il y a, à la fois dans le logiciel et le matériel. Mais il n'y a pas de grande valeur à prendre en charge la complexité et la performance élevées de la fourniture d'une API réentrante pour le traitement de l'interface utilisateur. En outre, les interfaces utilisateur sont à propos des choses les plus importantes que vous pouvez avoir, et l'état mutable est l'ennemi juré du code multithread. Même si c'était utile, le code d'interface utilisateur est particulièrement difficile à rendre réentrant et thread-safe. Ceci est plus ou moins vrai sur de nombreuses plateformes, comme vous le constatez.