早前開展的計劃因各種雜事而泡湯，而當遇到了具體任務後，在壓力下花了兩個多周的業餘時間把這件事完成了。

這就是我的引以為傲的Mercury-Project，它的核心目標是移植一些Android底層輪子到Linux平臺上。

1. 為什麼要做這件事？

　　Android的SDK是一個大而全的東西，有很多工具可供移植和使用，例如，安卓的MPEG4Writer，MPEG2TSWriter，OpenMAX、MediaCodec等，實現的很優美和完善。

我常常想學習這些子模組是如何實現的，那麼就需要有一套SDK環境，修改程式碼編譯後，再將so庫放到手機中跑，但是這種除錯方式有些缺陷：依賴手機硬體、編譯時間漫長。

　　因此，產生了這種想法：如何將這些基礎工具進行跨平臺化，移植到通用的Linux平臺上？

2. 移植基礎庫的先後順序性是什麼？

　　如果想做一個Linux平臺的記錄儀方案，那麼就需要用到封裝模組（muxer），怎麼搞這個呢？手擼一個穩定、相容性較強的ts_muxer，沒有十天時間肯定搞不定，那麼一個

捷徑是移植現有成熟的方案，例如從FFmpeg的libavformat中抄過來，或者移植Android的MPEG2TSWriter（這個模組其實是muxer+writer），抄FFmpeg的較容易，但是抄Android

的不是那麼容易，因為依賴Andorid的底層基礎庫。

　　例如，MPEG2TSWriter模組，用到了管理類物件的sp/RefBase，用到了訊息/反射機制ALooper/AMessage/AHander。

　　前者是安卓大廈的根基之一（實現路徑：system/core/libutils），任何native層開發幾乎都離不開它；

　　後者是native層中多媒體系統子模組開發的基礎工具（路徑為這個：frameworks/av/media/libstagefright/foundation/），從名字foundation中也可以看到端倪，這裡要補充一點：

這個foundation其實又是依賴libutils的，它是對libutils的更上一層的封裝。

　　因此，可以初步總結出，其依賴鏈：MPEG2TSWriter -> foundation -> libutils。

　　libutils又依賴什麼？Bionic！這個是什麼呢？是Android版的標準C庫，等價於通用Linux平臺的glibc庫。二者都是C標準庫的不同實現方式，其提供的介面、功能行為在不同平臺上

都是一致的，因此移植工作可以在libutils這一層次上結束。

　　因襲，結論是：移植的先後順序，先libutils，再foundation，最後MPEG2TSWriter。

3. Android為什麼搞這麼複雜？

　　確實是比較複雜，但層次性非常好！一個東西流行必有其內部脊髓所在！這也是安卓生態圈繁榮的根源吧。

　　軟體開發，一個非常重要的概念，就是分層，這個跟其他行業類似。

　　例如，我D目前收割群眾的主要方式——房地產行業。

　　蓋房子，其實也分很多層次，最底層是最廉價，也是最容易被人忽略的，也是最重要的。

　　蓋房子最底層是什麼呢？做磚頭這一古老行業！再往上一層是批發經銷磚頭的，再往上是施工工程隊。

　　施工工程隊可以對比於軟體開發的上層，它不可能什麼事情都要親力親為，例如從開磚窯廠、挖泥巴、燒製磚頭開始搞？那豈不又回到了原始社會！

　　現代社會的主要特點是精細的社會分工，每個人都幹自己擅長的事情，大家的勞動成果整合起來，形成一件完美的藝術品。

4. Mercury-Project名字的由來

     Mercury中文名稱為“水星”，是太陽系中最內層的行星。

     起名字也是一門哲學，每個人都有一個名字，大家有誰想過人為什麼要起名字？哈哈。。。

     起這個名字，絕不是意味著我要或者我想移民水星！！！水星朝向太陽一面溫度400多度，背向的將近零下200度，那誰受得了？！

     NASA發射的水星探測器也幾乎受不了，呵呵。。。

     起這個名字寓意Android就是那個太陽，水星要吸收太陽散發出來的光和熱！

5. 專案目前進展

    libutils大部分工具已移植完畢，foundation中常用的工具移植完畢，並且針對這兩個庫中提供的工具，編寫了諸多測試用例。

    下一步的任務，是把libutils中全部工具都移植完畢，再有就是，對移植的工具，編寫齊全的demo case進行驗證。

     時間允許的話，我儘可能針對每一種工具的內部實現原理的進行介