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 寫在最後：

碼字不易看到最後了，那就點個關注唄，只收藏不點關注的都是在耍流氓！

關注並私信我「架構」，免費送一些Java架構資料，先到先得！