库的层次设计

比较基本的概念，或许你已经知道，不过我曾经就是相关的小问题，导致非常诡异的编译问题，在framework.jar中我依赖了一个我们qrd的jar库，导致编译失败。 在bionic的libc中试图通过liblog打log，确也编译失败。这两个编译失败，单从编译log来看是无法解决的，只有了解以下的基本概念才能解决。 下面是吸取教训后的自我总结。 

设计库时，我们需要划分层次，类似于osi 7层协议那样，使用低层服务并向高层提供服务。 对于库而言，要使得某一层次的库可以访问，依赖低层次的库，并向上层库提供服务。在自己这一层次必须做到自包含。违背这一准则，会导致库定义重复和内容混乱以及可能的循环引用问题。 

几个例子

linux中内核处于最底层，然后是c标准库，然后是用户空间库。所以，内核库不能依赖c标准库以及任何用户库。c标准库可以利用内核库（通过os api进行系统调用）并向所有用户程序提供基本的c库支持，但是不允许引用任何用户库。 用户库则允许使用内核库以及标准库。 

android java库层次。   

最底层是java核心库，然后是android framework.jar, 然后是用户实现的第三方库。 java核心库不依赖任何上层的库。 framework只依赖java核心库，不依赖上层用户库。 上层用户库允许使用java核心库以及framework库。