面试题：Android 为什么设计只有主线程更新UI

选择方案的选择

单线程更新UI
多线程更新UI

从问题本身考虑就两个方案不是单线程就是多线程。

下面是个人根据具体情况分析，如果有什么不对的地方，欢迎指正。

从开发效率来看，开发一个单线程UI 库，会显得非常容易，而且，每个控件的运行效率肯定会比多线程的效率高，比如我们单线程可以使用HashMap，多线程就需要使用JUC 框架下的类库了，这个效率肯定比 HashMap低很多，这样就很好理解。编写一个多线程的UI库，很可能每个控件，都会加锁，控件本身效率就低了，但是这样还不够，后面会解释。

还有一个简单方案，就是对真个UI库，加锁，而不是具体某个控件，就是确保同一时刻，只能有一个线程，对整个UI系统更新，这个已经有点单线程更新UI的意思了。但是锁的粒度会很大，如果一个页面100个控件，相当于每个控件都加锁了。

这个方案实现起来倒是不复杂，只需要设计一个boolean变量就可以，任何线程需要更新UI 都会访问这个变量获取锁，这个方案会造成所有的线程都竞争同一把锁，单从运行效率分析，应该是很高的，但是这个竞争特别激烈，可能造成的问题就是，事件响应不够及时，

单线程更新UI方案简单成熟

单线程更新UI方案，从上面的分析来看，优势就很明显，整体设计可能是最简单的，每个控件的设计只需要考虑单线程运行就可以，完全不必关系其他线程更新UI。

而且这套方案非常成熟，在Android 之前，swing qt windows 几乎绝大部分图形界面api 都会使用这个单线程方案。

从执行效率看

前面说了，如果一个加锁的api 和不加锁的api 比较，那肯定不加锁效率高对吧，但是，这么说确实很笼统，如果合理设计一套多线程更新ui 的库，整体性能未必会比单线程差，只是想实现这样一套系统的复杂程度，可能不只是翻倍那么简单，设计越复杂，带来的问题是潜在bug 可能会多，但是这些，在设计ui系统的时候未必是这样考虑的，如果业务复杂，效果会更好，那么我相信大部分企业还是会设计一个复杂的系统的。

综合考虑？

多线程更新UI，不管如何设计都会绕不开一个问题，就是竞争，而这个竞争，是整个UI系统的，而不是单独一个控件，大部分情况下，一个线程可能同时更新的是过个控件，而要确保我一次更新的所有控件是同步更新的，所以要保证这个逻辑，其实我们就要确保一个问题，同一时刻。永远只允许一个线程去更新UI。不能保证这一点，就会造成业务逻辑可能各种问题，甚至各种死锁。

既然同一个时刻只能一个线程更新，那设计成单线程是不是就更好呢，到这里，其实还是不够全面的，还有个因素就是事件相应。如果多线程更新的情况下，其实这个是不容易实现的，反而单线程，就好实现一些。

总结

通过分析总结几个点。

1.一般UI还是要保证同一时刻只有一个线程在更新，所以效率不会更高。
2.多线程更新UI实现上会复杂一些，Java的内部人员发布过文章也说过这个几乎不可实现。
3.从响应速度角度分析，单线程可以设计出更好的响应速度的api
4.单线程更新，也是一个被证明效果非常好的方案。

从过个角度分析 Android 为什么设计只有主线程更新UI 都是最好的选择。

不过回答这个问题需要理解的不全是结论，而是对这个问题，和图形界面开发的理解。

如果说效率高，安全，也需要回答出来为什么。这些不是凭空说的。真的效率高吗？高在哪里？都需要说清楚，可能会有不正确的地方。但是只要把需要考虑的点表达清晰就好

引用
负责Swing开发的一个大师的一篇博客《Multithreaded toolkits: A failed dream?》

也有人说单新ui 效率会高，因为多线程会加锁。如果有人能把这个细节解释清楚呢，希望留言。因为正常设计也只是锁更新那一行代码而已，我的总结就是效率不分伯仲，希望大家探讨吧。

更多 Android 知识点和面试题尽在GitHub，大家可以自行查阅

GitHub地址：
https://github.com/733gh/Android-T3