库的层次设计

比较基本的概念，或许你已经知道，不过我曾经就是相关的小问题，致使很是诡异的编译问题，在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库。