庫的層次設計

比較基本的概念，或許你已經知道，不過我曾經就是相關的小問題，致使很是詭異的編譯問題，在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庫。