早前开展的计划因各种杂事而泡汤，而当遇到了具体任务后，在压力下花了两个多周的业余时间把这件事完成了。
这就是我的引以为傲的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进行验证。
时间允许的话，我尽可能针对每一种工具的内部实现原理进行介绍。