真的没有想到，android SDK里带的那个Emulator，竟然可以那样慢!
最近接了份扯淡的工作，总结套方案评估android的运行性能，从里到外！之所以说这份工作很扯淡，是因为我从来没有搞过android。算了，管他呢，只要能按时往我银行帐号里打钱，其它神马都是浮云，OK，开工吧。上网查了查，当然主要是研究了一份旧的报告，总结了一下，大概是需要三个工具：
1. TraceView
2. DDMS
3. OProfile
先搞TraceView吧。根据我多年的经验，一旦你想搞个你不会的东西，你要学的东西的数量，马上就会进行几何膨胀！果不其然，要用TraceView，就要会用Emulator，因为我没那台Google出的开发用手机啊，用Emulator，就要会创建那个android virtual device，要会添加sdcard。看了好多文档，转了一大圈，会了好多命令行参数后，突然发现SDK的图形安装器里竟然带了GUI版的AVD工具，靠，你到是文档里说一嘴啊。接着是搞ADB，什么的缩写来着？管他呢，反正是个remote debuger，等等，要先启动Emulator，那就启动Emulator吧。嗯？怎么说avd不存在，什么原因？回头再看文档，原来是刚才创建的avd，要用名字引用！它竟然给刚才创建的avd目录弄了个全局可查的别名！我说刚才那个名字是干什么用的呢，作为一个多年的开发者，我对这种自作聪明的兜圈子做法实在是深恶痛绝，直接给Emulator的命令行里添加ADB的父目录多好，弄个别名必然要增加学习成本的啊，哎～。好了，神马都好了，Emulator终于启动了，等了好一会儿，咦，怎么光显示个ANDROID图标，不显示桌面呢？什么地方搞错了......打开浏览器，开开VPN，准备继续研究文档时，手机桌面终于出来了.....
这东西怎么会这么慢啊，我的机器好赖也是core 2 duo，4G内存啊，桌面操作就像老牛拉解放，迟缓的让人发疯。看看资料吧，分特，Google太有才了，竟然是个ARM版的QEMU虚拟机，上面又跑了个dalvikt虚拟机！Emulator就是个验证应用程序行为的工具啊，性能评估什么的，必然要留给真机去进行，就不能学下苹果，把Emulator搞成本地运行？
出去抽根烟，平复下心态，还是写验证程序吧，从网上扒了个HelloWorld，装了个Eclipse，下了个ADT插件。呀，好神奇啊，Eclipse这东西竟然可以不编译代码就直接运行！再仔细看，原来是在编写代码的时候就进行编译了，想想也对，Java程序确实可以这样，我不好评说这个功能到底好不好，我个人是觉得编辑代码的时候一卡一卡的太影响情绪和思路了。
终于从Emulator的sdcard文件中取出trace文件，打开TraceView工具查看吧。嗯～嗯～嗯～嗯？call stack图哪儿去了？菜单上好像没有选项啊，回去查文档，我X，这也太过分了，还要去装Graphiz那个古老的网络图生成工具！这个实在是有才的过分了，既然你都做了个GUI版的trace查看工具，干吗就不干脆把call stack图显示也集成进去？
从开发工具角度来看，android只能说是个半成品，它的学习曲线太陡峭了，另外，也吐槽下java，10年前，sun说，将来CPU变快了，内存变便宜了，java的执行效率问题就不再是问题了。在这个ARM处理芯片都运行在1Ghz的年代，基于java的Eclipse（这个东西界面很多库还是本地代码的）在我的Core 2 duo机器上还是那么慢，看来虚拟机code的执行，是根本没法达到一个满意的程度的，我现在也理解了，为什么桥不死一直对java不感冒，对于注重用户体验的苹果来说，java的运行缓慢和不明所以的内存使用量暴涨或者是间歇性的卡壳（好像是GC的缘故），真的是如垃圾一样。
BTW，我觉得确实需要一种像java那样的，语法级尽量防止程序员犯错（.net加了过多的扩展已经背离了这个准则），拥有GC的语言，但是不给开发人员控制执行速度，不能提供直接的本地代码生成以获得更好的执行效能，就让虚拟机在那里白白的消耗用户手机的运算资源和电能，这是不是有点过分呢？
