有观点认为 Android 在系统设计存在硬伤，是真的吗？为什么？

看到一篇评价iOS和android系统的文章，其中有段描述关于2个系统的架构的，如下：
自苹果收购了乔布斯的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的硬伤吗？

事实上android系统卡顿的问题甚至不一定需要上升到内核层面
1：android基于linux 但linux只是一个操作系统内核，并不具有gui(用户看到的能够操作的界面)，大家手机上看到的那些图标呀滑来滑去的东西呀都是后来google自己加上去的 （此处应有经典的android架构图）
2：应用的卡顿由很多因素导致，jvm（android上是art）造成的stw只是占比不高的一个原因。
准确地说，应用开发者和系统开发者都要背锅。从应用开发者的角度来说，不正确地使用cpu和内存（例如对象没有及时释放甚至内存泄漏，在某些频繁调用的函数里创建对象，时间复杂度和/或空间复杂度糟糕的算法 没有在适当的场景使用ndk 等等等等）也会造成卡顿，这个比例其实非常高，在讲究速度的时代，一个项目很难保证绝大多数代码都遵循最佳实践。反过来说，只要遵循最佳实践，5.0以后的大部分android应用(之所以加了定语是因为部分性能要求高的应用因为硬件原因还是达不到 但近几年android阵营的硬件性能赶上来以后 可以说是几乎所有应用了)都可以达到媲美同时代ios应用的流畅度
在系统开发者层面，google做出了很多不为普通消费者所知的努力，例如：
4.x的project butter，使用vsync和triple buffer向着系统动画60帧迈进一大步，这个跟语言可没关系
5.x的art 支持了aot 从此android的流畅度正式与ios有了一战之力 但安装速度会变慢
6.x的art 使用了aot+改进后的jit 这样安装速度恢复到以前的水平 并且保留了运行速度快的特性
7.x的art 使用pgo(性能分析导引优化)和Concurrent Copying GC(并发复制垃圾回收) 提升内存占用和内存回收的效率
8.x的art 优化执行引擎
10.x的art Concurrent Copying GC 中加入了分代管理机制 进一步提升内存回收效率
注意：以上改进都是应用开发者啥也不用干就能享受到的性能红利
总结一下：导致android天生比ios慢的原因很多，语言层面的问题都只是占比不大的一个而已（而且经过多年改进，拖累已经不多），更别说系统内核层面。经过多年努力，甚至可以说并不比ios慢。
图形子系统的性能+语言性能+应用开发水平才是决定流畅度的主要原因。

最大的硬伤就是Google掏空了Linux。

Android把控制硬件的动作都放到了user space中，而在kernel  driver里面只有最简单的读写寄存器的操作，而完全去掉了各种功能性的操作（比如控制逻辑等），这些能够体现硬件特性的操作都放到了Android的HAL层，而Android是基于Aparch的license，因此硬件厂商可以只提供二进制代码，所以说Android只是一个开放的平台，并不是一个开源平台https://blog.csdn.net/hubinbin595959/article/details/58233584

既然Google选择了掏空Linux，那自然要面对Android的碎片化乃至驱动的低效了。

各芯片厂商的driver五花八门，为了满足spec，保证接口统一，不得不对driver进行层层封装，mediaserver omx hal 层层转发到driver，浪费大量的资源。
有观点认为 Android 在系统设计存在硬伤，是真的吗？为什么？

第二个问题是为了商业和平台无关性引入了JAVA虚拟机，但是为了效率又加入了NDK，导致解释执行和编译执行的优点没占到，缺点（解释执行需要更多内存资源，垃圾收集又会在垃圾手机上引发肉眼可见的卡顿；apk内如果包含了arm版的.so文件【类似Windows的dll文件】，那x86 和 MIPS等平台就不得不二进制翻译，效率低且非常容易闪退）倒是占全了。
https://www.zhihu.com/answer/3162090639

我觉得，如果真要说得上是硬伤，那就是java的应用层代码，太容易被破解了！这个确实是硬伤，你破解一个苹果的应用试试，这个难度就不是一点点；但是apk的破解，几乎无门槛，谁都可以做，很多开发者都被逼通过ndk来开发库，试图把关键的信息通过C库来完成，但是因为要和java层交互，破解起来也比苹果的容易的多；

不要被这种文章给骗了，事实上没有最好的技术，只有最适合的。引两篇文章以供参考：
1. 《微内核领域的传说》：http://techsingular.net/?p=1726
2. 《Unraveling the Mac OS X Microkernel Myth》：http://www.roughlydrafted.com/0506.mk1.html
几个被普遍接受的观点：
1. 是否为微内核，并不是操作系统内核复杂性与可扩展性的决定性因素。
2. 商用操作系统中，并没有纯粹的微内核或者宏内核，更多的是一种混合的设计。
3. Java与C++或者Objective C在性能上并非有绝对的快慢之分。
4. 垃圾回收机制与手动内存管理是互相补充的两种技术。
5. 在计算机科学领域，Trade-offs 是普遍存在的。

关于微内核和宏内核，可以参考这篇文章：
http://www.cublog.cn/u2/72217/showart_1074419.html
两种内核在移动操作系统方面的对比其实各有千秋，没有说谁一定是硬伤。
p.s一个八卦，在早期Jobs选择OSX的底层架构时是perfer Linux的，只是最后和Linus没有谈拢而已。