Android模塊化設計之組件開發規范

最近一直在做基礎建設方面的作業，面對這三十多個完全沒有規范可言的組件，氣的我直接打了一套閃電五連鞭，但打工還得繼續，于是想對這些組件建立一套規范，來降低夠用、使用、維護以及扯皮成本，本想在網上白嫖一套，可找到的都是一些基礎的代碼規范，用處不大，于是乎根據自己的作業經驗，總結出一套規范/約定出來，希望能拋磚引玉，各位大佬多多指點和補充~

規范本身就是開發人員之間的約定，沒有最權威的，只有最適合的，

版本規范

為保證組件在各個專案中的兼容性問題，約定組件開發版本如下：

• AndroidSdk版本
• minSdkVersion：21
• targetSdkVersion：28
• 語言環境
• 開發語言：Kotlin
• Kotlin版本：1.4.x
• JDK版本：1.8
• 其他建議版本
• AndroidStuido：4.2
• gradle tools：4.1.x
• gradle：6.7.x

組件命名規范

根據組件的功能不同，約定組件分為三個型別：

• 基礎組件

為專案提供與業務無關基礎支持的組件庫，如提供MVVM架構的lib_basic，提供依賴注入的lib_basic_koin，這類組件統一命名方式為lib_basic_xxx，這些基礎組件也可以被工具組件和業務組件依賴，而不僅僅是只被專案依賴，

• 工具組件

對專案中常用的業務無關功能封裝的組件庫，如Dialog彈窗，相冊選擇等，這類組件統一命名方式為lib_util_xxx，

• 業務組件

在某個專案的需求中出現的在其他專案中可能也會用到的功能的封裝，比如A業務員版中掃描拍照在A商業版中也有用到，于是單獨封裝為一個業務組件進行管理，這類組件統一命名方式為lib_tool_xxx，

• GroupId

所有組件統一GroupId為com.company.android，方便在Maven倉庫中進行索引和管理，

• 版本號

對于迭代的版本號，不做強制性的要求，只需合理進行升級即可，但以下情況需特殊注意：

1、對于上傳的開發版本，需要在版本中進行體現，如1.1.0-dev02，與正式版本做區分，在專案中驗證無風險后，合并到主迭代版本中，

2、對于緊急修復A專案中的問題而臨時發版的，需要在版本中進行體現，如1.1.0-hotfix-A，此次修改在其他使用的專案中驗證無風險后，合并到主迭代版本中，

開發原則

• 開閉原則

在組件升級時，應對新增開放，對修改關閉，即做加法不做減法，目的是為了保證對專案中呼叫老版本API的兼容問題，對于不再建議使用的API，應使用 @Deprecated注解進行標注，并新增建議使用的API進行代替，而不是直接洗掉舊API，在完成多個穩定版本的迭代之后，可以所有組件使用者討論洗掉舊版API的事宜，

• 向下兼容原則

所有組件的版本迭代必須向下兼容，即1.2.0版本須兼容1.1.0，在使用者升級版本之后，無需修改業務層代碼，

如果因組件前期設計不合理導致升級必須修改業務代碼時，組件開發者需要與所有組件使用者商討技術實作方案，看能否以最小的改動完成組件的升級，并在組件功能開發完畢后，以書面形式告知使用者并提供完整的升級檔案，

• 三方隔離原則

我們在封裝組件的時候，難免會使用到第三方依賴，為了避免更換三方依賴或依賴升級造成的影響，需要對三方依賴庫進行二次封裝，避免直接使用，比如我們要使用glide框架加載圖片，可以創建一個代理類對glide的功能進行代理，在業務代碼中使用代理類進行操作而不是直接呼叫glide，這樣我們將來替換glide框架時，能最小的改動業務代碼，

當然，并不是所有的三方庫都通過代理模式進行隔離，比如retrofit、RxJava等，畢竟我們的隔離原則是為了以后更簡單的迭代而不是自尋煩惱，

• 最少依賴原則

為了減少專案中依賴的類別庫，在組件封裝中遇到如下情況，應對組件進行拆分作業：

現封裝一圖片加載類別庫lib_util_imageloader，對Glide和Picasso進行了二次封裝，由于兩個類別庫提供了類似的功能，在專案中只需要使用一套就能滿足業務需求，沒有必要把兩個圖片加載框架都進行依賴，所以應該對lib_util_imageloader進行拆分為如下結構：

lib_util_imageloader_core：圖片加載核心庫，把加載圖片的方法抽象為介面，面向專案，不做具體的實作，

lib_util_imageloader_glide：對glide進行二次封裝，實作core中的介面，

lib_util_imageloader_picasso：對picasso進行二次封裝，實作core中的介面，

在專案使用圖片加載庫時，除了必須要依賴的core外，只需要從glide和picasso中挑選一個即可，這樣就不會把用不到的類別庫也打包到專案中去了，

這樣的做法還有一個好處，就是容易拓展，如果我想要使用Fresco,只需要再新增一個lib_util_imageloader_fresco，并實作core的介面即可，在切換組件時，只需要改變gradle檔案中的依賴，無需變更業務代碼，因為業務代碼都是基于core組件的，

• 最少可見原則

組件應該盡可能少的對外暴露類、介面、方法等，可以通過外觀模式對使用者統一提供API，降低使用者的理解難度，

• 支持開發模式

組件需要預留開發者模式，可以讓使用者自行選擇開啟關閉，

打開開發者模式：組件運行的關鍵節點需進行日志輸出，方便使用者進行除錯，可以在運行時拋出例外，

關閉開發者模式：組件不再對外輸出Error級別以下的日志，禁止在運行時拋出例外、ANR，如發生例外需要在組件內捕獲并通過錯誤回呼或列印Error級別日志等方式告知使用者，

• 可拓展性

部分組件（視具體情況而定，多數為對三方類別庫的封裝組件）應該有一定的拓展性，應支持使用者自定義實作覆寫默認實作，

比如Dialog類別庫有默認彈窗樣式，需要支持使用者自定義彈窗樣式而不是只能在默認樣式中進行選擇，圖片加載框架也是相同的邏輯，

開發規范

• 包名規范

為了避免無意中導致的包名沖突問題，約定組件的包名為4級，除去前兩級的com.company為固定寫法以外，后兩級可根據具體的組件功能進行命名，并要求有良好的可讀性，

• 資源規范

組件中定義資源檔案時，要以組件名稱為前綴，避免資源沖突導致的打包問題，需要在gradle檔案的android節點下新增如下代碼強制進行資源名稱前綴檢查：

android{
  resourcePrefix = "${your_component_name}_"
}

• 代碼規范

應當遵循Java開發代碼規范，這里不再贅述，

• 可見域規范

Kotlin中新增關鍵字internal，可用于修飾類名、方法名和成員變數名，限制所修飾的物件模塊內可見，對于無需對外暴露的類、方法和變數，應當降低其可見域，

• 行內函式

Kotlin中新增關鍵字inline修飾方法，可以減少方法堆疊的進堆疊方法數，在封裝組件時善用inline以提高組件的運行效率，

• 記憶體泄漏

所有組件在發布之間，必須進行記憶體泄漏檢測，禁止存在記憶體泄漏的組件上線，應在開發階段修復所有泄漏問題，

• 混淆

組件開發者需要確認自己的組件在打包混淆后是否可以正常作業，如有用到運行時注解、反射、Json轉換等功能，需要在接入檔案中宣告避免混淆的規則，

• 檔案

組件的接入、使用、升級和注意事項等需要在開發檔案中有明確的體現，沒有接入檔案或者檔案不完善一律不許通過驗收，

• Demo

組件最好有配套的演示工程，用來最直觀的體現出組件所提供的功能，也方便使用者進行參考，

最后

目前只能想起這么多，以后有新增的會繼續補充，

規范好定制，落實起來卻難，路漫漫其修遠兮，加油吧，打工人！

復習筆記

這份資料我從春招開始，就會將各博客、論壇，網站上等優質的Android開發中高級面試題收集起來，然后全網尋找最優的解答方案，每一道面試題都是百分百的大廠面經真題+最優解答，包知識脈絡 + 諸多細節，

節省大家在網上搜索資料的時間來學習，也可以分享給身邊好友一起學習，

領取方式：需要在評論區評論：“免費領”即可

Android學習+面試+視頻資料https://jq.qq.com/?_wv=1027&k=hmKIdv2Y