Android 为什么设计只有主线程更新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 都是最好的选择。

最后是今天给大家分享的一些独家干货：

【Android开发核心知识点笔记】

【Android思维脑图（技能树）】

【Android核心高级技术PDF文档，BAT大厂面试真题解析】

【Android高级架构视频学习资源】

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**