Android整体印象

    很多人觉得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设定和限制的）。