Android Thread Safe / Lock Free / Atomic 小註解

Atomic (原子) 通常是指一個指令不會被打斷, 例如一道組合語言的指令, 在沒有執行完之前, 就是 ISR (interrupt service routine) 也無法干擾其結果. 同樣的概念如果放到 function 上, 就很難說這個 function 從來都沒有打斷過了. 我們頂多說這個 function 的結果是如預期的.

怎麼樣保證如預期呢?在 Android 當中的 atomic.c 採用暴力的方法進行, 例如要做一個 write.

void android_atomic_write(int32_t value, volatile int32_t* addr) 顧名思義想把 value 寫到這個 addr,  而它裡面的內容就是:

{

int32_t oldValue;

do {

oldValue = *addr;

} while (android_atomic_cmpxchg(oldValue, value, addr);

只要 OldValue 沒有 value, 這個 loop 就不善罷休. 所以一定可以寫成功. 只要成功了, 就準備離開. 大家可以發現, 如果此時別的 thread 也來寫同樣的位置, 那就出事了. 

為了避免後者的狀況發生, 我們最好不允許這個在有效期間之內又被改掉. 解決之道是 lock 此一變數, 直到 unlock 之前, 都不讓別人改寫. 不過 Android 的 atomic 是 lock-free 的, 所以不需要用 lock. 相對地, 它讓其他的 thread 不會影響到當前的 thread, 也就是確保 thread safe.

怎麼做到 lock free, thread safe 呢, 簡單地說就是避免使用全域變數 (global variable), 只用區域變數 (local variable 或 auto variable). 此時每個 thread 都只針對自己的記憶體空間操作, 就不會影響到別人了.

此外, 我們可以指定哪些變數必須是 automic 的, 例如宣告成:AtomicBoolean, AutomicInteger, AutomicLong, AutomicIntegerFieldUpdate<T> …等等就有保護作用. 這些描述在 java.util.concurrent,automic.

當然, Android 還是有 lock, class 是 java.util.concurrent.locks.

[ref]

1. Android SDK

2. Lock-free atomic operations in Android

3. Thread-Safe的理解與分析

Android 執行應用程式的方式

Android 執行應用程式的方式大概有三種, 直接從 Native Service Binder 呼叫 HAL Library, 或是透過 Native Service / Daemon 來呼叫. 如果只用一張圖表示, 它長成下面這樣.

其中 Native Serice Binder 若直接呼叫 HAL Library, 相當於 Application 用 Binder IPC 呼叫 Run-time Service.

Application Framework 和 Library 這兩層包括的東西, 還是直接看標準版的 Android System Architecture 圖最容易了解, 再次貼在後面.

Android Function Call:

Android System Architecture:

[note]

1. IPC = Inter-Process Communication.

2. JNI = Java Native Interface

Quadrant Benchmark 小註解

 Quadrant  是 Aurora 公司推出的軟體, 功能是測量 Android 系統的效能. 相較於 Windows 有官方的性能評分工具, 但是分數的間距很小; Quadrant 比較像是 3D Mark 那樣, 能夠給出比較拉得開的分數. 除了總分, 也可以對 CPU, Memory, IO, 2D 和 3D 做出評價 (Advanced 以上的版本).

假如不用 Quadrant, 有沒有其它的代替方案呢? 有, 前三名還包括 Linpack 和 Neocore. 據說 CF-Bench 也可以測多核心 Android 系統的效能, 差別在於它不測 GPU.

只要用 Google 圖片去 search quadrant, 就可以看到很多 “第一名" 自拍. 我看到最厲害的是 3278 分. 客官啊, 這個 bench mark 的 bench mark 是 1 千多分, 破 3000 分是怎麼來的呢? 原來是有人破解了 Qudrant 的計分標準. 它的罩門在於 IO 速度這一項.

這位 Cyanogen 老兄發現, 只要把 Qadrant 測試用的目錄, 設在用 memory 模擬的 file system 下面, 就可以靠著 IO 方面的優勢, 獲得不可思議的高分. 引用 WIKI 的說明, 下面原文中提到的 tmpfs, 就是用 mount -t tmpfs -o size=1G, nr_inodes=10k, mode=0700 tmpfs /space 之類的指令, 把 1GB 的記憶體, 指定給 space 這個目錄夾使用. Quadrant 拿這個資料夾去測 IO, 當然就不察而給予過度高估的評價.

In Cyanogen’s tweet, he says he was able to exploit the flaw to get obscenely high Quadrant benchmark scores by mounting “a tmpfs over quadrant’s data directory.” A tmpfs, or temporary file storage system, can artificially inflate a device’s I/O score and provide unreal benchmark improvements.

這篇文章的原作者提到, 既然 Qadrant 有 bug, 所以參考意義不大. 不過我想到如果各家廠商要 PK Qadrant 的時候, 說不定也可以用這個技巧來欺騙對手…哈!

[ref] http://briefmobile.com/cyanogen-demonstrates-quadrants-flaws

Android Market 的運作機制

當我們從 Android Market 買一個 Application 的時候, Market 的 client 就會去問 server, 這個 application 對於這個 user 的狀態是什麼? 此外, 這個狀態不只是付費了沒有? 而是包括了詳盡的特殊條件 (custom constraints), 比方說只是試用一段時間、只能裝在特殊的平台…等等的 policy.

當 application 在 check status 的時候, 會產生一對 RSA key 來做加解密. Public key 會存在 myApp.apk 裡面, private key 用來與 server 溝通. 當 Application 想要知道它的license status, 它可以 call License Verification Library (LVL) 裡面帶有 callback function 的 library checker method.

Market client 負責與 market server 溝通, 它會收集 Google Account username, 手機的 (International Mobile Subscriber Identity), 和其他資訊送給 server 確認. Server 檢查過 user 資料, 並且檢查過購買紀錄之後, 就以 call back function 把 license 的狀態傳回給 client.

在 Java 的理想下, 一隻 AP 可以 write once, run everywhere. 不過前提依然是要能夠賺錢. 不收錢的軟體, Android Market 就不需要動用 license 檢查的機制的, 但對於收費軟體,  Android Market 讓花功夫寫軟體的人, 可以保障他的權利, 只要這個軟體是透過 Android market 所發佈的. 為了追蹤合法性, Android market client 必須要先在 host 上面跑 Android 1.5  以後的版本.

為了要確認 license 的狀態, Android 必須要上網, 或者是記住 (cache) 上次上網的狀態.

[ref] http://developer.android.com/guide/publishing/licensing.html

 

Android 與 Linux 的關係

我們的競爭對手紛紛把 Android 列在他們的 feature set 上, 對於跑 Linux Kernel 的本公司, 感覺好像有點落後~~~

但是 Android 是另外一個 OS (Operating System) 嗎? 不是的! 雖然 Google 強力把它包裝成Google 的 OS, 不過它其實是某種的 Linux. 這也就可以解釋 Google 為何又想要搞另外一套 Chrome OS 出來, 因為 Android 畢竟不是 Google 自己養大的孩子, 只是把別家的孩子抱來養, 穿上 Google 家的衣服而已! 既然 Linux 是受 GPL 授權保護的 open source, Google 當然會覺得養自己的孩子比較保險.

那麼 Android 是怎麼做到的呢? 首先, Google 在 Linux 開了一個後門, 把某些核心程式搬到 LInux 的上頭來, 不再受 Linux 的管轄. 在下圖中黃色的這塊就是 Android 的核心, 各位可以看到它建設在 Linux 的基礎上. 這樣大家應該可以瞭解 Android 是如何寄生於 Linux 的架構.

[圖片遺失]

Mr./Ms. Days (MMDays) – 網路, 資訊, 觀察, 生活 這個網站上, 對於 Android 有很多篇相關的好文章, 大家可以參考這裡的介紹.