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

·  阅读 9138

选择方案的选择

  1. 单线程更新UI
  2. 多线程更新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
标签:
分类:
Android
标签:
收藏成功!
已添加到「」, 点击更改