值得你學習的 Android 開發規範(上)

標籤：資源   ide   建立   feautre   uga   data   3.5   strong   實現   

• 前言

• AS規範

• 命名規範

• 資源檔規範

• 版本統一規範

• 第三方庫規範

• 注釋規範

• 其他的一些規範

   

1

前言

為了利於項目維護以及規範開發，促進成員之間Code Review的效率，故提出以下開發規範，如有更好建議，歡迎到GitHub提issue。

GitHub：https://github.com/Blankj/AndroidStandardDevelop

 

2

AS規範

工欲善其事，必先利其器。

1. 盡量使用最新版的IDE進行開發；

2. 編碼格式統一為UTF-8；

3. 編輯完.java、 .xml等檔案後一定要格式化（基本格式方面使用 AS 預設範本即可）；

4. 刪除多餘的import，減少警告出現，可利用AS的Optimize Imports(Settings → Keymap → Optimize Imports)快速鍵；

5. AS常用開發外掛程式可以參考這裡～《AS常用開發外掛程式》（https://github.com/Blankj/AndroidStandardDevelop）

 

 

 

 

3

命名規範

代碼中的命名嚴禁使用拼音與英文混合的方式,更不允許直接使用中文的方式。正確的英文拼字和文法可以讓閱讀者易於理解,避免歧義。

注意：即使純拼音命名方式也要避免採用。但alibaba、taobao、youku、hangzhou等國際通用的名稱,可視同英文。

 

3.1 包名

包名全部小寫，連續的單詞只是簡單地串連起來，不使用底線，採用反網域名稱命名規則，全部使用小寫字母。一級包名是頂級網域名稱，通常為com,edu,gov,net,org等，二級包名為公司名，三級包名根據應用進行命名，後面就是對包名的劃分了，關於包名的劃分，推薦使用按功能分，一開始我們也是按照層去分包的，很坑爹。按照功能分可能你不是很好區分在哪個功能中，不過也比你按照層區分要好找很多。具體可以參考這篇博文～Package by features, not layers，當然，我們大Google也有相應的sample～iosched，其結構如下所示，很值得學習。

參考Google I/O 2015的代碼結構，按功能分包具體可以這樣做：

PBF(按功能分包Package By Feature)與PBL(按層分包Package By Layer)相比較有如下優勢：

1.package內高內聚，package間低耦合

哪塊要添新功能，只改某一個package下的東西。

 

按class職能分層（PBL）降低了代碼耦合，但帶來了package耦合，要添新功能，需要改model、dbHelper、view、service等等，需要改動好幾個package下的代碼，改動的地方越多，越容易產生新問題，不是嗎？

 

按功能分包（PBF），featureA相關的所有東西都在featureA包，feature內高內聚高度模組化，不同feature之間低耦合，相關的東西都放在一起，還好找。

 

2.package有私人範圍（package-private scope）

你負責開發這塊功能，這個目錄下所有東西都是你的。

 

PBL的方式是把所有工具方法都放在util包下，小張開發新功能時候發現需要一個xxUtil，但它又不是通用的，那應該放在哪裡？沒辦法，按照分層原則，我們還得放在util包下，好像不太合適，但放在其它包更不合適，功能越來越多，util類也越定義越多。後來小李負責開發一塊功能時發現需要一個xxUtil，同樣不通用，去util包一看，怎麼已經有了，而且還沒法複用，只好放棄xx這個名字，改為xxxUtil……因為PBL的package沒有私人範圍，每一個包都是public（跨包方法調用是很平常的事情，每一個包對其它包來說都是可訪問的）

 

如果是PBF，小張的xxUtil自然放在feautreA下，小李的xxUtil在featureB下，如果覺得util好像是通用的，就去util包看看要不要把工具方法添進xxUtil，class命名衝突沒有了

PBF的package有私人範圍，featureA不應該訪問featureB下的任何東西（如果非訪問不可，那就說明介面定義有問題）

 

3.很容易刪除功能

統計發現新功能沒人用，這個版本那塊功能得去掉。

 

如果是PBL，得從功能入口到整個商務程序把受到牽連的所有能刪的代碼和class都揪出來刪掉，一不小心就完蛋。

 

如果是PBF，好說，先刪掉對應包，再刪掉功能入口（刪掉包後入口肯定報錯了），完事。

 

4.高度抽象

解決問題的一般方法是從抽象到具體，PBF包名是對功能模組的抽象，包內的class是實現細節，符合從抽象到具體，而PBL弄反了。

 

PBF從確定AppName開始，根據功能模組劃分package，再考慮每塊的具體實現細節，而PBL從一開始就要考慮要不要dao層，要不要com層等等。

 

5.只通過class來分離邏輯代碼

PBL既分離class又分離package，而PBF只通過class來分離邏輯代碼。

 

沒有必要通過package分離，因為PBL中也可能出現尷尬的情況：

按照PBL，service包下的所有東西都是Controller，應該不需要Serv尾碼，但實際上通常為了碼起來方便，直接import service包，Serv尾碼是為了避免引入的class和當前包下的class命名衝突，當然，不用尾碼也可以，得寫清楚包路徑，比如new net.ayqy.service.Main()，麻煩。

 

而PBF就很方便，無需import，直接new MainServ()即可。

 

6.package的大小有意義了

PBL中包的大小無限增長是合理的，因為功能越添越多。

 

而PBF中包太大（包裡class太多）表示這塊需要重構（劃分子包）。

 

3.2 類名

類名都以UpperCamelCase風格編寫。

 

類名通常是名詞或名詞短語，介面名稱有時可能是形容詞或形容詞短語。現在還沒有特定的規則或行之有效約定來命名註解類型。

 

名詞，採用大駝峰命名法，盡量避免縮寫，除非該縮寫是眾所周知的， 比如HTML, URL，如果類名稱中包含單詞縮寫，則單詞縮寫的每個字母均應大寫。

測試類別的命名以它要測試的類的名稱開始，以Test結束。例如：HashTest或HashIntegrationTest。

 

介面（interface）：命名規則與類一樣採用大駝峰命名法，多以able或ible結尾，如
interface Runnable、interface Accessible。

 

注意：如果項目採用MVP，所有Model、View、Presenter的介面都以I為首碼，不加尾碼，其他的介面採用上述命名規則。

 

3.3 方法名

方法名都以lowerCamelCase風格編寫。

方法名通常是動詞或動詞短語。

3.4 常量名

常量名命名模式為CONSTANT_CASE，全部字母大寫，用底線分隔單詞。那，到底什麼算是一個常量？

 

每個常量都是一個靜態final欄位，但不是所有靜態final欄位都是常量。在決定一個欄位是否是一個常量時，考慮它是否真的感覺像是一個常量。例如，如果任何一個該執行個體的觀測狀態是可變的，則它幾乎肯定不會是一個常量。只是永遠不打算改變對象一般是不夠的，它要真的一直不變才能將它示為常量。

3.5 非常量欄位名

非常量欄位名以lowerCamelCase風格的基礎上改造為如下風格：基本結構為scopeVariableNameType。

 

scope：範圍

非公有，非靜態欄位命名以m開頭。

靜態欄位命名以s開頭。

公有非靜態欄位命名以p開頭。

公有靜態欄位（全域變數）命名以g開頭。

例子：

使用1字元首碼來表示作用範圍，1個字元的首碼必須小寫，首碼後面是由表意性強的一個單詞或多個單片語成的名字，而且每個單詞的首寫字母大寫，其它字母小寫，這樣保證了對變數名能夠進行正確的斷句。

 

Type：類型

考慮到Android中使用很多UI控制項，為避免控制項和普通成員變數混淆以及更好達意，所有用來表示控制項的成員變數統一加上控制項縮寫作為尾碼（文末附有縮寫表）。

 

對於普通變數一般不添加類型尾碼，如果統一添加類型尾碼，請參考文末的縮寫表。

 

用統一的量詞通過在結尾處放置一個量詞，就可建立更加統一的變數，它們更容易理解，也更容易搜尋。

 

注意：如果項目中使用ButterKnife，則不添加m首碼，以lowerCamelCase風格命名。

 

例如，請使用mCustomerStrFirst和mCustomerStrLast，而不要使用mFirstCustomerStr和mLastCustomerStr。

說明：

集合添加如下尾碼：List、Map、Set
數組添加如下尾碼：Arr

 

注意：所有的VO（值對象）統一採用標準的lowerCamelCase風格編寫，所有的DTO（資料轉送對象）就按照介面文檔中定義的欄位名編寫。

 

3.6 參數名

參數名以lowerCamelCase風格編寫。

參數應該避免用單個字元命名。

 

3.7 局部變數名

局部變數名以lowerCamelCase風格編寫，比起其它類型的名稱，局部變數名可以有更為寬鬆的縮寫。

 

雖然縮寫更寬鬆，但還是要避免用單字元進行命名，除了臨時變數和迴圈變數。

 

即使局部變數是final和不可改變的，也不應該把它示為常量，自然也不能用常量的規則去命名它。

 

3.8 臨時變數

臨時變數通常被取名為i、j、k、m和n，它們一般用於整型；c、d、e，它們一般用於字元型。 如：for (int i = 0; i < len ; i++)。

 

3.9 類型變數名

類型變數可用以下兩種風格之一進行命名：

• 單個的大寫字母，後面可以跟一個數字(如：E, T, X, T2)。

• 以類命名方式(參考3.2 類名)，後面加個大寫的T(如：RequestT, FooBarT)。

值得你學習的 Android 開發規範(上)