一個的設備程序如果完美庫化，它意味著：

1.所有工程師在移植或創建該設備驅動時，花費的代價超小。

2.隨著使用者的增多，它飽經考驗，不斷趨于穩定，變為當之無愧的公共代碼。

3.庫對外的接口(函數名及其參數聲明)是不變的，當所有常用設備都實現庫化時，它帶來另外一個好處，應用層的移植、創建、修改維護的時間耗費也會劇烈減少。應用層的跨平臺無縫移植不是傳說，當它所依賴的所有外圍設備通通在不同平臺庫化的時候，應用層的實現，就像在寫java代碼一樣。

4.庫意味這公司核心代碼的安全，庫代碼只掌握在核心工程師手里，應用層的程序即使丟失也是無礙。

5.新人對于這些基于庫案子更快上手，一來有庫幫助文檔的說明，二來不必也無法關心底層細節，專注于應用開發。

6.提供給客戶二次開發，你可以把硬件和外設驅動的庫交給客戶，讓其二次開發。

7.通信協議的庫化，將使通信系統類的產品更加安全，至少不會被離職的工程師破壞，比如RFID的扣款充值。

8. ......

怎么樣，它使老板心動，工程師百味雜陳。

當然，有些工程師會想到，庫可以使他脫離繁瑣的底層驅動工作，進行更高層次的工作。

庫的創建要想搞得好，有以下幾個條件

1.提供給客戶的只有.h檔和.lib檔。

2.所有.h檔中沒有define，編譯條件對于.lib檔來說只是一個笑話。

3.所有.h檔中沒有extern變量，如果有，這意味著系統只能創建一個這種設備。比如蜂鳴器驅動，如果extern變量，就意味著整個系統只允許一個蜂鳴器。

4.完善而詳細的使用幫助文檔。可參考keil的hlp文檔格式。

5.簡單的使用該.h檔的demo程序讓人參考。

6.“動態鏈接”庫代碼，簡言之，沒用到的接口函數代碼不會被鏈接器搞到最終的二進制檔中。

7.還有一點，盡量的平臺無關性，它不依賴于任何寄存器或者其他和平臺相關的東西。

要達到上述的目的，通常會使庫有如下特點

1.結構體指針

2.大量的回調函數指針。

3.豐富的接口。

4.庫源碼的.c檔將按接口函數拆分成更多的.c檔，這為了實現鏈接時代碼空間最小化。

庫的缺點也是有的

1.它會使設備速度變慢一些，多了幾層間接取址的消耗。但對于32位機，對于它帶來的便利，還是可接受的。

2.它會使code空間消耗相對更大一些，但請相信我，對于一整個中大型系統而言，它會使代碼量不升反降，因為大系統中有非常多的重復冗余代碼。這方面我個人的經驗，降的不是一般的多，簡直到了一個難以置信的程度。

早期的8位機，51平臺上其實不能很好地實現完美的庫，至少是不能實現一個跨機型的底層設備驅動庫。近年來隨著32位機的興起，庫漸漸地受到越來越多工程師的青睞。這里面最本質的原因在于，51架構的棧是靜態編譯的，局部變量和傳參的棧也是靜態的，函數無法重入。而多數的32位機都是壓棧傳參的方式。當然，51速度慢也是重要的原因之一。

如果有熟悉面向對象語言或者linux驅動的朋友，你大概就明白一個好的庫是什么樣子的了。庫就像是面向對象中的類，至于linux底層驅動的代碼，那就是函數指針和結構體指針的世界。C的精華在指針，在里面得到完美的詮釋。

當然，庫的代價也是有的

1.它會使設備速度變慢一些，多了幾層取地址的消耗。但對于32位機，對于它帶來的便利，還是可接受的。

2.它會使code消耗便大一些，但請相信我，對于一個中大型系統而言，它會使代碼不升反降，因為大系統中有非常多的重復冗余代碼。