查看: 2073|回复: 2

《技术贴分享》谷歌工程师深度技术分析“为什么ios比android流畅”

[复制链接]

该用户从未签到

发表于 2012-3-16 21:24:30 | 显示全部楼层 |阅读模式
分享到:
现在首先说明一下,这里面的解释并非我自己写的,而是我找到相关资料整理出来的,也算是为坛子做出点贡献,文末也分析了谷歌三个儿子和三星i9100,希望这篇文章能在技术层面上提供一个科学的评判android和ios。如果能解决大家心中的困惑的话,不妨给小弟加几分,在此先谢谢大家了。我发这贴也没有贬低android的意思,希望大家能从客观上了解两个系统的区别。
Andorid更新了一个版本又一个版本,硬件从单核到双核到四核,系统流畅度总算基本能和iOS持平了。不过人们不禁会问,为什么都是基于Linux,两个系统会差别如此大?为什么iPhone 4用单核处理器就能实现的流畅度,Android要高端双核才能保证?近日,Android开发小组工程师Dianne Hackborn算是半官方回答了其中的一个缘由。
Dianne Hackborn表示,从界面UI本身的渲染而言,首先,Android从第一个版本就有使用图形硬件加速,例如通知栏拖拉,对话框的显示和切换等等。只不过在3.0之前的版本都不是采用完整的图形硬件加速由于Android不是一个统一平台,各终端存在硬件差异,系统会自动调节动画的帧数。一个典型的例子就是,Nexus S可以实现到60fps的渲染,所以会足够流畅。但使用同样分辨率的里程碑,由于硬件(GPU)性能问题,它就无法提供足够的帧数来保证流畅了。这样,它的界面渲染帧数要低于60帧,我们使用起来就会偶尔感觉到“卡”。
而且,即使为UI开启硬件加速,OpenGL技术带来的内存开销会十分大,比如PowerVR的图形芯片,此时要消耗掉8MB内存,而UI程序本身都只要2MB内存,这太划不来了。所以,为了保证不同机型顺利运作,很多时候Android会采用CPU绘图运算代替硬件加速——注意,CPU还要干别的事情,让CPU来绘图只会拖慢速度。
在Android 4.0之前的版本,硬件加速是作为一个可选择的参数而存在(考虑到部分APP不支持)。但从4.0开始,这个选项将会被默认启用,开发小组已针对进行优化,即使不支持硬件加速程序运行也不会出现问题。
  Dianne Hackborn最后表示,硬件加速不是提升流畅度的唯一手段。事实上Android开发小组已经使用很多技术例如改进渲染技术来提升流畅度,典型的例子就是Android 3.0的浏览器相比2.2有巨大进步。而随着4.0铺开,更多用户可以感受到这点。
Dianne Hackborn没有评价iOS是如何达到流畅的。不过大家注意,从iPhone 3GS开始,每一代iPhone的图形芯片(GPU)都相当强大(iPhone 3GS、iPhone 4、iPhone 4S的图形处理芯片均为同代手机最高水平),而且苹果iOS是封闭系统,我们猜测,苹果在这一方面并没有碰到Android那么多烦心事儿。
苹果A5处理器集成的PowerVR SGX543MP2图形处理器性能相当强大,几乎秒杀了Android阵营各类对手
而另一位软件工程师和前Google实习生Andrew Munn解释说是因为Android系统UI的框架设计的问题。
在iOS中UI渲染过程具有绝对的优先等级,当用户接触到iPhone的触摸屏后,iOS中所有的进程都将停止,系统会将所有资源用于渲染UI过程。而在Android系统中UI渲染过程的优先级别却没有那么高,也就是说当你触摸Android手机屏幕的时候,系统后台的程序并没有停止,仍然在继续运行之中,比如下载和查收短信,这样系统UI获得的资源就不够,这就是Android系统不流畅的原因
由于这个原因,新发布的Galaxy Nexus,甚至配备四核处理器的话说EeePad Transformer Prime平板电脑都无法保证顺滑的操作体验,这些设备只能与3年前的iPhone顺滑程度相比,那么Android团队为什么不从根本解决这个问题呢?
实际上,Android的开发工作在第一代iPhone发布之前就已经开始了,原始Android原型体被设计成为使用键盘手机的设备,也就是黑莓手机的竞争对手。UI渲染优先级别在有键盘的手机上并没有那么重要。但是在iPhone发布之后,Android小组为了快速推出能与iPhone竞争的产品,迅速将Android改成触摸屏手机系统,但那时重写UI框架已经不可能了。因为如果这样Android应用市场中的所有程序将变得不可用,这种关系将一直处于恶性循环之中。难怪乔布斯在传记中表示Android是偷来的产品,哪怕苹果倾家荡产也要将其消灭。
自苹果收购了乔布斯的NeXT之后,花了六年把它打磨成了Mac OS X;又在2005年左右花了两年半时间,基于它制造了iOS。从各种意义上来说,iOS是一个传统技术的操作系统。它有一个基于微内核Mach的 Darwin内核,有一个叫做Cocoa Touch的运行时,用的是Objective-C这个C语言的超集。而Android在Linux内核之上,集成了一个Java虚拟机Dalvik,整 个应用层跑在虚拟机之上,而开发语言用的是Java。
事实上双方的选择都是很有道理的。苹果有Mac OS X十年基础,当然会选择自己最精通的技术,把iOS打造成一个传统系统,也可以无缝链接Mac OS X的开发者资源。而谷歌没有任何操作系统经验,为了要争取最大的开发者资源,他们选择了世界上最大的Java社区。虽然起点相同,但走出的第一步方向就已 经截然相反。
究其根底,只在于Java只有自动内存回收,而Objective-C自动与手动内存回收均可(注意iOS只有手动内存回收)。这小小的区别导致,谷歌只 能做一个Java虚拟机,而苹果可以继续他们在Mac OS X上的经验。而这个行为导致了两者在系统流畅性上的最大区别。Java由于只有自动内存回收,系统会在任意时间停掉所有进程开始回收内存,这个过程是人类 可以感受到的数百毫秒。而iOS由于可以手动管理内存,可以在用户操作的间歇由程序员进行回收,用户不会在频繁使用过程中感受到停顿。在日常使用中这个停 顿其实是可以忍的,但是在游戏过程中这个停顿是不可以忍的,比如想像一下一只愤怒的小鸟在空中停顿了零点几秒再继续飞行。
谷歌事实上意识到了这个问题,于是它在Android 2.3版本中大修了这个问题并将之作为一个特性大书特书。且抛开2.3的普及性不谈,单说这个大修的行为,也并没有修好这个问题。于是谷歌抛出了第二个在 开发上的修补:引入C/C++ NDK。可以说到了这一步, Android整个内核往上的应用层才有了与iOS抗衡的实力,可惜时间已经过去了近四年,iOS积累了十五年,Android刚刚起步。
而在内核之下呢?基于微内核Mach的Darwin 对比 当今服务器主流Linux又如何?当年Linux创始人曾经与某位牛人吵过一场著名的架,正是关于微内核与内核对比,Linus一直到现在都认为微内核只 是纸上谈兵而在现实中解决不了实际问题。在这场吵架之后的岁月,坚持内核的主流系统只剩下Linux一家,而微内核系统已经延展到了基于SVR4的IBM AIX/HP-UX,GNU/Hurd,Mac OS X,Blackberry QNX,Windows(是的,你没有看错)。Time will tell,这句话从来都没有错。Android三方ROM所困扰的驱动问题,正是Linux内核的最大局限,植根于骨子的病是治不好的
下面是第三位谷歌内部工程师的关于Android图形系统的一些观点。
 1. Android 一直在使用硬件加速。实际上从1.0版本之后,所有的窗口元素的合成与显示都是通过硬件完成的。
2.这意味着许多你所看见的动画都是被加速过的:按钮的显示、通知栏下拉的阴影、不同Activity之间的切换动画、弹出窗口以及提示框的显示和隐藏等等等等。
3.Android以前使用软件方式(与硬件加速相对应)来控制各个窗口元素的渲染,例如下图的UI,其中包括四个窗口组件:状态条、壁纸、桌面上的的启动器、以及菜单。如果其中一个元素更改了自身的内容,例如高亮一个菜单条目,对于3.0之前的版本,系统使用软件方式来绘制新的内容,然而并非所有的元素都需要被重新绘制,同时各个窗口元素的拼接也是通过硬件方式完成的。类似的,任何窗口的移动:例如菜单的上下运动是完全通过硬件方式渲染的。
4. 现在我们来关注窗口元素的内部渲染,实际上为了达到每秒60帧的FPS,你并不一定需要硬件加速。帧速取决于要显示的像素的数量以及CPU的速度。比如说,二儿子完全可以以60FPS的速度在它800*480分辨率的屏幕上完成任何普通的原生UI动画,例如列表的滚动等,完全没有问题。而最初的Droid系列却很难达到这样的速度。
5.在Android3.0中可以实现窗口的”完全”的硬件加速绘制。而在Android 4.0中也没有引入更多的功能。 从3.0开始,如果在你的应用中设置了一个标志允许硬件加速,那么此时所有的窗口的绘制都会交给GPU来完成。在Android 4.0中最主要的改变就是:在面向Android4.0或更高版本的应用中,硬件加速是被默认开启的,再也不需要在配置文件中设置 android:handwareAccelerated=”true”.(而我们不允许之前的应用默认打开硬件加速,是因为光靠硬件加速,无法很好的完成某些特殊的绘制操作;同时在应用需要其中一部分UI更新的时候,会影响其的一些表现。对于目前现有的很多应用,强制开启硬件加速,会明显的中断应用的运行)
6.硬件加速并不如大家所认为的那样完美。例如在基于PVR驱动的设备上(比如二儿子跟三儿子),光是在进程中开启OpenGL就得占用8M的RAM。对比一般进程的2M的开销实在是巨大。RAM是有限的,一大部分被拿去绘制,那么其他正在运行的进程就会因为缺少内存而出问题,比如降低应用间切换的速度。
7.由于OpenGL的额外开销,我们最好不要过多的使用其进行绘制。比如我们现在在做的一些工作,就是为了让Android 4.0能在不使用硬件加速的情况下流畅的在二儿子上使用:这样我们就不需要在系统进程中浪费8MB的内存用,也不需要在手机进程中浪费额外的8M内存,或者是在系统UI进程中的8MB内存 等等等等。相信我,你不会注意到用OpenGL来绘制一些类似状态栏或是华丽的动画是完全没有好处的。
8.硬件加速并非流畅UI的“解药”。我们为了UI的流畅尝试了很多不同的方法,比如说在1.6中引入的对前台/后台进程的调度策略,在2.3中的对输入系统的重写,”严厉模式”的使用,并发的垃圾回收机制,载入器等等。如果你想达到60fps的帧速,你只有20毫秒的时间来处理每帧的内容。这时间实在不长,光是在UI进程中读取存储卡的操作产生的延时就会大于这个时限,尤其是在写操作的时候。
9.举些最近发现的一些影响UI流畅度的例子:我们注意到在二儿子上,使用4.0时列表的滚动就不如使用2.3时流畅。而导致这个现象的原因则是计时器的轻微漂移:有些时候应用正在接收触摸事件并在屏幕上绘制,而在上一个动作还没完成的的时候,就接受到下一个事件并开始绘制,导致它丢失了当前这帧。尽管发生这种现象的时候,帧速能达到稳定的60FPS.(当然,这个问题已经修正)
10.当人们比较Android跟IOS上浏览器的滚动流畅度的时候,他们所看见的差别并非开没开启硬件加速所导致。 最初的时候,Android使用了一种完全不同的渲染策略,并做了一些折中:网页被转换成一个”显示列表“,持续的在屏幕上进行绘制,而非使用块(Tiles)的形式。它有一个优点:就是在滚动或是缩放的时候不会发生有的块还没被渲染出来的现象(译者注:早期的IOS上这种现象非常明显,快速滚动到底部时要等一会网页才会一块一块的绘制出来)。 而这个方法的不给力之处就在于页面复杂的时候,帧速就明显低了。例如Android3.0,浏览器中现在开始使用块的方式进行渲染,于是它可以在滚动或是放大的时候保持一个稳定的帧速,自然也会出现新的块没有被立即渲染出来的情况。 而每个块都是以软件方式绘制的,我相信在IOS中也是这样的。(在3.0之前的版本中,没有开启硬件加速,基于块的策略也可以使用。而且如我之前提到的,二儿子可以很容易的达到60FPS)
11.硬件加速不能如大家所想奇迹般的让绘制的问题统统消失。GPU的性能就是一个很重要的限制。最近一个很有趣的例子:基于英伟达的Tegra2的平板可以很容易的以60FPS的速度访问2.5次1280*800分辨率的屏幕中的任何一个像素。现在考虑到在Android 3.0中切换到所有应用列表的情形:你需要绘制背景(1x 所有的像素)、接着是快捷方式和桌面小工具(假设内容不多,花费0.5x),接着是所有应用的黑色背景(1x),接着是所有应用的ICON(0.5x)。显然,我们已经超过了原先的预算了,而此时我们还没完成各个独立窗口元素的拼接并做最后的显示。想要取得60FPS的动画,Android 3.0以及后续版本使用了一系列的小技巧。 其中主要的一个就是: 它将所有的窗口元素平铺在一个层中,而不是挨个拷贝到CPU的缓存中。但即使是这样,我们已然超出预算,幸好我们使用另一个技巧:因为Android中的背景是一个独立的窗口元素,我们可以将它设置的比屏幕更大来放置整幅位图,现在,用户开始滑动,背景跟着运动,此时并不需要任何特殊的绘制,仅仅是移动窗口即可,而由于这个窗口是在一个平铺层上,我们甚至不需要用GPU来将这个窗口元素组织到屏幕中输出。
12.随着屏幕分辨率的不断升高,能否达到60FPS跟GPU的速度尤其是内存总线带宽息息相关。事实上,如果你想要提升硬件的效力,特别注意要提升内存总线的带宽。很多时候CPU(特别是带有完美的NEON指令集的CPU)会比内存总线块的多。
有些人认为盖世兔已经有了一个非常流畅的UI并指出他们已经超越三儿子并做了很多改进。事实上,大家忽略了很多设备的差异,盖世兔的屏幕是480*800而三儿子是720*1280。如果二儿子在它480*800的屏幕上都能达到60FPS,拥有更NB的CPU的盖世兔必须得同样流畅嘛。 而两者之间最大的差别就是三儿子需要同时绘制2.4倍于盖世兔的像素。这相当于在单核上提升到2.4倍的速度。(需要指出 在UI渲染的时候,多核是没有意义的,因为渲染必须要在一个进程中完成,无法并行)
这就是为什么硬件加速非常重要:随着像素的提升,GPU通常能更好的处理图像的运算。事实上,这是我们在Android中引入硬件加速的最大动力。在720*1280的屏幕上,现有的ARM CPU达到60FPS很吃力,但是通过GPU渲染就不同了。同样,在与盖世兔的比较中,同时打开没有硬件加速的应用,在三儿子中无法达到盖世兔同样的60FPS,是因为它得渲染2.4倍于盖世兔的像素。
在最后,还得提及GPU的另外一个优势:许多绘制的效果变得更加容易。比如你要以软件形式绘制一个位图,你除了设置一个位移,不能做任何事。仅仅是缩小就得花上相当多的时间进行渲染。而在GPU中,此类转换则相当容易。这就是为神马新的默认主题Holo使用硬件加速绘制背景。而在没有开启硬件加速的应用中,此类背景会自动去掉~

 
回复

使用道具 举报

该用户从未签到

发表于 2012-3-20 10:46:37 | 显示全部楼层

回复:《技术贴分享》谷歌工程师深度技术分析“为什么ios比android流畅”

技术高,实在是高。
回复 支持 反对

使用道具 举报

该用户从未签到

 楼主| 发表于 2012-3-20 23:05:11 | 显示全部楼层

回复:《技术贴分享》谷歌工程师深度技术分析“为什么ios比android流畅”

回复第 2 楼 于2012-03-20 02:46:37发表:
技术高,实在是高。 

呵呵,看后我也很长知识啊
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 注册/登录

本版积分规则

关闭

站长推荐上一条 /4 下一条



手机版|小黑屋|与非网

GMT+8, 2024-11-15 06:46 , Processed in 0.119601 second(s), 19 queries , MemCache On.

ICP经营许可证 苏B2-20140176  苏ICP备14012660号-2   苏州灵动帧格网络科技有限公司 版权所有.

苏公网安备 32059002001037号

Powered by Discuz! X3.4

Copyright © 2001-2024, Tencent Cloud.