别的不提了，最让我恶心的是它因为各种各样的原因自己不知不觉就会启动好几个我根本用不着的程序和后台服务，有时候甚至让人觉得匪夷所思，然后这些进程还就在那呆着了。
android管理内存的方法叫做low memory killer，这东西简单的不能再简单，就是留比如30M缓冲，你启动一个新程序可以往这30M里放，同时它再清出30M；也就是说这个时候去结束它觉得没用的程序。
这里头有一个核心思想，就是我花钱买的内存不是用来空闲的。保证越多的程序在内存里，那么切换进这些程序的概率就越高，如果中奖了速度就会更快。
这个道理听起来再正确不过了，可是一个处理不好，就是android这样的老牛拉破车的结局：你搞不清楚什么时候CPU或者内存就被别人占用了，于是间歇性的会明显感觉到不流畅。可惜Google就是处理不好这个，很容易就在这个缓冲的边界折腾来折腾去。
仔细观察一下android下Java程序的架构就知道，有时候你仅仅需要一个简单的动作，这时候却牵连出一大堆占内存的东西。不知道这到底是赖面向对象的组织方法呢，还是赖Google没设计好。
另一方面，这种设计就很难约束开发者；随便拿一个Process Monitor看一下，仔细一琢磨就知道，很多时候很多软件的不同模块之间没必要的牵连太多，功能分布不合理，尤其是这些程序如果是作为Framework的扩展和围绕常用功能集展开的，比如厂商自定义的东西，就完蛋了。
这就是为什么Sense界面和原生Android在轻量级使用时空闲内存会有那么大差异的原因（HTC的主设计师应该开掉），以及为什么Android会不可思议的时快时慢的原因（和其它厂商相比）之一。
让我们再观察观察Settings.apk。这玩意有什么内容？居然要占走几M十几M的内存。为神马为神马这是为神马！能够快速加载和启动的程序，或者程序中的某一部分，根本就没有必要留在内存里。我们可以说，Google这种常驻内存的策略，最终全都优惠在那些驻不驻内存用户根本察觉不到的东西上了。
那另一个影响速度的原因是什么呢？是那些该死的服务：虽然看起来Google想规划一下这个事情，但是至少目前，这些服务还是会经常性的和用户当前操作去抢CPU资源。
让我们看看Linux内核编程是处理这个事情的：接着中断的例程必须尽可能快速的结束，把大部头工作交给一个队列去做。Linux内核程序员全都懂这个事情，但你Google没权利要求我们像做驱动那样做应用，更何况整个运行时设计的素质让开发人员处理这个比在内核里还难！
（Android的主设计师应该开掉，你知道你设计的是什么东西吗？）
不知道竞争到底会走向百花齐放还是就这样了。如果真的硝烟再起，我要说的是，只要有一家肯真正努力，Android一定完蛋，不管它那时候是3.5还是9.0。因为大规模更改运行时去达成合理化，等于直接把App数降回史前时代。
不过这些也真难说了，从最上到最下，从最大到最小，世道变了，人心也变了。哥们我是不得不关注这些方面寻找机会，有朝一日财务自由了，宁可回去当原始人也绝不忍受这种对付事情的产品。
P.S. 一旦有了真正的竞争而不是几个寡头垄断，战火烧到PC平台也不是没有可能。到了那会儿第一个销售收入下降的就是可怜的Intel，因为大家发现居然有免费的午餐，下载个盗版XYZ就能让体验好一倍... （我这篇文章说的是体验，不涉及真正的执行效率，虽然这方面Google跟竞争对手比也是个新手中的菜鸟）