Android基础工具移植说明

早前开展的计划因各种杂事而泡汤,而当遇到了具体任务后,在压力下花了两个多周的业余时间把这件事完成了。

这就是我的引以为傲的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进行验证。

     时间允许的话,我尽可能针对每一种工具的内部实现原理进行介绍。

发表评论

评论已关闭。

相关文章