当前位置:首页 > 嵌入式 > 嵌入式动态
[导读]写在前面的一些话:在纠结了很久以后,我决定来写写 iOS 和 Android,也算是对自己近几年来学习成果的一个总结。这个话题非常大,本人虽尽我所能查证来源,但也难免会有疏

写在前面的一些话:

在纠结了很久以后,我决定来写写 iOS 和 Android,也算是对自己近几年来学习成果的一个总结。这个话题非常大,本人虽尽我所能查证来源,但也难免会有疏漏,有的话欢迎指出。我希望大家读完后,是这样的:

 

而不是:

 

我们应该为这个世界的多样性而感到庆幸,不是么?

一、什么是流畅?什么是卡顿?

如果我们讨论流畅和卡是建立在不同的标准上,一定会变成毫无意义的口水战。在这里,流畅我们定义为运行程序时达到 60fps 或以上的绘制效率,且尽可能少丢帧。卡顿我们定义为程序运行时无法达到 60fps,丢帧频繁。

二、Apple 和 Android阵营 比是不是能带来更流畅的应用体验?

不是。两者都非常顺滑,用久了也都不卡顿。

Android 定义为 带有 GMS 推送的,带有良好 Android 应用生态圈的(包括少数国内优秀应用),具有 Google Play 服务的 Android 手机,拥有健康使用习惯的 Android。包括但不限于 Nexus,Moto,SONY,LG,htc,Samsung 在没有封杀 Google 的市场的使用体验。

三、Apple 和 安卓阵营 比是不是能带来更流畅的应用体验?

是。安卓(尤其是用久了)很可能会卡顿。

安卓 定义为 不带GMS推送的,缺失良好 Android 应用生态的,不具有 Google Play 服务的,基于各种“深度优化,深度定制,世界第一,跑分天王,etc.” 家,配合 “动不动就管家卫士全家桶,清理内存释放手机速度,打败全国百分之XX” 的用户的 安卓生态。

四、Apple 和 Android阵营 硬件对比

Apple 硬件处于一个什么样的水平?足够优秀的水平,Apple 是著名的硬件狂魔,并不是大家想的 iPhone 硬件远远不及 Android 阵营。

1、 Android 阵营目前的旗舰 Soc 之一 是基于 高通810 的解决方案(MTK 和 三星,华为 的解决方案不是很了解,欢迎补充。当然业界一般认为是三星的 CPU 14nm 制程更先进,所以功耗发热的表现较810更好。),它拥有 8 个 CPU 核心,20nm 制程,主频高达 2 GHz。810 纯 CPU 计算能力,并发计算能力优于 A8。但它频率高,核心多,功耗和发热量在密集计算时也会远高于 A8,发热会限制 810 的发挥。

2、CPU Cache 方面。

A8 非常慷慨地配备了高达 64KB 64KB 的 L1 Cache,1MB L2 Cache 和 4MB L3 Cache,与上一代 A7 相同,810 数据不明。但实际应用来看,似乎 810 配备的 Cache 喂不饱 8个核心,存在 Cache Miss 的情况。(有硬件信息的朋友欢迎补充)但是,即使没有准确数据的情况下,有一件事情也是可以确定的,那就是 Cache per Core数据 810 绝对不如 A8。如果要做到一样的水平,那么 810 要配备 128kb L1 Cache,4MB L2 Cache,16MB L3 Cache。要知道的是,这么多的 Cache 即使是对于 Intel Core i7 也是很奢侈的。而如果假设 810 和 A8 配备了一样的Cache,810 的 Cache per Core 数据就很难看了。要知道,CPU Cache 的速度远高于 RAM 的速度,所以小 Cache 带来的情况就是 外围 I/O 经常处于等待状态,延迟了 CPU 计算能力的发挥。打个比方,你拿跑车引擎配个 4 速变速箱,引擎的能力就无法发挥了。Cache 方面,A8 表现优于 810。

3、GPU 方面。

A8 配备的 PowerVR Series 6XT GX6450 运算能力是 136.4 Gflops(533MHz)/153.6 GFlops(600MHz),稍微优于 801 配备的 Adreno 330 ,Adreno 430 则是 324~388.8 GHz(600MHz)【水冷……】。毕竟当时高通设计 810 的时候就是用来拖 4k 的,图形性能 Adreno 430 数据上远优于 GX6450,但是 GX6450 带 1334*750 相当于 801 带 720p,带 1920*1080 分辨率性能也足够充裕。

4、晶体管数量。

丧心病狂的 A8 堆了 20 亿个晶体管(包括 Cache,GPU,dsp),已经赶上 810 所有 8 个核的总晶体管数量了。带来了 A8 极其凶残的单核性能。810 单核性能弱于 A8。

五、系统与运行机制层面

(一)内核

1、又要开始拿 Linux 和 Unix 说事了,但很不幸的是,流畅这件事跟系统内核一点关系都没有。

2、说个老梗:

● iOS 基于 Unix 所以是 Touch(响应触摸操作)——Media——Service——Core 架构

● Android 基于 Linux 所以是 Application——Framework——Library(包含了响应触摸操作的显示相关)——Kernal 架构

● 所以 iOS 要比 Android 响应的快,所以 iOS 更流畅 云云

● 然而这个东西是 2.x 时代的,Google 早就改掉了……我也不知道这种 Unix 内核性能优于 Linux 的论调为什么时不时还会冒出来……反正两者都不是实时操作系统(RTOS)。

(二)运行时(Runtime)

1、 Android 基于 Java 虚拟机,前段时间还因为这个 Google 和甲骨文吵上了法庭。算了回归正题,我们主要要说的运行时有 Dalvik 和 ART(Android Runtime)两种,Dalvik 是 Android 于 Android 4.4 之前所使用的默认 Runtime,ART 则是 Android Runtime,是在 4.4 时引入的一种新的运行时,在 L 及以上版本取代 Dalvik 成为默认运行时,在 GC 机制、JNI 和 Stack size 上都与 dalvik 有着很大的不同。Dalvik 属于 JIT(Jusi-in-time)编译器,ART 属于 AOT(Ahead-of-time)编译器。反正说了这么多你们只需要知道 ART 可以直接调用底层效率更高就对了。

● 其实是我 《编译原理》 还没啃熟你们不要打我嘤嘤嘤,有兴趣的自己去看这两个链接

● http://tinyurl.com/maz6uaq

● http://tinyurl.com/nepu7vk[!--empirenews.page--]

2、iOS 不开源,但是可以知道的是它的 Object-C 编译器属于 GCC 编译套装的一部分(感谢 @InflationAaron 指出:后期应该是转向了苹果主导的 LLVM 编译器)。

(三)渲染流水线

1、 Android 3.0 引入了应用端绘图的 GPU 加速(Hardware Canvas),Android 4.1 引入了黄油计划(Project Butter),到 4.1 可以说 Android 的渲染机制已经足够优秀,只要按 Design Guideline 写是轻松让过渡动画达到 60fps 的。黄油计划包括了:

● 窗口三重缓冲机制(降低连续丢帧可能性)

● 垂直同步机制(减小应用端开始绘制到实际屏幕更新的延迟)

● GL 窗口缓存绘图命令的异步执行(减少应用主线程的阻塞)

但很明显 Google 还不满足,于是在 Android L 引入了独立的 GPU 线程,并允许主线程和 GPU 线程并发。也就是说GPU线程在绘制第 N 帧的 Display List 时,主线程已经可以同时生成第 N 1 帧的 Display List,并且允许 GPU 调用不同参数绘制同一个 Display List,简单的说就是提高了绘制过渡动画的效率。

这里说一个 Google 的黑科技,Project Sky - Dart on Android,完全脱离 Java 的一套东西,他们的目标是把渲染时间压缩到 8ms 以内,也就是等效 120fps。但他们现在做出的 Demo 里每帧平均渲染时间是 1.2ms/f,也就是等效惊人的 833fps……

2、iOS 不开源……(又来了)但是,我们仍然可以推测他的渲染流水线和 WebKit 类似,因为 WebKit 存在大量 Apple 的参与代码。

3、总而言之,你们只需要知道 Android 和 iOS 是 different but not better than each other 就行了。只是在实现路线上有所不同,但实际上到最后都异曲同工。Google 的 Project Sky 性能惊人,实际应用有待观查。

六、应用,ROM(Android)以及其它

(一)This might be the most tedious part.

(二)应用,讲到这里就不想讲了,算了,还是讲一下吧:

1、BAT

● Baidu,alibaba,tencent,号称 Android 流畅度三大杀手

● 这些大公司用户太多太多了,导致他们必须兼容低版本的 Android,无法利用新的 API,导致卡顿:

(1)QQ,节奏大师,Android 2.2,API level 8

(2)QQ浏览器,UC浏览器,Android 2.3,API level 9

(3)闲鱼,支付宝,淘宝,百度,Android 4.0,API level 14

(4)微信,Android 4.0.3,API level 15

● 发现什么问题了没有?引入黄油计划的 Android 版本是 4.1,所以 60fps……

● 然后 QQ 和节奏大师你们这还抱着冻酸奶的态度令我感动……以及浏览器们都和姜饼暧昧不清……唉,连GPU加速都……

● 然后如果打开开发者选项里面的 show GPU overdraw(虽然不一定是 GPU 绘制的),你们就会发现各种严重的 overdraw,尤其是阿里巴巴系列的应用,整个页面滥用 Webview,导致了严重的重复绘制。

● BAT 经常大量使用自制控件进一步加剧了对资源的使用。

● 假如有第三方客户端的话,其实往往有非常优秀的遵守 Design Guideline 的应用,比如新浪微博的第三方客户端们,四次元,Fuubo,Smooth等等。

2、GCM,与那些推送的事情

● GCM 就是 Google Cloud Messaging,是 Google 自家的推送服务,也是绝大多数 Android 应用的推送服务。使用这个服务,利用的是 Google 服务器统一推送,可以带来及时,省电,后台不唤醒的推送体验。

● APNs 就是 Apple Push Notification Service,Apple 的推送服务,与 GCM 类似,可以带来良好的体验,且是 iOS 上唯一的推送机制。

● 然而由于某堵墙的存在,国内并没有办法体验到 GCM 推送带来的推送体验。所以部分手机厂商就开始做自己的推送机制,比如小米做的对齐唤醒和 MiPush,但是只对 MIUI 及兼容的部分应用有用。

● 剩下的就是其它诸多推送了,BAT 自家的推送机制,极光,蝴蝶云,智游,个推等等。假如很不幸的,你的手机上安装了 BAT 全套,又安装了带各种不同推送提供商的应用,那就等着感人的耗电,内存占用与无数的后台唤醒吧……

3、优化

● 很不幸的是,到现在,两个平台都仍然有大量的应用跑在单核单线程上,对双核,多核以及 64 位的利用非常之低,甚至没有。这个时候 A8 较高的单核性能能带来更好的体验。但如果应用对多核做好了适配的话,在 Android 上流畅性是可以花样吊打 iOS 的。

4、流媒体视频

● Android 在这方面流畅度要好于 iOS

(1)Android 支持传统流媒体格式,可以用已经成熟的 CDN

(2)iOS 需要使用TS流,需要额外准备 CDN 线路,部分线路支持还不佳

(3)Android 4.0 后使用 HLS 协议并且实现 P2P

(三)ROM

1、iOS 并不存在这个问题,不讲。

2、Android 存在的问题是,有太多厂商太多版本的 ROM 了,每个厂商都对底层做些修改。所以简而言之就是闹心,负分优化大家见得多了我就不说了。

PS:知道为什么国内定制越深度的 ROM 适配 Android L 越慢吗?就是因为底层的东西改得太多 5.0 把运行时改了工程量很大难以在保证功能健全的情况下快速适配。

3、驱动(不是很懂,希望补充)

七、最后我们来说说设计

1、 iOS 的人机交互设计还是很值得称道的,毕竟是带领我们进入了 Multi Touch 时代,从 iOS 6 的拟物到 iOS 7/8/9 的扁平 高斯模糊毛玻璃为代表的设计路线,都可以说是一套非常值得令人尊重的设计方案。它是比较早把流畅的动画引入设计语言的一个方案,也在长期的验证中逐渐发展成熟。

2、以 Holo Theme 为代表的 Android Design,进化出了 Material Design,对整个 UI 的把控能力达到了一个非常高的水准。阴影,涟漪波纹,Z 轴等等,都显示出 Google 对细节一丝不苟的把控,且这套 UI 比较好的解决了桌面,网页,移动端的交互统一性。

八、总结

1、总之,对比下来我们会发现,两种生态在健康的情况下其实软硬技术实力都是处在同一水平线上的,互有长短。硬件 Apple 并没有弱于 Android,更谈不上软件的神优化。但是,如果 Android 没有 Google Services,就相当于失去了 Android 的灵魂,失去了 Google Play 的优秀资源,失去了 GCM 推送带来的流畅省电,失去了 Google Cloud 在内的很多很多核心竞争力。不卡或会卡,本质不是系统的问题,而是什么样的环境,用户着什么样的程序。[!--empirenews.page--]

2、iPhone 就好像是一辆 F1 方程式赛车,里里外外都精心设计过。看起来只有 1.6L 的排量,但实际上却是一颗上千马力的心脏,但这也决定了他只能在专门设计的方程式赛道上跑,而且跑的很欢。一旦脱离赛道(越狱),就各种不安全。

3、 Android 则好像是各种其它跑车,硬件的定制化程度极高,既有入门级的现代 Coupe,尚酷 R,也有比肩 F1 的布加迪威航,法拉利,兰博基尼,更有小众的科林赛格,优雅的玛莎拉蒂等等……如果再适合他们的路况上跑,就算是入门级,轻松破 200km/h 也不是什么难事,即使无法比肩 F1,也足够体验驾驶乐趣,旗舰则可以和 F1 全面硬抗,弯道,直道,加速,都能争个高下,甚至还可以玩一些 F1 做不到的事情,比如弹射起步,漂移等等。

4、安卓则是……则是几个改装厂把这些跑车们自行改装,有的厂商改的好,有的改成渣,拉到了坑洼不平的土路上,还时不时来点路障,这就算起步跑得溜,但久了对整车肯定不好。

本站声明: 本文章由作者或相关机构授权发布,目的在于传递更多信息,并不代表本站赞同其观点,本站亦不保证或承诺内容真实性等。需要转载请联系该专栏作者,如若文章内容侵犯您的权益,请及时联系本站删除。
换一批
延伸阅读

9月2日消息,不造车的华为或将催生出更大的独角兽公司,随着阿维塔和赛力斯的入局,华为引望愈发显得引人瞩目。

关键字: 阿维塔 塞力斯 华为

加利福尼亚州圣克拉拉县2024年8月30日 /美通社/ -- 数字化转型技术解决方案公司Trianz今天宣布,该公司与Amazon Web Services (AWS)签订了...

关键字: AWS AN BSP 数字化

伦敦2024年8月29日 /美通社/ -- 英国汽车技术公司SODA.Auto推出其旗舰产品SODA V,这是全球首款涵盖汽车工程师从创意到认证的所有需求的工具,可用于创建软件定义汽车。 SODA V工具的开发耗时1.5...

关键字: 汽车 人工智能 智能驱动 BSP

北京2024年8月28日 /美通社/ -- 越来越多用户希望企业业务能7×24不间断运行,同时企业却面临越来越多业务中断的风险,如企业系统复杂性的增加,频繁的功能更新和发布等。如何确保业务连续性,提升韧性,成...

关键字: 亚马逊 解密 控制平面 BSP

8月30日消息,据媒体报道,腾讯和网易近期正在缩减他们对日本游戏市场的投资。

关键字: 腾讯 编码器 CPU

8月28日消息,今天上午,2024中国国际大数据产业博览会开幕式在贵阳举行,华为董事、质量流程IT总裁陶景文发表了演讲。

关键字: 华为 12nm EDA 半导体

8月28日消息,在2024中国国际大数据产业博览会上,华为常务董事、华为云CEO张平安发表演讲称,数字世界的话语权最终是由生态的繁荣决定的。

关键字: 华为 12nm 手机 卫星通信

要点: 有效应对环境变化,经营业绩稳中有升 落实提质增效举措,毛利润率延续升势 战略布局成效显著,战新业务引领增长 以科技创新为引领,提升企业核心竞争力 坚持高质量发展策略,塑强核心竞争优势...

关键字: 通信 BSP 电信运营商 数字经济

北京2024年8月27日 /美通社/ -- 8月21日,由中央广播电视总台与中国电影电视技术学会联合牵头组建的NVI技术创新联盟在BIRTV2024超高清全产业链发展研讨会上宣布正式成立。 活动现场 NVI技术创新联...

关键字: VI 传输协议 音频 BSP

北京2024年8月27日 /美通社/ -- 在8月23日举办的2024年长三角生态绿色一体化发展示范区联合招商会上,软通动力信息技术(集团)股份有限公司(以下简称"软通动力")与长三角投资(上海)有限...

关键字: BSP 信息技术
关闭
关闭