记录一篇通过GPU加速Android UI渲染的文章

一直在网上查找如何使用GPU加速Android UI渲染。已知的事实是,当前(Android2.x)系统的整个UI都是由CPU计算的,无论是基本的绘图(skia),还是各类特效(比如线性渐变滤镜等)都是借助ARM的NEON指令加速,因此本质上是一种完全软件的实现,效率非常低下(对于ARM来说,要对每个像素点进行处理就意味着将这些像素点的ARGB值加载到通用寄存器中,在进行简单的移位、乘法或者按位与运算,然后再写回到Surface中)。再加上Java虚拟机需要不定期做垃圾回收等工作,从而将UI渲染线程block住。总的来说,从最终效果上看,用户就能明显感觉到Android系统的UI就是比IPhone或者IPad卡顿。

刚刚找到一篇《The Care and Feeding of the Android GPU》的博文,作者意见尖锐(必须说明,该文章发表于2011年1月1日,此时Google IO 2011还没有开始,所以有些观点已经随着Android 3.x的发布而过时,但总的思路很有借鉴价值),引起了很多人的讨论。总的来说很有意思,现分析如下:

一上来,作者就宣布Android系统用户体验的两大问题:动画效果与触摸响应。非常“用户体验”的形容,应该是一位I系列的重度使用者。继而作者指出:当前UI合成(composition)与view系统都主要由软件计算,而垃圾回收以及一些异步服务也会时不时block住UI操作,造成卡顿感觉。然后作者将Google的Android UI组骂了一顿,说他们至今仍然否认GPU可以提升UI性能,反而说应该消除垃圾回收,从而提升动画效果。特别是,Android UI组认为绘图本身不是性能瓶颈,用GPU也没啥用。随后作者应用了UI组头Romain Gay的讲话(再次提醒,该文写作的时间在Android 3.1发布之前,所以以下观点带有明显的“历史局限性”):

利用GPU加速text和bitmap的渲染就能起到立竿见影的作用,这种观点是天真的(很有x主席的风范)。这个星球上还存在很多不依赖GPU就能加速UI的手段:比如提升触摸事件dispatch速度、降低垃圾回收等异步操作的开销等。1年前的Nexus One的性能就足以满足以60fps的性能滑动list(受限于LCDC的刷新率)。而使用GPU加速2D渲染可能带来其他问题,比如:填充率(fillrate)的问题、具有抗锯齿要求的不规则图形渲染性能问题、上传texture的性能问题以及shader compiled的问题等。我并不是说我们不用GPU加速UI(我自己就一直在这么干并测试),但别寄希望马上就能使用。

作者说:没人要求“2D绘图元语需要GPU加速”,而是说动画以及view的合成需要GPU加速!也就是Core Graphic可以是大部分基于软件的,但Core Animation应该是基于GPU加速的。看看Samsung的Galaxy S的浏览器就是基于GPU加速和基于分块的(tiled)。别人告诉他这就是由于Power VR GPU加速的结果。而与Nexus S相比,基于同样的硬件,Galaxy S的效果就像黄油般顺滑。拜托,别再在每帧动画动画过程中执行Dalvik虚拟机的指令,彻底换成GPU的流水线吧。如果有价值的话,另起一个线程,专门做scene graphic,这甚至可以获得32bit的图像啊。Google那些砖家总说硬件越来越好,最终就能自然搞定这些问题。放屁!手持设备功耗为王!用双核或者nGHz只能在0使用时间的前提下提升性能,这还得附件“不许用太大屏”这个条件。醒醒吧,Android组!Windows 7都比你们干得好了。

后面部分是回复,也非常有意思,记录如下:

  • Ariya说:从源码上没瞧见Samsung喜欢用GPU加速浏览器啊,所谓的tiles,好像确实可以加速渲染,但那也是我N年前就搞定了的东东啊
  • 楼主说:A同志,我说的Galaxy S手机,不是平板,他们硬件和软件都不一样的。而前者从XXJPU版本的固件就开始用GPU加速了。
  • Ariya说:Oops,我说的就是Galaxy S的手机,没从源码上看到用GPU加速的地方呢,而tiles加速和我以前做的差不多哈。另外,谁看到GPU加速的代码麻烦告我下。
  • Jose说:三星里面有一个专门做底层图形加速的家伙,叫Carsten Haizler,这人以前搞Linux桌面的。
  • Typeface说:(不知道这位在说什么)。
  • Kay说:我觉得你说的是“垃圾回收与同步操作”吧。顶你的观点,和我的ios设备比起来,在menus的滑动上,Android就被甩了老鼻子远了。只有高FPS的滑动才能实现“无缝滑动”的效果,而这一点我没在哪部Android手机上感受到。
  • Sivan说:你说的这些问题在WP7、BlackBerry或者webOS上都存在,这些家伙都用Webkit。事实上都远比不上iOS的效果。
  • sha说:最近fwiw这家伙提交了一个针对skia的patch,就是用GPU做后台,估计预示着什么哈。同时我也同意Android UI组的Romain Guy所说的“加速GC(Android2.3中包含)是提高响应的核心”。
  • Andrew说:搞笑的是2007年出的第一代iphone都没有的多点触摸响应延时的问题居然在2010推出的Android身上出现。我觉得相对于iOS设备而言,Android的体验太挫了,什么地方都慢。99.9%的用户都不是geek,所以很看重第一感觉,而Android给人的第一影响(UI响应)就让人不爽。
  • Pierre lebeaupin说:靠,他们不仅没有大量使用GPU加速动画(特指对每帧的渲染),而且他们居然在渲染过程中执行Dalvik虚拟机的字节码指令!神啊!大家说说为什么核心的音频解码和动画渲染要用C++,甚至不用object C,相信我这并不是因为写这些程序的哥们都是受虐狂masochists。在这部分PPT中,Android的UI砖家们要应用开发人员别在他们的UI代码中用temperal objects(虽然PPT里面没有明说哪些代码不会被垃圾回收,但我的理解是,凡是要和动画同时执行的所有代码-其实就是UI中绝大多数-都会被垃圾回收)以便不会产生需要垃圾回收的东西(这样行不?个人不懂Dalvik,所以只能祈求这样能成)。但这太难为写Java的同学了,也许用C++还容易些。个人觉得最好将动画搞成一个单一的、实时的使用C++编写的线程。只有这样才能避免JAVA的垃圾回收机制在执行过程带来的UI卡顿现象。更明确的说,UI卡顿并不是一个性能问题,而是一个实时性问题。前者还可以通过硬件提升解决,但后者就没辙了。同时,只要不应用动画的实时渲染,则即使Android的绘图函数本身不是实时的也没啥关系。
  • Tochi说:我从Romain Guy在Sun干活时就Follow他了,I’ll take his word over that of a random blogger who does not appear to have a clue(这句话我不知道是不是应该译为:我转述他的话,他说一个无关紧要的博客写手懂个屁).另外,双核更省功耗。
  • BuyElectronic.com说:(引用该文部分,什么都没说)。
  • Dennis Forbes说:只是好奇,就用这一点批评Android,苹果控们是不是太武断了。对那些每天用Android设备的人不负责任吧。我还严重怀疑这篇枪文的观点出自Hack News
  • Clarence Odbody说:Tochi:这篇文章可不是什么“无关紧要的博客写手”搞的!
  • JasonK说:Tochi,以后说别人是“无关紧要的博客写手”之前看看别人的简历先!我从Romain Guy在Sun干活前就Follow他了。这小子挺聪明,但并不表示他啥都懂。
  • Andrew说:Forbes,我相信这个问题并没有困扰那些每天用Android设备的人,但对于那些用过iPhone或者正在准备买一支智能手机的人而言,看到这个问题无疑就会考虑下是不是应该购买了。
  • Andrew说:我还想说这些基于触摸的设备,大尺寸的屏幕和UI是核心饰物。当你手指按下去的时候,难道不是应该立刻获得反馈?否则要触屏干嘛。
  • Dennis Forbes说:Andrew说“否则要触屏干嘛”,有点儿过激了吧。我们在这讨论的仅仅是在划屏过程中的那么一点儿卡顿而已。至于交互性,这就与GPU八竿子打不着了。诸如Dispatch这样的过程才是非常耗时的,才会影响交互性,而这与GPU沾不上边哈(Android 2.3基本解决了)。先不论Yang先生的专业背景,Android UI组的哥们应该很清楚用CPU或者GPU渲染的优劣。此外,用GPU加速滑动还能降低能耗基本上属于妄想。我相信后续的HoneyComb将更好地使用GPU,从而带来更好的用户体验。本文讨论的话题有些夸大了。
  • bms说:问题的关键是Android基于Java。每次在台式机上用eclipse时那种按下按钮半天没有反应的感觉让人抓狂,而在QT或者GTK上就没有这回事儿。同样的情况发生在Android上。
  • Janne说:Forbes认为对用Android的同学UI的卡顿没啥关系。我认为的确UI的卡顿对于Android用户可能关系不大,但这并不表示这不是一个问题!有些人就喜欢回避问题。你买的车可能是“油老虎”,你可以选择忽视这个问题,但并不表示这个问题不存在。我自己用Galaxy S和ipod touch,我老婆用iphone4,可以明确感到Galaxy的UI就是卡。当然有些同学会因为Android提供的其他便利而忽视UI卡顿的问题。但我就是不爽。每次卡的时候我就得提醒自己这个东东还没有优化好。感觉上就像设备在挣扎着去做我希望它完成的任务。而对iOS设备就完全不同,一切如黄油般顺滑,应用也像很轻松一样完全没有负担。当然你也可以说我提到的问题都无关紧要,他们不是客观的数据,不会写道spec里面,但我却认为这直接决定了一台设备是否能给用户带来舒适的感觉。
  • Dennis Forbes说:我并不是说用GPU去加速不好,而是说对最终用户体验的提升不会太明显。
  • Nick说:这个帖子就是一堆追求UX性能和一堆认为UX性能意义不大的人的辩论,说穿了就是一堆果粉对一堆Geek。
  • Dennis Forbes说:Nick,我们讨论的不是UX性能是否重要。说到UI,我的iphone的消息通知系统也让人抓狂。没有设备是完美的,虽然其UI的顺滑度不错,但有些UI设计还是很恶心的。
  • Janne说:Forbes,我并不是说所有Android用户都应该恨自己的手机,目前有数百万的Android用户很喜欢自己的Android设备,他们不在乎UI的卡顿。但也有很多人很在乎,包括我自己。我以前用Nokia的手机,虽然性能一样很烂,但在没有IPhone做对比时也就无所谓了。现在Android给我的感觉就像Symbian,复杂而又缓慢。当然Symbian也有自己的拥护者,但对我来说它就是慢,就是让人不爽。对你也许无所谓。但是请不要认为人们对系统顺滑的追求是“天真”的!我并没有说Android系统很烂,相反我认为Android是一个很有吸引力的平台,有很多好的功能,但界面的顺畅还不是其中之一。苹果病态的对细节的追求让UI响应无懈可击,这让人们的使用体验大幅提升。在是否需要有流畅的UI这个问题上并没有对错,只是观点和角度不同。
  • 楼主:首先澄清一下,Android还是有部分用到了GPU加速,包括:窗口级UI合成、SurfaceFlinger以及动态壁纸所使用渲染脚本。但是最重要的、直接于用户体验相关的scrolling, panning, zooming操作却没有使用GPU加速(比较让人震惊的是在Android 2.3中仍然没有用GPU加速)。OEMs在这个问题上已经和Google合作了快2年了,但渐渐开始各自为阵。HoneyComb应该可以用GPU加速一些核心UX部分,我只是希望Android的市场部能花更多的精力在浏览器的操作上,而不是推什么3D地图。我也认识一些做Android UI的家伙,都很聪明,我相信他们能搞定这事儿。
  • Janne说:Forbes,还是那句话,我就是很看重UI性能,你不看重是你的事儿。
  • Dennis Forbes说:我觉得Android UI组的哥们需要考虑应用的多样性,所以才无法做到APPLE的效果。Android得照顾甚至ARMv5TE的架构,不太可能直接使用chip+GPU的方式。设备可能有NEON,也可能没有,可能支持GPU,可能不支持。甚至可能是X86架构,你叫他们怎么办。而Apple就不一样,他们就一套系统,完全可以定制,所有掌控权都在自己手里。
  • gpu_mystery说:看起来楼主很牛,什么都懂。那么有两个问题希望请教:1.List滑动的操作到底分几步(触摸;产生上下滑动事件、List实现接受这类的时间,等等)2.GPU怎么帮忙,可就是为什么用GPU就快?
  • Michael说:Janne,老实说我在我的DG Droid和老婆的EVO上没有碰到你说的UI性能问题。
  • 后续还有,将来有时间继续总结
Advertisements

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s