接下来一段时间,我决定把安卓的常用基础工具做一个总结。以便给读者一些启示,算是抛砖引玉,或者是对自己研究心得的记录吧。(格式写的乱,读者自行脑补分段吧。。。)

 

1. 一个问题:安卓native层开发为什么可以用较少行代码实现一些复杂的业务逻辑操作?

  对于这个问题,有些人可能觉得并不是,像Android中的AudioFlinger模块,太冗长、啰嗦,类之间的关系巨复杂了!还有OMXCodec编解码相关的内容也是绕的云里来雾里去!

2. 待介绍的内容

  今天,我对于Audio的native框架、音视频编解码这些较上层的框架相关内容,暂且不做介绍,而是要介绍再下一层的东西。

  这一层,是在bionic之上,具体业务(像音视频编解码框架,audio框架)之下的一层,为公共基础库,可以被各个模块使用。

  实现路径为system/core/libcutils/,头文件路径为system/core/include/utils/,编译出的库为libutils.so。

  可以看到安卓多媒体中间件的源文件基本上都包含了这些头文件:#include <utils/xxx.h>,并且makefile都链接了这个库libutils.so。

3. 问题答案

  上面问题的答案,就是“封装”!

  再用一种说法是,提供一些轮子给你使用,来简化你的工作量。

  然而,大部分人是使用“轮子”,极少数人造“轮子”。有些有想法和野心的人,去造“轮子”,搞了半天,结果不得不承认,还是别人造好的轮子香。

  当使用大量可复用的基础工具时,可以大大简化具体业务的开发工作量,你只需关注你所在层次的业务逻辑,而不用花太多时间去考虑底层细节。

4.为什么

  上层的业务开发工作基于这些被严格测试和验证了的基础工具来展开,可以快速高效实现具体业务逻辑,把我们的精力和焦点放在具体业务逻辑上,而不是二者同时考虑。

  一个比喻,盖房子的问题,当盖第一层时,可以直接动手开干,几乎不需要借助其他工具,但盖第二层甚至往上时,我们需要借助一些工具才能干活,例如各种脚手架。

  再有一个通俗易懂的比喻,我们目标是造一辆山地车,主要精力是拿各个厂商的零件去组织装配就可以了,例如拿Shimano的变速器,拿米其林的轮胎等等。相反,另外一

种做法不可取:山地车商又组织一批人力去攻克变速器和轮胎技术。

  再有一个例子是,EUV光刻机巨头ASML,也不是每样东西都研究,像光学镜头这种东西也不得不让Carl Zeiss定制,NASA的哈珀望远镜的镜头也是让Carl Zeiss帮定制的。

这个没办法,光学镜头人家研究了一两百年,自己短时间突击肯定达不到别人的高度。

  这也体现了国际分工和全球化作用,那就是做自己最擅长的事情——业务聚焦。

5.具体介绍细节

  回到这个问题点,可以这么说,只有把基础工具的实现原理了解清楚,上层业务开发才更快速和高效,而不用再从造轮子开始做起。读android中一些模块的实现,

我们也不会因调用逻辑不清楚而晕头转向了。

  接下来呢,我将利用几篇文章来介绍相关工具,并利用demo来验证这些工具。这些工具介绍都是基于Android4.4版本,demo都会上传至我的github仓库

这些工具内容涉及线程类、原子操作、互斥锁、RefBase、容器类Vector/List、堆栈调用、sharebuffer、hash类等等。以及应用于多媒体中间件部分的更上一层的工具,像

ALooper/AMessage/AHandler消息机制模型。

6.个人期望

  我的目标让读者明白两点:如何实现 + 如何用。

  前者是修炼内功的过程,后者是投机取巧摘取胜利果实之举。当然,由于每个人的分工、负责模块不同,也不必都去了解底层轮子,而只需了解如何使用就行了。

  再对比解释一下,黎曼猜想(素数分布规律),已经存在了整整160年(提出于1859年),各路数学家们前仆后继,无不希望解决这个问题,以此让自己永载史册。但一百

多年过去了,数代的数学家们无从开始时的乐观,经过多年研究论证后又转向悲观。如果你证明了的话,再退一步——即使你能使证明过程推进一大步,那你将立刻登上全

球各大媒体头条,问鼎年度数学界的诺贝尔奖——菲尔兹奖(对年龄有限制)或阿贝尔奖。黎曼的短短八页的论文论证过程,明显是大大高估了读者的水平,那些公式中的很

多被黎曼称为“容易得到、易证”的表达式,后来的数学家们都要用尽心力、穷尽几十年才能得到证明。可惜天妒英才,39岁时就不幸因病去世,但是他留下来的为数不多的

文,足够后世人类研究几百年了。

  了解了其证明之艰辛大多人都放弃,仅停留在使用这个猜想层面上,毕竟,还没有发现一个反例来说明这个结论是错的,如果不对,那么,在这个猜想基础上造的上层

建筑,都会轰然倒塌。

  这件事情有多艰辛呢?一个对比的例子是,费马大定理存在了350年,被称为“末日难题”,多少代数学家使出浑身解数,都期望攻破定理的证明。最终一个34岁的年轻数

家(20多岁就成为了普林斯顿大学的数学系教授)决定攻破这个关头,在计划开始前,他就对自己说:接下来面对的,是可能长达10年甚至更长的专心致志、默默无闻的努力。

在此后的七年里,除了他妻子,没人知道他在干什么,除了吃饭、睡觉和散步,他无时无刻不在与那个顽强的敌人进行贴身缠斗,光是准备基础知识和关于这个领域的前人的

成果,就花了18个月时间!最后花了七年时间攻破了这个三百多年的世纪猜想。

       那黎曼猜想的难度丝毫不亚于费马大定理,这个问题同时存在于希尔伯特在1900年提出的20世纪需要解决的23个问题,以及克雷研究所提出的“21世纪7大数学难题”,后者

任何一个难题,如果你解决了,立刻能拿到100万美金的奖金。但是,这可能是世界上最难挣的钱。

  这正如这些软件的底层轮子,首先你要确认一点是——别人做好的并且在广泛使用的东西应该不会有问题,因此,你不必再重新造,了解功能、适用场景、会使用就行了。

  这也是无奈之举,大部分人都逃脱不了凡夫俗子的命运,除非你喜欢折腾。。。呵呵。。。

  。。。。。。

  今天太晚了,就先写到这儿。