前言

在開發中，一個良好的開發習慣以及一個開發規范可能會讓你少走很多彎路，也會一定程度上的提高代碼的可讀性，可維護性和可拓展性。當隨著需求的不斷變更，需要維護項目的時候。當隨著項目的代碼量的提升，需要重構的時候。你會明白一個好的開發規范多麼多麼的重要。
這裡整理一下自己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

---

編程規范

源文件編碼格式為 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 系列會對你有很大的幫助。

---

架構規范

架構方式

是選擇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都繼承這個基類。

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 是一個依賴注入框架，使用代碼自動生成創建依賴關系需要的代碼。減少很多模板化的代碼，更易於測試，降低耦合，創建可復用可互換的模塊。

為你的項目引入Rxjava+RxAndroid這些響應式編程吧。極大的減少邏輯代碼，讓你愛上寫代碼停不下來。

通過引入**Event Bus（事件總線，這個項目使用的是otto）。它允許我們在**Data Layer中發送事件，以便View Layer中的多個組件都能夠訂閱到這些事件。比如DataManager
中的退出登錄方法可以發送一個事件，訂閱這個事件的多個Activity在接收到該事件後就能夠更改它們的UI視圖，從而顯示一個登出狀態。
當然你也可以有很多的選擇，EventBus，Otto，自定義RxBus等。減少回調。

添加日志打印，用於查找錯誤等。
需要使用BuildConfig.DEBUG標記對Log進行封裝，只在調試時輸出重要信息，正式版不輸出