Android开发架构规范
前言
在開發中，一個良好的開發習慣以及一個開發規范可能會讓你少走很多彎路，也會一定程度上的提高代碼的可讀性，可維護性和可拓展性。當隨著需求的不斷變更，需要維護項目的時候。當隨著項目的代碼量的提升，需要重構的時候。你會明白一個好的開發規范多么多么的重要。
這里整理一下自己android開發中的一些規范。希望對各位有幫助。
命名規范
包命名規范
- 包名全部采用小寫
- 主包名采用[公司性質].[公司名稱].[項目名稱]的命名方式
如果根據不同情況進行分包的話，可以將包名分別命名為util，view， adapter等。
代碼命名規范
命名規則有很多高大上的名詞，比如大駝峰，小駝峰，匈牙利命名法。其實最簡單的就是按照谷歌命名學習。
- 常量、枚舉等均采用大寫形式，用下劃線區分各單詞。使用static final
例如：private static final String TAG_FOR_ACTIVITY = "XXXX"; - 類名、接口名、枚舉名。第一個和后面的單詞都要第一個字母大寫
例如：MainActivity,PersonalLoginActivity - 資源文件命名
例如：activity_main.xml，ic_launcher.png
注意圖片文件命名只能用小寫字母、數字，否則會導致R文件無法編譯出來。也是比較費心的。 - 繼承自安卓組件的類，一般采用父類名作為后綴，
例如：class LoginActivity extends Activity{} - 自定義異常必須以Exception結尾
- 全局變量添加所有者前綴：實例成員變量前綴m（表示member），類靜態變量前綴s（表示static），
例如：protected Subscription mSubscription; - 控件變量添加組件前綴，順序在所有者前綴之后，控件縮寫button->btn,textview ->txw,listview->lst等
例如：全局名稱mBtnNext局部名稱btnNext - 構造方法采用遞增方式（參數多的寫在后面），參數少的調用參數多的構造函數。這樣也減少初始化代碼。比如開源庫PagerSlidingTabStrip
更多命名規范
之前收藏的這篇文章比較全。Android 命名規范 （提高代碼可以讀性）
編程規范
- 源文件編碼格式為 UTF-8。
- java代碼中不出現中文，最多注釋中可以出現中文
- 服務端可以實現的，就不要放在客戶端
- 引用第三方庫要慎重，避免應用大容量的第三方庫，導致客戶端包非常大
- 處理應用全局異常和錯誤，將錯誤以郵件的形式發送給服務端
- 圖片的.9處理
- 使用靜態變量方式實現界面間共享要慎重
- 單元測試（邏輯測試、界面測試）
- 不要重用父類的handler，對應一個類的handler也不應該讓其子類用到，否則會導致message.what沖突
- activity中在一個View.OnClickListener中處理所有的邏輯
- strings.xml中使用%1$s實現字符串的通配
- 數據一定要效驗，例如字符型轉數字型，如果轉換失敗一定要有缺省值；服務端響應數據是否有效判斷
- 對于未完成的方法，使用TODO加以標記
- 若功能已完成，但存在效率等潛在問題時，使用XXX加以標記
- 若代碼存在嚴重問題或僅用于調試，使用FIXME加以標記
- values目錄下文件名稱較固定，不得隨意更改
代碼提交規范
我們使用的無論是git，還是svn都需要遵守下面這些規范，個人比較傾向于git。
- 工作目錄要及時更新，不要和服務器有太大的差別
- 提交代碼時，如果出現沖突，必須仔細分析解決，不可以強行提交
- 提交代碼之前先在本地進行測試，確保項目能編譯通過，且能夠正常運行，不可盲目提交
- 必須保證服務器上的版本是正確的，項目有錯誤時，不要進行提交
- 提交之前先更新
- 提交時注意不要提交本地自動生成的文件，比如我們Android Studio項目中的?idea,build文件夾是不需要提交的。
- 不要提交自己不明白的代碼
- 提前協調好項目組成員的工作計劃，減少沖突
- 對提交的信息采用明晰的標注（寫注釋）
使用git以及github，相信stormzhang的從0開始學習 GitHub 系列會對你有很大的幫助。
架構規范
這是我整個系列文章從零開始搭建android框架系列的重點，所以這里放在最后面。
架構方式
是選擇MVP，MVC，MVVM ，Flux還是clean 架構？
，+dagger2？+rxjava？+Retrofit/okhtttp?+loader？+databinding？+contentProvider?
谷歌官方架構示例android-architecture，以及我之前github中整理的架構合集能給你答案。
開源庫的選取以及封裝。
對開源庫的選取，一般都需要選擇比較穩定的版本，還有作者在維護的項目
，比如這里在github搜索image，出現的安卓中的圖片加載庫。除了考慮star，還要考慮作者對issue的解決，以及開發者的知名度等各方面。
選取之后，一定的封裝是必要的。
網絡圖片加載的封裝這篇文章可能會從圖片加載封裝的角度給你講講封裝的必要性。
架構提示
這里盡量寫出自己想到的點。
抽象層面上：
- 提高架構的拓展性是有必要的。
以前的框架可能會出現功能不足的情況，但是因為這點是不可預見的，所以我們選擇框架時一定要了解好框架本身的擴展性如何，或者對框架有較深的理解，能夠自己擴展框架， - 提高架構的穩定性
- 架構的文檔也是必不可少的。
具體操作時：
-
activity和fragment里面都會有許多重復的操作以及操作步驟，所以我們都需要提供一個BaseActivity和BaseFragment，讓所有的activity和fragment都繼承這個基類。
來看看我們BaseActivity中都提供了哪些操作：
-
必要的注釋真的會一定程度上的降低你的工作量，而不是提高。
比如說我使用Rxjava做加載數據的操作。這里面的流程可能稍顯復雜，但是能夠step1， step2的寫在上面，能夠讓別人看懂，自己維護也方便。
-
數據提供統一的入口。
無論是在mvp，mvc，還是mvvm中，提供一個統一的數據入口，都可以讓代碼變得更加易于維護。
比如，我使用的DataManager，里面的http還是preference，還是eventpost ，還是database ，都在DataManger里面進行操作，我們只需要與DataManger打交道。
-
多用組合, 少用繼承
-
提取方法, 去除重復代碼。
比如在我的架構中，我會吧imageloader單獨的抽取出來作為一個widget，把對RecyclerView的封裝單獨抽取出來，把下拉刷新上拉加載抽取出來。如下圖：
對于必要的工具類抽取也很重要，這在以后的項目中是可以重用的。
-
不要使用魔鬼數字/字符串/尺寸值/顏色值，正確的命名等
比如日間模式和夜間模式的對應顏色值，一看就很清晰了。
-
引入Dagger2 減少模塊之間的耦合性
Dagger2 是一個依賴注入框架，使用代碼自動生成創建依賴關系需要的代碼。減少很多模板化的代碼，更易于測試，降低耦合，創建可復用可互換的模塊。
參考之前的文章?Google官方MVP+Dagger2架構詳解 -
為你的項目引入Rxjava+RxAndroid這些響應式編程吧。極大的減少邏輯代碼，讓你愛上寫代碼停不下來。
-
通過引入?Event Bus（事件總線，這個項目使用的是otto）。它允許我們在Data Layer中發送事件，以便View Layer中的多個組件都能夠訂閱到這些事件。比如DataManager
中的退出登錄方法可以發送一個事件，訂閱這個事件的多個Activity在接收到該事件后就能夠更改它們的UI視圖，從而顯示一個登出狀態。
當然你也可以有很多的選擇，EventBus，Otto，自定義RxBus等。減少回調。 -
添加日志打印，用于查找錯誤等。
logger?以及timber是我推薦的。
需要使用BuildConfig.DEBUG標記對Log進行封裝，只在調試時輸出重要信息，正式版不輸出 -
TODO more
參考文章
Android進階之路——安卓編程規范
Google官方MVP+Dagger2架構詳解
網絡圖片加載的封裝
Good-Android-development-habits
Android Project Guidelines
原文： http://www.jianshu.com/p/99239b9c1630
總結
以上是生活随笔為你收集整理的Android开发架构规范的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【进阶】从linux到android，进
- 下一篇： Android系统中的进程管理：进程的优