或許 Android 應該逐漸放棄 java 改用 C/C++ 了

最近 Oracle 控告 Google 使用 Java，想賺很多錢。

java 最重要的能力 portability 已經隨著 ARM 一統天下而沒什麼意義了。

其實目前 Android 的程式也不是只要 compile 一個版本就可以全部 Android 2.1-3.2 通用，還是需要針對不同的 Android 版本去 compile 不同的版本。

很扯的是 build Android 的 source 2.2 還只能用 javac 1.5，之後的版本要用 1.6。看起來 Java 的 portablity 似乎不怎麼好。

Android 目前是有 NDK (Native Development Kit)，不過還是不是很成熟，Android 宣稱用 native 執行不會增加速度多少。

我相信，如果 NDK 弄得好，很多 win32 的程式就可以很輕易轉移過來，這也是 Apple iPad/iPhone 用 C/C++/Objective-C 的優勢。

用 java 的另一個壞處是 .apk 有可能被 decompile，可以 google .apk 如何變成 source，看起來 decompile 的 source似乎可讀性很高。

如果從資訊取得自由化的角度來看，這點就千萬要保留，還是加減用 Java 好了。

Android 手機有不少人抱怨比較耗電。其實 Java 也是造成比較耗電的元凶之一，如果一個 event  進來因為 Java 需要多 30%時間來處理，這代表 CPU idle 省電的時間少了 30%。那些 daemon 一直在執行的影響最多，特別應該優先改成 native code 執行。

最近在 Android 用 java & jni develop programs，

奇怪的是 Android 沒有像 win32 MessageBox() 的 function，有自己的 event loop，可以直接 block wait for button press

AlertDialog.Builder 沒有自己的 event loop，沒辦法弄成 block wait，造成程式很難寫，用起來也比 MessageBox() 麻煩

其實 用 android 舊的(如 2.2) env compile 的 .apk 大部份的情況是可以在新版的 android(如 3.2) 執行的。

用 3.2 會 functions 比較多，原有的 functions 大部份是與 2.2 相容的。

用 adb shell 然後用 ps 看到的。

可以看到 skype & facebook 沒在用 就用了不少 memory

看起來 java 程式應該有 shared memory 的部份，不可能吃那麼多 memory ?

gcin 有 UI/java & engine/C 兩個 process。

由於 facebook 完全沒在用，又吃 memory，怕 facebook 有 polling 的動作影響耗電量，就把 facebook 砍掉。

skype 很少用，聽說也有 polling 會吃電池，所以也把 skype 砍掉。真希望 skype 可以改成有選項不要開機自動執行。

這顯然是假的。Google 準備推出 ART  Android Runtime (ART), 是在 install 時就 compile 成 native CPU code (ARM)，讓 AP 以 native 執行，據說速度增加 100%(2X 快？)。

我想問的是，為何不是在 ADT 就直接用 java compiler compile 成 native ARM cpu code ? 需要用 ART 是那些沒有繼續 develop 的 AP，因為沒有 update，應該是很少才對。這樣就不用存 java code (dex) & native code 兩份。

最近用 java 寫一個簡單約 400 行的 service，看「正在執行的服務 Running services」，，這個 service 用掉 4.9M memory。

這個 service 沒有allocate 很多 memory，object 用完也有 assign null 來加強 memory 的 garbage collection，怎麼還會用那麼多？

這個 service 如果用 C 寫，memory 用量應該是少於 100k。如果 Running services 回報沒錯，那java 的精簡還真的是神話。

目前 Android UI & service 沒辦法用 C 寫。

如果 facebook 和 skype 都是系統內建無法移除的話, 可以去 設定->應用程式->全部, 點進去 facebook 或 skype , 選 "強制停止". Android user app 需要手動執行過一次, 他的 service thread 才有權限在開機時自動執行.

更狠一點就是 root 機, 然後直接刪 system partition 的 fackbook/skype apk ...

Android x86 emulator 在Linux 上的 KVM 執行速度最快，開機的速度接近手機(<10秒)。只是在 Ubuntu 12.04 上有致命的問題，在Android 裏面install 的 apk & files 很容易不見，好像是關閉 emulator 時沒有 flush write buffer 的關係。所以現在沒在用。

Android x86 Windows 用 Intel HAXM 好像速度沒快多少，不過 files 不會有不見的問題。

Windows Android 4.4 x86 emulator 是不是沒人用，4.4 kitkat 出來幾個月了，x86 emulator 還是不行用。

今天再試 Intel HAXM + Android 4.2.2 x86 emulator，速度接近 Linux KVM 了。不知道是不是之前的 HAXM driver install 有問題，可是執行的時候明明有說 HAXM is working.

之前的判決Google 勝訴，不過這一次的判決，Oracle 贏了。

最近開發一些 Android app，覺得 memory consumption 真的是 Android 很大的問題。1G 的 memory 在理論上應該可以做很多，可是常常會被 onSaveInstanceState, onRestoreInstanceState，甚至正在執行的 foreground Activity 也不放過。

save & restore 有點麻煩，如果 developer 是用 2G 的手機，那可能不會看到在 1G 手機 memory 不足的問題。

看到報導說，下一版的 Android 要放棄 dalvik VM (just-in-time compilation)，全面改使用新的 ART (ahead-of-time compilation) 來做了。只是記憶體管理的問題，雖然說有 KSM (Kernel SamePage Merging) 的機制可以考慮，恐怕短時間內還是無解？

Android 4.2.* 的 garbage collection 似乎不是很好，bitmap 一多，很容易爆掉。沒試過 4.4 的手機。

據說，需要大量記憶體的話，得在 android.mk 增列一個權限。(名稱我忘記了，可以偷看一下 AOSP 的圖庫原始碼) 剛下載了您寫的 AndCamera 在 N7 2013 上直接 FC，看圖軟體也在翻到第二頁後閃退... XD

已 release 新版，麻煩測試是否有改善。

android 對於 bitmap 不知道為何沒有馬上做 garbage collection，需要手動 recycle，以免爆掉。

裝了新版，在N7 2013上相機還是FC，不過檔案總攬可以用了，只是翻頁很慢。也在紅米機上測試過，相機可用，檔案總攬翻頁還是慢。是gc縮圖cache的關係？

我是用 exif 裏面的 thumbnail 縮圖，如果是別的照相 app 沒有exif 縮圖，就要變成整個 load 進來。有些看圖軟體是用自己的 thumbdb。

目前 adt 對於 support & google service library 目前是讓每個 .apk 放一份，這樣不僅浪費 disk space，也浪費 memory。

似乎應該改成從網路下載，整個系統就只有一份 library ，不同的版本可以多份。

Android 5.0 Lollipop 據說只能使用 ART 了，沒有設定可以選 Dalvik or ART。

看了 HTC Desire Eye 裡的 Android 5.0，用ART執行 一樣是吃 memory 的肥豬。隨便一個小 app 就要 50M+ 的 memory。其實Android 5 現在很多 service 是用 C 寫的。Android 的 memory 需求應該有 iOS/Windows Phone 的 1.5-2X。

猜測用 java run time 會這麼肥大的原因是因為 .so 分割的不好，造成一 load 就整個 load 進來。

java 沒有 unsigned byte, short, int …，如果需要 unsigned byte，要改成 short.

或許這是 java 比較浪費 memory 的一個原因。