由这篇文章引发的思考“技术控解释为什么Android没有iOS那么顺滑”

CSDN首页今天有篇关于AndroidUI和iOS UI作对比的文章：《技术控解释为什么Android没有iOS那么顺滑》：http://mobile.csdn.net/a/20111207/308708.html

很有趣，可以读读，作者是一个曾经在谷歌呆过Google的软件工程师，他的观点认为由于Android的UI渲染线程优先级过低，造成了Android没有iOS那么顺滑，即使在四核处理器下，事实上，熟悉了不少GUI框架，包括Windows的，Java Swing的，大部分渲染线程是单线程，无法利用多线程处理器的优势，不知道Android的UI框架是不是个例外。

事实上，调整线程优先级是很轻松的一件事，Java Swing的GUI线程就是比普通的线程多一个优先级，我不认为Android的工程师调整这个线程优先级有多复杂。

用过iPhone的用户发现它的UI界面反应，特别是一些动画效果特别流畅，而Android UI不流畅的问题，可能有几个原因：

过多的计算在UI渲染线程，而没有进行很好的优化。比如说处理一个UI动画效果，例如两个界面动态的切换，可能需要生成两个图片，并对这两个图片进行处理，然后渲染，图片的生成就会耗费大量的时间，有的效果可能必须要生成图片对象，而生成这些图片有可能必须放在渲染线程执行，对生成图片对象的优化就变成了很重要的问题，必须耗费更少的时间达到更好的效果，有些图片最好做一些缓存。
不应该放在UI渲染线程的任务放在了渲染线程，事实上，上述文章提出的一些问题，比如下载和查收短信，类似这样的任务应该放在其他线程，而针对多线程的处理器，这些线程的任务不会影响UI渲染线程的反应。
主动绘制和被动绘制的问题没有处理好，大部分GUI框架是被动绘制，就是通过系统触发界面区域变脏的事件进行被动绘制，而视频游戏，动画效果基本上是主动绘制，通过一个线程循环对界面所有元素进行绘制；类似iPhone的界面效果可能是主动绘制和被动绘制相结合的效果，或者针对动画部分例程，进行了特别的处理，就是针对动画效果不能用被动绘制；针对GUI界面，主动绘制也没必要，JavaFX就是一个GUI主动绘制的例子，GUI的控件就是scene中的一个Node,动画效果很好，但GUI表现又太差；完全使用主动绘制要考虑CPU占用的问题。

事实上，在多核时代，GUI框架应该进行一些改变，UI渲染线程应该绘制一些内部状态准备好的控件对象，而把和界面无关的其他计算放在其他线程，而UI上边的动画效果则需要特别的处理来保证流畅，而UI反应过慢这些问题很容易通过一些性能分析工具查出来，个人使用NetBeans自带的分析工具也分析出来GUI程序的不少问题，比如以前的博客提到的类似一些方法非常慢的问题（ GraphicsDevice.getDisplayModes()，GraphicsEnvironment。getAllFonts()，PrinterJob.getPrinterJob()和PrinterJob.defaultPage()方法等）。
相关的关于性能问题的几篇文章： Java程序性能之一
Java程序性能之二
Java程序性能之三

更多相关文章

随机推荐