Chromium瀏覽器組件設計意圖
在文章開始之前。我要嘰歪幾句，一上來就看Chrome的代碼。簡直暈頭轉向，摸來摸去莫不著頭腦，好不easy看了一點點代碼。卻猶如瞎子摸象。無法眾觀全局。以下這篇小文，簡介當中一個重要的模塊--Component的設計，為我們閱讀Google的代碼打開思路。
概述
Chrome瀏覽器組件是一個google的一個項目。它用來不斷的模塊化Chrome的代碼。把整個content模塊從src/chrome文件夾下抽取出來，雖然組件項目付出了不少努力，到眼下為止，這個文件夾(src/chrome)仍然是最大的互相依賴的模塊。
因此，抽取src/chrome子模塊仍然是google團隊下一步的工作之中的一個。
目標
眾所周知，Chrome項目在過去幾年中，不管是代碼還是復雜度都增長了很多。對這個項目貢獻代碼的人員數量也添加了很多。並且。google也添加了很多目標平臺以及配置，這些並沒有在項目啟動初期被他們預見到得到。對每一個人來說，要理解整個架構變得越來越難。更別說全部代碼了。
Chrome瀏覽器組件項目引入了模塊化並強制運行，目標例如以下：- 按比例增大架構，使得瀏覽器更適合需求變更。比方：使用src/chrome/browser模塊的瀏覽器希望關掉或者又一次實現某些模塊。比方安卓上的Chrome;
-
通過進一步實現依賴關系圖，我們想要實現的架構變得更清晰。
那些依賴規則指出哪些子模塊是同意的。哪些是不同意的。
- 大大簡化了src/chrome子模塊的依賴關系圖，使他們不循環依賴;
-
通過添加很多獨立的組件比方單元測試可運行程序來加速開發人員的瀏覽器構建過程。
降低最大組件的連接時間。比如browser組件。單元測試程序更小了，這有利於大家用gdb調試代碼。或者通過printf高速便利代碼。
- 上面提到的方法應該能夠降低大家的擔憂、也讓google團隊更easy合作，使得架構更不easy誤解，同一時候不easy寫出不好的架構來，通常也會使我們更高效。
設計
概覽
1 把src/chrome文件夾提取出一個個的組件。這些組件變成了一個個的目標，他們有自己獨立的單元測試目標，明白指定他們的依賴。沒有循環依賴。
2 沒有循環依賴
指的是組件並不認識自己的使用者（embedder）--嵌入組件的模塊比如src/chrome。假設組件須要獲得自己使用者的信息和服務，他們能夠在初始化的時候獲得。或者執行時通過抽象的client接口獲得。這個client接口由組件定義、使用者(embedder)來實現。
3 組件在哪裏？
在src/components/的子文件夾裏。
- 註意: 一些模塊更像一個抽象層--比方src/content、或者更像一個產品--比方src/chrome，這些模塊應該有自己的頂級文件夾，而不應該放到src/components文件夾下。
4 Client接口在哪裏?
他們的聲明在每個組件裏，而實如今組件的使用者那裏。
A: 通常說來。例如以下使用方法是沒問題的：組件的使用者採用C++類的詳細類來使用組件。這樣的情況下，API是非常easy的，不管組建類是什麽--組件收到指針。實現來自使用者的托付接口。某些情況下，google引入了全然抽象的API給組件的使用者調用，這些API隱藏了組件的實現細節。就像他們給src/content組件做的一樣。
某些其它情況下，他們給組件的C++詳細類分分類，一部分分到內部類，一部分分到public類裏。不管是內部類還是外部類，他們都應該存在於組件文件夾下，比如：src/components/mycomponent/public/. 假設一個組件的public分類存在，組件的client接口應該存在那裏。
部分參考：http://www.chromium.org/developers/content-module本文屬原創，轉載請註明出處，違者必究
關註chromium群480089700。或者微信公眾平臺:程序猿互動聯盟(coder_online)，你能夠第一時間獲取原創技術文章，和（java/C/C++/Android/Windows/Linux）技術大牛做朋友。在線交流編程經驗。獲取編程基礎知識，解決編程問題。程序猿互動聯盟，開發者自己的家。
Chromium瀏覽器組件設計意圖