选择方案的选择
- 单线程更新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。不能保证这一点，就会造成业务逻辑可能各种问题，甚至各种死锁。
既然同一个时刻只能一个线程更新，那设计成单线程是不是就更好呢，到这里，其实还是不够全面的，还有个因素就是事件相应。如果多线程更新的情况下，其实这个是不容易实现的， 反而单线程，就好实现一些。
总结
通过分析总结几个点。
- 一般UI还是要保证同一时刻只有一个线程在更新，所以效率不会更高。
- 多线程更新UI实现上会复杂一些，Java的内部人员发布过文章也说过这个几乎不可实现。
- 从响应速度角度分析，单线程可以设计出更好的响应速度的api
- 单线程更新，也是一个被证明效果非常好的方案。
从过个角度分析 Android 为什么设计只有主线程更新UI 都是最好的选择。
不过回答这个问题需要理解的不全是结论，而是对这个问题，和图形界面开发的理解。 如果说效率高，安全，也需要回答出来为什么。这些不是凭空说的。真的效率高吗？高在哪里？都需要说清楚，可能会有不正确的地方。但是只要把需要考虑的点表达清晰就好
引用
负责Swing开发的一个大师的一篇博客《Multithreaded toolkits: A failed dream?》
也有人说单新ui 效率会高，因为多线程会加锁。如果有人能把这个细节解释清楚呢，希望留言。因为正常设计也只是锁更新那一行代码而已，我的总结就是效率不分伯仲，希望大家探讨吧。