Google+上有意思的讨论从未间断，几乎已是Google+的标志性特色了。最近两天，移动领域的爱好者都被Dianne Hackborn的一则吐槽所吸引。吐槽要火，两大因素不可缺少，一是该话题乃众人关注，却无统一意见。二是吐槽中有大料或者干货爆出，引人入胜。此番吐槽吸引人的地方，正是因为此吐槽是关于饱受争议的Android graphics性能的，自从Android推出的第一天起，graphics的渲染，动画切换等就为人诟病，到后来几乎成了果粉安粉大战的必备话题。而吐槽之人呢？是Android团队中比较senior的架构工程师Dianne Hackborn，相信关注Android开发的朋友，都不会对此女陌生。
为什么Dianne Hackborn身为Android内部人士，会突然公开讨论如此敏感的一个话题呢？用她自己的话说，就是“受够了外界谣传的关于Android图形渲染的不实信息”。我把她吐槽的大概重点归纳如下：
1. 外界盛传，Android图形渲染一直不支持硬件加速，直到3.0才开启此特性。我也一直深信此观点。其实，从最初起，Android就一直支持硬件加速图形窗口，比如你看到的所有比如菜单的出没，activity之间的切换，对话框的弹出等。
2. 但Android却是用软件来渲染窗口里面的内容的。如果屏幕上有多个窗口呈现，其中一个窗口的内容需要重新绘制，那么其他窗口不会变化，而改变化的窗口的重新构成还是通过硬件加速，只不过其中变化的内容，却是软件绘制了(不好意思插一句。Redraw!!!!!Android开发者现在应该知道这多么坑爹了吧）。虽然说是软件绘制，却不一定就表示会卡。卡不卡，是由绘制频率和刷新率是否匹配所决定的，比如手机频的刷新率是60fps，但你的渲染率是50fps，双方不同步，自然就会有停顿的感觉产生。如果用软件做这个任务，做得好不好，这个取决于显示屏上的像素数量以及你CPU的能力。比如同样的渲染，Nexus S即使在800×480也不会有问题，而最老的Moto Droid如果也是这样的屏幕，就会力不从心。
3. “完全”的硬件加速，已经在Android 3.0中就支持了，也就是说，即使是窗口内容的渲染也是硬件做的。Android 4.0并没有比3.0有更多的加速能力。4.0的改进，仅仅是默认所有app都使用硬件加速了，而不是像3.0那样开发者还需要指定android:handwareAccelerated=”true”这个选项。然而，完全启用硬件加速的代价是，程序内存占用会严重增多，反而会导致别的方面，比如程序切换，变慢。正因为这样，在将ICS移植到Nexus S时，Google强制关闭了硬件加速选项，保证整个系统的流畅运行。
4. 人们经常比较的网页浏览的性能，iOS总是比Android好很多，但这个和硬件加速渲染是无关的。在Android中，网页是被当作list而不断在屏幕上渲染的，而iOS用的则是tile贴图。list的好处是你不会在放大缩小或者上下滑动时看到还没来得及绘制的tile，但这却大大增加了渲染frame rate的难度。所幸的是，从3.0开始，Android也使用了tile的渲染，所以之后的设备不会再有这种性能缺陷（在我的GN上是明显感觉出来了进步）。
她的吐槽还有很多内容，但大意就是这些。有兴趣的朋友可以直接点击那个链接过去看。总的来说，问题就是Android是一直都有硬件加速的，可惜这个加速仅仅是用于服务那些微不足道或者不重要的东西的—窗口的切换这些。真正和application相关的内容渲染却都是软件在做。这就是为什么iPhone永远感觉都比Android快的原因。iPhone一切的UIView都是Core Animation支持的，而Core Animation又是GPU支持的。更关键的是，iPhone的Core Animation是在不同的线程上run的，和用户正在做的操作是隔离的，所以动画效果会严格按照schedule的去产生，完全没有迟钝感。
Dianne Hackborn的这个吐槽引起了很大的影响，其中一位前Google的实习生，即将去Windows Phone开发组的Andrew Munn，也因此发表了其对此的看法。Munn强调，这些技术细节都不重要，用户关注的就是你卡不卡。作为一个长期服侍果粉LD的人，我对此深表同意。Munn也针对这个性能问题提出了不少技术看法，可惜其中有不少低级错误。我总结一些我觉得是对的吧：
1. 所有app硬件加速，如Dianna所说，不是万能良药。但是，至少如ICS所表现，确实解决了很多问题。Munn的Nexus S在运行ICS后流畅度大为增加，而从我使用Galaxy Nexus的情况看，完全不是和以前的Android一个等级的。特别是桌面环境（很多widget的情况下）和Android market。Munn还指出，硬件加速能帮助电池的使用长度。
2. 垃圾回收机制虽然已经并行化了，但还是需要改进。最明显的就是Android上的gallery app。如果你在使用gallery时，会发现frame rate很低的情况，这是因为Android将其限制到了30fps。为什么？因为如果你浏览60fps的照片，偶尔会出现垃圾回收引起的停顿，严重影响使用体验。
3. Java, Dalvik。这个问题相信所有开发者都有体会。作为Java痛恨者之一，我很早就做过论断，只要Android坚持java一天，系统效率就会落后iOS一天。如果你尝试过Android NDK的开发，你会发现，区别是多么惊人。
4. Android的UI问题是一个历史遗留问题。在目前市场上所有的移动系统里，Android是唯一一个早于iPhone推出之前就开始开发的，而且当时针对的是黑莓，非触摸屏机。所以，UI框架也有着不可原谅的遗留问题：UI的渲染是在主线程进行的，animation是由UI管的。而且UI没有任何优先级。之后，全新的WebOS, Win 7等都针对触摸操作而学习iOS的UI处理，只有Android没有，也无法推到重来。
如果你好奇为什么Google很难推到现在UI的框架重来，原因不外乎就是这几个：所有的app都需要重写。老旧而没升级的app无法兼容。在UI新框架ready之前，所有Android的特性都无法继续进行改进。
是的，Android有很多很强大的特性，比如widget，比如动态桌面，比如完全多进程。这些特性带给我们强大的体验，同时也增加了UI的负担，反过来成了Android一道长久的伤疤，而这个伤疤，即使是硬件再强大，也很难磨灭。作为一个长期使用iPhone的Android爱好者，UI是我之前一直无法忍受Android日常使用的第一原因。当然，正如我前一篇介绍Android4.0的文章提到，ICS是在这个方面的一个巨大进步。它能和iOS比肩了么？还不能。但它让Android从在万米长跑中落后100米，变为了落后20米。Munn和我对Google都有同样的印象，那就是：速度，在Google里永远是第一目标。Google有很多人，他们都对”lag”这个东西极度痛恨，对“速度”的追求永无停止。看看search，看看Gmail，看看Chrome，你就明白了。我不知道Android team能否最后找到不需要重写就能解决UI问题的方法，但以我对Android team的工作精神，能力以及管理（这个话题要展开可以另写一篇文章，但总的来说我觉得Android是Google内部管理最好的团队之一）的了解，我相信Android迟早会达到这个目标的。也许就在今年6月。