從2008年9月23日發布 Android 1.0開始到現在的 Android 12，它已經歷十三個年頭，在這程序中經歷了層層的升級改變……
隨著 Android 版本的不斷更新升級和用戶對 APP 產品需求技術越來越高，相對的各大公司對 Android 開發者們設定的招聘門檻也越來越高，
至于如何去看一個開發者水平的高低，一般看面試官會怎么問，會問那些部分的技術內容？
一般公司對于一些剛入行的新手要求不會太高，但基本要懂得的技識訓要懂的，不會太深入的去問，
而對于在 Android 開發行業有三五年經驗的人，就不會這么簡單的問了，會根據他們做過和設計到的一些專案進行詢問，
因為在這個行業有太多掛著3-5年作業經驗的“新手”，如果不深入的問，就很容易讓他們拿著高工的薪資，且沒有得到應該有的技術支持，
他們一般是如何開發的呢？
專案架構毫無章法，毫無設計模式，不追求極致的性能體驗，總計就是東西做出來就行
想要評判技術水平的高低，可以用代碼的好與壞來進行衡量，但在開發眼里，寫好專案碼第一步就是需要選擇好的架構設計，
在 Android 開發行業中比較受歡迎的架構模式那肯定是組件化開發了，為啥？
- 對于初級進階中高級的開發者來說，組件化是必備的，
- 對應大廠的專案中，組件化也是必備的，
- 對應大型專案中維護角度來說，組件化仍是必備的，
- 對應團隊開發來說，組件化還是必備的，
- 對應提升開發效率來說，組件化依然是必備的，
為什么要選組件化開發？
首先說優勢：
Android APP組件化架構的目標是：告別結構臃腫，讓哥哥業務變得相對獨立，業務組件在組件模式下可以獨立開發，而在集成模式下又可以變成“app殼工程”中，組成一個完整功能的APP；
從組件化工程模型中可以看到，業務組件之間是獨立的，沒有關聯的，這些業務組件在集成模式下是一個個library，被app殼工程所依賴，組成一個具有完整業務功能的APP應用，但是在組件開發模式下，業務組件又變成了一個個application，它們可以獨立開發和除錯，由于在組件開發模式下，業務組件們的代碼量相比于完整的專案差了很遠，因此在運行時可以顯著減少編譯時間，
組件化專案架構詳解
-
集成模式: 所有的業務組件被“app殼工程”依賴，組成一個完整的APP；
-
組件模式: 可以獨立開發業務組件，每一個業務組件就是一個APP；
-
app殼工程: 負責管理各個業務組件，和打包apk，沒有具體的業務功能；
-
業務組件: 根據公司具體業務而獨立形成一個個的工程；
-
Main組件:屬于業務組件，指定APP啟動頁面、主界面 ；
-
Common組件: 也就是功能組件(component_base 模塊)，支撐業務組件的基礎，提供多數業務組件需要的功能，例如提供網路請求功能；
-
component_data組件: 存放與專案相關的公共資料,例如bean的基類,IntentKV存資料的鍵值對等.
-
SDK組件: 集成微信,支付寶支付,分享,推送等常用的第三方框架.
專案中實踐
當你用組件化開發接觸到大型專案時，你就會發現組件化開發的優點，如果你沒有用組件開發進行時，你會發現一下問題：
- 編譯時間長，每次改一個引數都需要編譯整個專案
- 專案耦合太嚴重，每次復用一個功能都要Copy很多的關聯類
- 團隊開發不方便，不能很好的分工合作
根據上面的問題，你會發現組件化已成為每個Android開發必須掌握的一項技能，它能夠讓大家開發專案變得更方便，讓大家的功能復用變得簡單(因為在組件化專案中，每個功能彼此之間是沒有關聯的）：
從上圖中我們會發現，在組件化架構的專案中，我們的每個業務邏輯模塊從傳統的用包名來劃分升級到了用模塊來劃分，這樣的好處在于，當在新專案中要用到一個之前專案的某一個功能的時候，如果兩個專案都是組件化架構，那我直接復制過來就可以使用，不需要解耦合，
而且大家會發現，每個模塊都是可以獨立運行的Application，這樣設計優勢在于每個模塊都能夠獨立的測驗，能夠提高我們的編譯速度，再站在團隊開發的角度來說，每個小專案組負責一個模塊的功能，互不干擾，何樂而不為呢？
為了方便大家能夠更好的掌握組件化開發，小編自行整理了一些 Android組件相關學習檔案和Android 開發其他相關的學習檔案、面試題、Android 核心筆記等等檔案，希望能幫助到大家學習提升，如有需要參考的可以直接去我 CodeChina地址：https://codechina.csdn.net/u012165769/Android-T3 訪問查閱，
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/291076.html
標籤：其他