很多人觉得Google能做出Android本身就是一个很了不起的工作过程，真的是这样吗？正好在Android上花过半年时间业余研究，从上到下还算是比较熟了，就说说我的印象吧：
1. 内核以开发用机G1和Sapphire做例子，内核部分Qualcomm的那部分初始工作最重要（但也称不上大项目），Google的几个mechanism实际上工作量很轻、和类似目的的成熟组件比实际上都是超级简化版，设计的也有不少有欠考虑的地方。
lower memory killer多么简陋就不说了，另一个差劲的设计就是缺乏管理的WakeLock【1】，遍布若干层的这玩意加上我个人最恨的那些没事醒着等待中断的内核代码，无论哪个地方一个小bug，就可能让你的手机待机超不过仨小时。【2】
不是说不能往内核里加东西，也不是说一出手就必须惊天动地，关键是不能一拍脑门子想出个方案就上。Android对于内核的改动，很多类似地方的设计都缺乏整体思路，与其说是一组设计，不如干脆说是一堆hack来的确切；所幸Google在这这里干的活不多。
2. 中间层能把这么多不同的开源项目粘一起确实是个费心的工作；不过说到具体的活儿，基本上就是因为license和手机环境的设置，照着别人代码抄一遍，掏空一些逻辑，换上一些逻辑。这一块主要是麻烦事儿很多：从总体上来看，这些麻烦还是被Google较好地控制住了的。
但一些组成部分的选择还是存在不小的疑问：如媒体框架，我不知道Google怎么想的，非去买PacketVideo的。估计是这公司和Qualcomm有传统友谊？总而言之自己没信心做也就算了，买也不买个好点的；弄这么个伪面向对象的丑陋的庞然大物，基本上每次新版Android推出都是让手机能正常运转的障碍：太难挑bug了，以至于Google自己都懒的调好。
我个人的认识是，Google在这个层面的工作虽然已然不错，但缺乏真正的精耕细作。在工程上这或许是合理的，发布之后可以回过头慢慢揉合。但这种发展方式必然要求你有很好的上层抽象，不影响上层建筑。于是问题就变成：Google做到了吗？
3. 运行时引擎说白了就是Dalvik这部分了。这个虚拟机基本上是2000年以后最糟糕的一个虚拟机，而且做这个放到21世纪也没什么技术含量了。说实在的如果说重量级程序员最多需要两、三个足够了，打杂的也不需要几个；很多时候咱们平时不会自己从事这个方面的开发，不是说这个工作就一定是什么难以逾越的大山。
这个部分说白了又是一个照例子抄的活儿，却做的无比的落后，快赶上Python那个解释器的水平了。不过我相信HTC之类的厂商一定也有他们自己的想法：我发现HTC在这个部分加入了自己的一些内存管理逻辑，想必是Google又让他们的在某些情况下郁闷了吧呵呵。
我的一个问题是，为什么不更改V8去适应强类型呢？应该不是技术上的问题，而是公司内部统筹安排导致的工作成果和人员不能重用吧。在Android刚推出的时候，我就看到过一个多媒体应用的开发者抱怨，说Android处理XX的速度比Nokia的J2ME还慢，不得不写Native代码，想想看，Nokia用的可是更垃圾的CPU!
4. 整体运行时环境说起来第一就是Java类库了，这部分也基本上是照抄加简化，否则也不至于让Oracle抓着把柄。实现Java类库这方面，我的感觉，就是你要把这部分工作放中国来，5000～7000的程序员雇上个20来个，很可能3～5个月就能做出Android 1.5的质量了。这部分Google的实现存在一些问题以前提到过，不过都是些容易改善的。
多出来的是界面层、进程内外通讯、功能的配合和不同应用互操作这部分，以及整体上有一组适用于移动嵌入式环境的策略及对应的设计实现。其实这多出来的部分才是Android的核心，上面三个部分虽然更“底层”，却是服务于这一层次的目的的。（设计一旦确定，以Android的方案来说，其难度和工作量都不大）
很遗憾的是如果仔细斟酌，却会发现Google方案在一到具体应用上漏洞百出。其中一部分牢骚在我上篇文章里提到过了。其他的话题比较大了，很难一句话说明白。不过如果站在开发者角度，并仅仅在Java层进行开发的话，中肯的说除了Java本身带来的缺点和一些细节，基本上还是和ASP.NET 1.1这类东西在一个水平线上。
5. 纵观各子系统周边输出子系统虽然相对不重要但很说明问题，比如notification要决定LED灯一类的表现，开始的设计就过于具体的服务于G1/Sapphire，导致厂商有了其它设计的话，全都按自己的方式四处瞎写代码，完全破坏了原有的安排。但人家厂商也是有苦难言：你压根就没给人家一个合适地架构和接口。
输入子系统也有类似的问题，虽然现象不同但它设计的也固若金汤铁桶一般。你如果想从Java层以下，内核层以上自定义一些行为，又不能够或者不想硬改代码（改了Android升级了你还得同步），除了挂钩子，唯一一条出路就是对内核动手了。天杀的，我宁可Google设计的时候能多考虑些我痛骂过得方法论了..
网络子系统的话，已经有的TCP/IP栈肯定是没问题了，VPN之类的弄点开源代码改吧改吧实现的也没问题了，可是启用WIFI分配地址神马的时候，居然沦落到用脚本钩下环境变量用作通知，让人怀疑设计神马的都是浮云... 我寨威武！蓝牙子系统也拿的是套开源方案，按内行（就不说是谁了嘿嘿）的话，恨不得自己上手重新实现一下。
图形子系统正常使用不会碰到什么麻烦，看了看相关部分的代码，最主要的问题是来自接口过于简陋，对各种情况估计不足，出现bug的时候厂商就只能见招拆招了。比如图像缓冲和摄像头传回数据之间的大小不和，其结果可能是相当诡异而不是有个明确的接口甚至约定来处理这种情况（记住摄像子系统的接口也是被Android设定和限制的）。
内存子系统，传统部分我没有太多的疑问，关键在于设备特定内存上【3】。这部分的设计简洁、但却缺乏更多的考虑。比如这些特定内存是被鼓励分门别类的管理；这种设计导致这种设备特定内存在一些机器上不够用，以至于可能无法发挥芯片最大能力。【4】
多媒体子系统整体还是比较清晰和简单的，而且似乎也没简单到了不够用的地步（我对什么是好的多媒体子系统毫无经验）。不过默认下挂的OpenCore多媒体框架，前面已经提到过了，深恶痛绝。不知道Google自己的那个框架现在成熟了没有，什么时候换上，还有....会不会更糟糕，T_T
Camera子系统第一个版本接口及定义就很差劲，说它将将够用都是夸它了，第二版也没好到哪儿去，跟内存子系统、图形子系统和多媒体子系统真可以说是分庭抗礼对着干。一些配合设计的也是莫名其妙，比如一些数据不是由上层逻辑完全控制的，而是由底层某个接口暴露出去然后直接在台面底下转帐给别的子系统。这不，第三版又来了。
声音子系统呢，我个人没碰到过什么麻烦，最基本的应用本身也比较简单，就是从中间层走到内核去；有硬解码什么的在高通方案里转内核给硬件负责了；不过我想这个子系统的内行一定不满意，因为首先用户就有不满意的：声音有延迟。
我觉得最好的应该是传感器子系统，为什么这么说？因为我从来没感觉到来自这方面的问题 :)。不知道以后传感器种类进一步增加的话会怎么样，想必Google现在也更有经验了吧。
总结把所有方面总结一下的话，基本上稍微有有复杂性的部分Google都是绕着走的，凑在一起以后也不好好适配，很多地方缺乏一致性。然后无论是买还是拿来或者自己决定的事情，拍板经常拍的缺乏仔细考虑。大不了永远的beta慢慢改呗..真是服了。
当然，整个系统有几个子系统的接口无论好坏毕竟需要用脑子设计，还有整合、除错、周边工具的工作量，如果想达到能推出、广泛使用的地步，光一个十来人的小组肯定不够的。但作为这样一个众口称赞的大型企业，动用那么多人力物力，弄出这样一个“操作系统”，真有点对不起Google一贯给自己渲染的光辉形象了。
其实Android本来就不是“从头”来的项目，我想倒是因为Google实际上有一切大公司的弊病还缺乏传统操作系统开发公司的优势，所以在Google介入后设计合理程度和质量才这么差。
注【1】：顾名思义，这东西是防止手机进入休眠状态的一个锁，即便是官方ROM都曾经出现耗电量剧增的现象，大多都是这个锁的使用导致的问题。
注【2】：事实上整个电源管理这块，在Android刚推出时就被这方面资深的第三方开发人员痛骂不是没有道理的。
注【3】：虽然原因不同，但为这个内存设备驱动，Linux的一个核心人员几次拒绝了Android提交的代码，属于Android最终被Linux扫地出门的导火线之一吧。（在这个问题上我并不完全支持内核小组）
注【4】：想想看本来能用的内存在Android下却只能闲置，就能理解这个问题了。比如在MSM7200a方案上，分配给Camera和DSP的空间在大多时候被浪费，而mdp操作却只能使用非常有限的物理内存；反过来DSP也不能使用本来设计使用的空间，于是VGA视频压缩就彻底被取消了。
P.S. 没想到能写出这么多，其实最近时间有限，好久没有碰Android了。写下的基本上都是我印象比较深的，肯定还有其他问题没有提到。不过Android的意义，不仅仅是因为它本身是开放的，更多的它让手机开始开放。虽然这和BootLoader加密加得不够好也有莫大关系，但无论如何这也是一件好事。