第一次和android的……無奈接觸

真的沒有想到，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的語言，但是不給開發人員控制執行速度，不能提供直接的本地代碼產生以獲得更好的執行效能，就讓虛擬機器在那裡白白的消耗使用者手機的運算資源和電能，這是不是有點過分呢？