关于 Android 和 iOS 流畅度的一切

2019独角兽企业重金招聘Python工程师标准>>>

之前发表了《论苹果公司的系统拖累策略》，在看了锋友的回复之后，发现无论大家是赞成或者反对，可能都对Android和iOS的认识上存在着一些盲区和误区，于是答应转载这篇专业分析两个系统的文章，以便科普。来得有些迟，还是希望各位谅解。

这篇文章对我的启发和在认识上的更新帮助都比较大，又出于我个人比较重视知识版权和劳动成果的保护，所以呢，在这里我想着重写明文章作者和出处，希望版主不要封杀：

作者：DoubleLee 出处：zealer+

-------------------------------------------------科技分割线 -------------------------------------------------

写在前面的一些话:

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

如果觉得概念太多看不下去就直接看加粗部分就够了。

我希望大家读完我的这篇帖子后，是这样的：

而不是：

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

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

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

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

不是。两者都非常顺滑，用久了也都不卡顿。Android 定义为带有GMS推送的，带有良好 Android 应用生态圈的（包括少数国内优秀应用），具有Google Play 服务的 Android 手机，拥有健康使用习惯的 Android。包括但不限于Nexus，Moto，SONY，LG，htc，Samsung 在没有封杀Google的市场的使用体验。

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

1.是。安卓（尤其是用久了）很可能会卡顿。安卓定义为不带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://**/maz6uaq

· http://**/nepu7vk

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

5、总结一下，Android流媒体性能较好，BAT是流畅度杀手，国内混乱的推送有锅。

（三）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在内的很多很多核心竞争力。Android不卡，安卓会卡，本质不是系统的问题，而是什么样的环境，用户着什么样的程序。

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

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

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

感谢大家的阅读。

以上。

8月7日 23:10

转载于:https://my.oschina.net/weichou/blog/547674

关于 Android 和 iOS 流畅度的一切相关推荐

Android App性能流畅度测评分析可以用到工具
1.前言在手机App竞争越来越激烈的今天,Android App的各项性能特别是流畅度不如IOS,安卓基于java虚拟机运行,触控响应的延迟和卡顿比IOS系统严重得多.一些下拉上滑.双指缩放快速打字 ...
为什么android没有iOS流畅,安卓系统为什么没有IOS流畅，原因究竟出在哪？
随着硬件水平的发展,安卓确实具备比IOS更强大的发展前景,目前的安卓系统确实已经具备了和IOS系统一争高下的实力了.我们先来谈一谈,安卓系统为什么没有IOS流畅,原因究竟出在哪?(深度解答).说起来安 ...
【MIG专项测试组】如何准确评测Android应用的流畅度？
转自腾讯Bugly 叶方正,2008年加入腾讯,就职于无线研发部[专项测试组].曾经负责多个产品的性能优化工作,积累大量的移动终端平台优化以及评测经验. 怎样获取SM值? 前文我们分析了通过测量应用 ...
鸿蒙系统和ios流畅度对比,鸿蒙OS对比iOS，华为再次“超越”，流畅度大幅领先苹果！...
原标题:鸿蒙OS对比iOS,华为再次"超越",流畅度大幅领先苹果! 随着越来越多的细节被曝光,鸿蒙系统也已经进入到了最后内测阶段. 近日,华为消费者业务软件部总裁公开王成录表示,华 ...
Android流畅度总结
一.谷歌官方对流畅度的解释: Android流畅运行,需要运行60帧/秒, 则需要每帧的处理时间不超过16ms. 二.IOS系统比ANDROID系统流畅的原因因为Android系统UI的框架设计的问 ...
安卓手机玩游戏卡顿怎么解决_安卓手机卡顿如何解决？教你四招，流畅度立刻飙升！...
原标题:安卓手机卡顿如何解决?教你四招,流畅度立刻飙升! 自从苹果手机进入中国市场,iOS与安卓用户之间就争议不断,主要原因还是手机卡顿问题.早些年,iOS流畅度遥遥领先,许多安卓用户都转为了苹果粉, ...
为什么Android没有iOS顺滑zz
http://www.newsmth.net/bbstcon.php?board=ITExpress&gid=1150535 一位软件工程师和前Google实习生Andrew Munn解释说是 ...
专项测试实战 | 如何测试 App 流畅度（基于 FPS 和丢帧率）
本文为霍格沃兹测试学院学员学习笔记,进阶学习文末加群. FPS 和丢帧率可以在一定程度上作为 APP 流畅度的一项衡量标准,本文介绍利用 adb shell dumpsys gfxinfo 命令获取软 ...
专项测试实战 | 如何测试 App 流畅度（基于 FPS 和丢帧率）？
为UI页面写测试用例时(比如web页面,移动端页面),测试用例会存在大量元素和操作细节.当UI变化时,测试用例也要跟着变化, PageObject 很好的解决了这个问题! FPS 和丢帧率可以在一定程 ...

关于 Android 和 iOS 流畅度的一切

关于 Android 和 iOS 流畅度的一切相关推荐

最新文章

热门文章