在纠结了很久以后，我决定开个帖子来写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制程，主频高达2GHz。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
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时，主线程已经可以同时生成第N1帧的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、安卓则是……则是几个改装厂把这些跑车们自行改装，有的厂商改的好，有的改成渣，拉到了坑洼不平的土路上，还时不时来点路障，这就算起步跑得溜，但久了对整车肯定不好。
|
