安卓開發規範

摘要

1 前言

爲了利於項目維護以及規範開發，促進成員之間Code Review的效率，故提出以下開發規範，如有更好建議，請務必及時反饋！方便他人，提高自己

數據傳遞建議(可根據需要忽略)

Activity界面件傳遞複雜數據需要用到對象，針對複雜數據直接使用json，採用類似EventBus的做法，數據類型按照項目接口規範走即可(一套接口規範搞定多處數據問題)，以便維護

2 AS規範

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

儘量使用最新版(穩定版)的IDE進行開發；
編碼格式統一爲UTF-8；
編輯完.java、 .xml等文件後一定要格式化（基本格式方面使用 AS 默認模板即可）；
刪除多餘的import，減少警告出現，可利用AS的Optimize Imports(Settings → Keymap → Optimize Imports)快捷鍵；
Android開發者工具可以參考這裏～[Android開發者工具][Android開發者工具]

3 命名規範

代碼中的命名嚴禁使用拼音與英文混合的方式,更不允許直接使用中文的方式。正確的英文拼寫和語法可以讓閱讀者易於理解,避免歧義。
Ps.核心要點：通俗易懂

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

3.1 包名

包名全部小寫，連續的單詞只是簡單地連接起來，不使用下劃線，採用反域名命名規則，全部使用小寫字母。一級包名是頂級域名，通常爲com,edu,gov,net,org等，二級包名爲公司名，三級包名根據應用進行命名，後面就是對包名的劃分了，關於包名的劃分，推薦使用按功能分，
* 分模塊分組件進行分包，保證結構清晰，可共用資源放入configLibrary模塊中

3.2 類名

類名都以UpperCamelCase風格編寫。

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

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

類	描述	例如
Activity 類	Activity爲後綴標識	歡迎頁面類WelcomeActivity
Adapter類	Adapter 爲後綴標識	新聞詳情適配器 NewDetailAdapter
解析類	Parser爲後綴標識	首頁解析類HomePosterParser
工具方法類	Utils或Manager爲後綴標識（與系統或第三方的Utils區分）或功能+Utils	線程池管理類：ThreadPoolManager日誌工具類：LogUtils（Logger也可）打印工具類：PrinterUtils
數據庫類	以DBHelper後綴標識	新聞數據庫：NewDBHelper
Service類	以Service爲後綴標識	時間服務TimeService
BroadcastReceiver類	以Receiver爲後綴標識	推送接收JPushReceiver
ContentProvider類	以Provider爲後綴標識	ShareProvider
自定義的共享基礎類	以Base開頭	BaseActivity,BaseFragment

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

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

注意：如果項目採用MVP，所有Model、View、Presenter的接口都以I爲前綴，不加後綴，其他的接口採用上述命名規則。

3.3 方法名

方法名都以lowerCamelCase風格編寫。

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

方法	說明
initXX()	初始化相關方法,使用init爲前綴標識，如初始化佈局initView()
isXX() checkXX()	方法返回值爲boolean型的請使用is或check爲前綴標識
getXX()	返回某個值的方法，使用get爲前綴標識
setXX()	設置某個屬性值
handleXX()/processXX()	對數據進行處理的方法
displayXX()/showXX()	彈出提示框和提示信息，使用display/show爲前綴標識
updateXX()	更新數據
saveXX()	保存數據
resetXX()	重置數據
clearXX()	清除數據
removeXX()	移除數據或者視圖等，如removeView();
drawXX()	繪製數據或效果相關的，使用draw前綴標識

3.4 常量名

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

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

// Constants
static final int NUMBER = 5;
static final ImmutableListNAMES = ImmutableList.of("Ed", "Ann");
static final Joiner COMMA_JOINER = Joiner.on(','); // because Joiner is immutable
static final SomeMutableType[] EMPTY_ARRAY = {};
enum SomeEnum { ENUM_CONSTANT }

// Not constants
static String nonFinal = "non-final";
final String nonStatic = "non-static";
static final SetmutableCollection = new HashSet();
static final ImmutableSetmutableElements = ImmutableSet.of(mutable);
static final Logger logger = Logger.getLogger(MyClass.getName());
static final String[] nonEmptyArray = {"these", "can", "change"};

3.5 非常量字段名

非常量字段名以lowerCamelCase風格的基礎上改造爲如下風格：基本結構爲scopeVariableNameType。

scope：範圍

非公有，非靜態字段命名以m開頭。

靜態字段命名以s開頭。

公有非靜態字段命名以p開頭。

公有靜態字段（全局變量）命名以g開頭。

例子：

public class MyClass {
      int mPackagePrivate;  
      private int mPrivate;  
      protected int mProtected;
      private static MyClass sSingleton;  
      public int pField;
      public static int gField;
}

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

Type：類型

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

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

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

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

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

量詞列表	量詞後綴說明
First	一組變量中的第一個
Last	一組變量中的最後一個
Next	一組變量中的下一個變量
Prev	一組變量中的上一個
Cur	一組變量中的當前變量

說明：

集合添加如下後綴：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)。

更多還可參考～阿里巴巴Java開發手冊

4 資源文件規範

4.1 資源佈局文件（XML文件（layout佈局文件））

全部小寫，採用下劃線命名法

4.1.1 contentView命名

必須以全部單詞小寫，單詞間以下劃線分割，使用名詞或名詞詞組。

所有Activity或Fragment的contentView必須與其類名對應，對應規則爲：將所有字母都轉爲小寫，將類型和功能調換（也就是後綴變前綴）。

例如：activity_main.xml

4.1.2 Dialog命名

規則：dialog_描述.xml

例如：dialog_hint.xml

4.1.3 PopupWindow命名

規則：ppw_描述.xml

例如：ppw_info.xml

4.1.4 列表項命名

規則：item_描述.xml

例如：item_city.xml

4.1.5 包含項命名

規則：模塊_(位置)描述.xml

例如：activity_main_head.xml、activity_main_bottom.xml

注意：通用的包含項命名採用：項目名稱縮寫_描述.xml

例如：xxxx_title.xml

4.2 資源文件（圖片drawable文件夾下）

全部小寫，採用下劃線命名法，加前綴區分

命名模式：可加後綴 _small 表示小圖， _big 表示大圖，邏輯名稱可由多個單詞加下劃線組成，採用以下規則：

用途_模塊名_邏輯名稱
用途_模塊名_顏色
用途_邏輯名稱
用途_顏色

說明：用途也指控件類型（具體見附錄UI控件縮寫表）

例如：

名稱	說明
btn_main_home.png	按鍵`用途_模塊名_邏輯名稱`
divider_maket_white.png	分割線`用途_模塊名_顏色`
ic_edit.png	圖標`用途_邏輯名稱`
bg_main.png	背景`用途_邏輯名稱`
btn_red.png	紅色按鍵`用途_顏色`
btn_red_big.png	紅色大按鍵`用途_顏色`
ic_head_small.png	小頭像`用途_邏輯名稱`
bg_input.png	輸入框背景`用途_邏輯名稱`
divider_white.png	白色分割線`用途_顏色`
bg_main_head	主模塊頭部背景圖片`用途_模塊名_邏輯名稱`
def_search_cell	默認搜索界面單元圖片`用途_模塊名_邏輯名稱`
ic_more_help	更多幫助圖標`用途_邏輯名稱`
divider_list_line	列表分割線`用途_邏輯名稱`
sel_search_ok	搜索界面確認選擇器`用途_模塊名_邏輯名稱`
shape_music_ring	音樂界面環形形狀`用途_模塊名_邏輯名稱`

如果有多種形態，如按鈕選擇器：sel_btn_xx.xml

名稱	說明
sel_btn_xx	按鈕圖片使用`btn_整體效果`（selector）
btn_xx_normal	按鈕圖片使用`btn_正常情況效果`
btn_xx_pressed	按鈕圖片使用`btn_點擊時候效果`
btn_xx_focused	`state_focused`聚焦效果
btn_xx_disabled	`state_enabled` (false)不可用效果
btn_xx_checked	`state_checked`選中效果
btn_xx_selected	`state_selected`選中效果
btn_xx_hovered	`state_hovered`懸停效果
btn_xx_checkable	`state_checkable`可選效果
btn_xx_activated	`state_activated`激活的
btn_xx_windowfocused	`state_window_focused`

注意：使用AndroidStudio的插件SelectorChapek可以快速生成selector，前提是命名要規範。

4.3 動畫文件（anim文件夾下）

全部小寫，採用下劃線命名法，加前綴區分。

具體動畫採用以下規則：模塊名_邏輯名稱。

例如：refresh_progress.xml、market_cart_add.xml、market_cart_remove.xml。

普通的tween動畫採用如下表格中的命名方式：動畫類型_方向

名稱	說明
fade_in	淡入
fade_out	淡出
push_down_in	從下方推入
push_down_out	從下方推出
push_left	推向左方
slide_in_from_top	從頭部滑動進入
zoom_enter	變形進入
slide_in	滑動進入
shrink_to_middle	中間縮小

4.4 values中name命名

4.4.1 colors.xml

colors.xml的name命名使用下劃線命名法，在你的colors.xml文件中應該只是映射顏色的名稱一個ARGB值，而沒有其它的。不要使用它爲不同的按鈕來定義ARGB值。

不要這樣做

  <resources>
      <color name="button_foreground">#FFFFFF</color>
      <color name="button_background">#2A91BD</color>
      <color name="comment_background_inactive">#5F5F5F</color>
      <color name="comment_background_active">#939393</color>
      <color name="comment_foreground">#FFFFFF</color>
      <color name="comment_foreground_important">#FF9D2F</color>
      ...
      <color name="comment_shadow">#323232</color>

使用這種格式，你會非常容易的開始重複定義ARGB值，這使如果需要改變基本色變的很複雜。同時，這些定義是跟一些環境關聯起來的，如button或者comment, 應該放到一個按鈕風格中，而不是在colors.xml文件中。

相反，這樣做

  <resources>

      <!-- grayscale -->
      <color name="white"     >#FFFFFF</color>
      <color name="gray_light">#DBDBDB</color>
      <color name="gray"      >#939393</color>
      <color name="gray_dark" >#5F5F5F</color>
      <color name="black"     >#323232</color>

      <!-- basic colors -->
      <color name="green">#27D34D</color>
      <color name="blue">#2A91BD</color>
      <color name="orange">#FF9D2F</color>
      <color name="red">#FF432F</color>

  </resources>

嚮應用設計者那裏要這個調色板，名稱不需要跟"green"、"blue"等等相同。"brand_primary"、"brand_secondary"、"brand_negative"這樣的名字也是完全可以接受的。像這樣規範的顏色很容易修改或重構，會使應用一共使用了多少種不同的顏色變得非常清晰。通常一個具有審美價值的UI來說，減少使用顏色的種類是非常重要的。

注意：如果某些顏色和主題有關，那就單獨寫一個colors_theme.xml。

4.4.2 dimens.xml

像對待colors.xml一樣對待dimens.xml文件與定義顏色調色板一樣，你同時也應該定義一個空隙間隔和字體大小的“調色板”。一個好的例子，如下所示：

<resources>

    <!-- font sizes -->
    <dimen name="font_22">22sp</dimen>
    <dimen name="font_18">18sp</dimen>
    <dimen name="font_15">15sp</dimen>
    <dimen name="font_12">12sp</dimen>

    <!-- typical spacing between two views -->
    <dimen name="spacing_40">40dp</dimen>
    <dimen name="spacing_24">24dp</dimen>
    <dimen name="spacing_14">14dp</dimen>
    <dimen name="spacing_10">10dp</dimen>
    <dimen name="spacing_4">4dp</dimen>

    <!-- typical sizes of views -->
    <dimen name="button_height_60">60dp</dimen>
    <dimen name="button_height_40">40dp</dimen>
    <dimen name="button_height_32">32dp</dimen>

</resources>

佈局時在寫margins和paddings時，你應該使用spacing_xx尺寸格式來佈局，而不是像對待string字符串一樣直接寫值，像這樣規範的尺寸很容易修改或重構，會使應用所有用到的尺寸一目瞭然。這樣寫會非常有感覺，會使組織和改變風格或佈局是非常容易。

4.4.3 strings.xml

strings的name命名使用下劃線命名法，採用以下規則：模塊名+邏輯名稱，這樣方便同一個界面的所有string都放到一起，方便查找。

名稱	說明
main_menu_about	主菜單按鍵文字
friend_title	好友模塊標題欄
friend_dialog_del	好友刪除提示
login_check_email	登錄驗證
dialog_title	彈出框標題
button_ok	確認鍵
loading	加載文字

4.4.4 styles.xml

style的name命名使用大駝峯命名法，幾乎每個項目都需要適當的使用style文件，因爲對於一個視圖來說有一個重複的外觀是很常見的，將所有的外觀細節屬性（colors、padding、font）放在style文件中。在應用中對於大多數文本內容，最起碼你應該有一個通用的style文件，例如：

<style name="ContentText">
    <item name="android:textSize">@dimen/font_normal</item>
    <item name="android:textColor">@color/basic_black</item>
</style>

應用到TextView中:

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/price"
    style="@style/ContentText"
    />

你或許需要爲按鈕控件做同樣的事情，不要停止在那裏。將一組相關的和重複android:****的屬性放到一個通用的style中。

將一個大的styles.xml文件分割成多個文件，你可以有多個styles.xml 文件。Android SDK支持其它文件，styles.xml這個文件名稱並沒有作用，起作用的是在文件裏的<style>標籤。因此你可以有多個style文件，如styles.xml、styles_home.xml、styles_item_details.xml、styles_forms.xml。不同於資源文件路徑需要爲系統構建起的有意義，在res/values目錄下的文件可以任意命名。

4.5 layout中的id命名

命名模式爲：view縮寫_模塊名_邏輯名，比如btn_main_search
使用AndroidStudio的插件ButterKnife Zelezny，生成註解非常方便，原生的話可以使用Android Code Generator插件。

如果想對資源文件進行分包可以參考我這篇文章～Android Studio下對資源進行分包

5 版本統一規範

Android開發存在着衆多版本的不同，比如compileSdkVersion、minSdkVersion、targetSdkVersion以及項目中依賴第三方庫的版本，不同的module及不同的開發人員都有不同的版本，所以需要一個統一版本規範的文件。
依賴配置包configLibrary中統一控制，包括各種依賴庫
SVN或git 提交代碼請先更新再提交，如有衝突必須解決衝突後提交，如將錯誤代碼提交導致他人工作停滯，通報批評！！
Ps.自己的錯誤自行承擔，強化責任意識！公司不聽理由，只看結果！

6 第三方庫規範

別再閉門造車了，用用最新最火的技術吧，安利一波～Android 流行框架查速表，順便帶上自己的乾貨～Android開發人員不得不收集的代碼

希望Team能用時下較新的技術，對開源庫的選取，一般都需要選擇比較穩定的版本，作者在維護的項目，要考慮作者對issue的解決，以及開發者的知名度等各方面。選取之後，一定的封裝是必要的。

個人推薦Team可使用如下優秀輪子：

Retrofit
RxAndroid
OkHttp
Glide / Fresco
Gson / Fastjson
EventBus / AndroidEventBus
GreenDao
Dagger2(選用)
Tinker(選用)

7 註釋規範

爲了減少他人閱讀你代碼的痛苦值，請在關鍵地方做好註釋。

7.1 類註釋

每個類完成後應該有作者姓名和聯繫方式的註釋，對自己的代碼負責。

/**
 * <pre>
 *     author : Blankj
 *     e-mail : xxx@xx
 *     time   : 2017/03/07
 *     desc   : xxxx描述
 *     version: 1.0
 * </pre>
 */
public class WelcomeActivity {
       ...
}

具體可以在AS中自己配製，Settings → Editor → File and Code Templates → Includes → File Header，輸入

/**
 * <pre>
 *     author : ${USER}
 *     e-mail : xxx@xx
 *     time   : ${YEAR}/${MONTH}/${DAY}
 *     desc   :
 *     version: 1.0
 * </pre>
 */

這樣便可在每次新建類的時候自動加上該頭註釋。

7.2 方法註釋

每一個成員方法（包括自定義成員方法、覆蓋方法、屬性方法）的方法頭都必須做方法頭註釋，在方法前一行輸入/** + 回車或者設置Fix doc comment(Settings → Keymap → Fix doc comment)快捷鍵，AS便會幫你生成模板，我們只需要補全參數即可，如下所示。

/**
 * bitmap轉byteArr
 *
 * @param bitmap bitmap對象
 * @param format 格式
 * @return 字節數組
 */
public static byte[] bitmap2Bytes(Bitmap bitmap, CompressFormat format) {
    if (bitmap == null) return null;
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    bitmap.compress(format, 100, baos);
    return baos.toByteArray();
}

7.3 塊註釋

塊註釋與其周圍的代碼在同一縮進級別。它們可以是/* ... */風格，也可以是// ...風格(//後最好帶一個空格）。對於多行的/* ... */註釋，後續行必須從*開始，並且與前一行的*對齊。以下示例註釋都是OK的。

/*
 * This is          // And so           /* Or you can
 * okay.            // is this.          * even do this. */
 */

註釋不要封閉在由星號或其它字符繪製的框架裏。

Tip：在寫多行註釋時，如果你希望在必要時能重新換行(即註釋像段落風格一樣)，那麼使用/* ... */。

7.4 其他一些註釋

AS已幫你集成了一些註釋模板，我們只需要直接使用即可，在代碼中輸入todo、fixme等這些註釋模板，回車後便會出現如下注釋

// TODO: 17/3/14 需要實現，但目前還未實現的功能的說明
// FIXME: 17/3/14 需要修正，甚至代碼是錯誤的，不能工作，需要修復的說明

8 測試規範

業務開發完成之後，開發人員做單元測試，單元測試完成之後，保證單元測試全部通過同時單元測試代碼覆蓋率達到一定程度（這個需要開發和測試約定，理論上越高越好），開發提測。
* 代碼寫完後發佈之前務必先用findBugs插件查找有誤低級錯誤，然後交由測試人員測試後，纔可將apk交與客戶
// TODO…

9 方法排序規範

使用butterknife生成的綁定代碼和成員變量請放到類最後面
類名下第一行爲佈局文件指向
類名下第二行爲initData()基本數據 & 網絡請求
類名下第三行爲butterknife生成的點擊事件羣 or initListener()
點擊事件或數據填充超過10行，請封裝方法AS快捷鍵“選中代碼塊”按ctrl+alt+M
務必保證一個原則：打開一個類最多拖動一到兩屏，可以清晰知道界面相關邏輯

10 其他的一些規範

合理佈局，有效運用<merge>、<ViewStub>、<include>標籤；
Activity和Fragment裏面有許多重複的操作以及操作步驟，所以我們都需要提供一個BaseActivity和BaseFragment，讓所有的Activity和Fragment都繼承這個基類。
方法基本上都按照調用的先後順序在各自區塊中排列；
相關功能作爲小區塊放在一起（或者封裝掉）；
當一個類有多個構造函數，或是多個同名方法，這些函數/方法應該按順序出現在一起，中間不要放進其它函數/方法；
數據提供統一的入口。無論是在 MVP、MVC 還是 MVVM 中，提供一個統一的數據入口，都可以讓代碼變得更加易於維護。比如可使用一個DataManager，把 http、preference、eventpost、database 都放在DataManger裏面進行操作，我們只需要與DataManger打交道；
多用組合, 少用繼承；
提取方法, 去除重複代碼。對於必要的工具類抽取也很重要，這在以後的項目中是可以重用的。
可引入 Dagger2 減少模塊之間的耦合性。Dagger2 是一個依賴注入框架，使用代碼自動生成創建依賴關係需要的代碼。減少很多模板化的代碼，更易於測試，降低耦合，創建可複用可互換的模塊；
項目引入RxJava + RxAndroid這些響應式編程，可以極大的減少邏輯代碼；
通過引入事件總線，如：EventBus、AndroidEventBus、RxBus，它允許我們在DataLayer中發送事件，以便ViewLayer中的多個組件都能夠訂閱到這些事件，減少回調；
儘可能使用局部變量；
及時關閉流；

儘量減少對變量的重複計算；

如下面的操作：

for (int i = 0; i < list.size(); i++) {
   ...
}

建議替換爲：

for (int i = 0, int length = list.size(); i < length; i++) {
   ...
}

儘量採用懶加載的策略，即在需要的時候才創建；

例如：

String str = "aaa";
if (i == 1) {
   list.add(str);
}

建議替換爲：

if (i == 1) {
   String str = "aaa";
   list.add(str);
}

不要在循環中使用try…catch…，應該把其放在最外層；
使用帶緩衝的輸入輸出流進行IO操作；
儘量使用HashMap、ArrayList、StringBuilder，除非線程安全需要，否則不推薦使用Hashtable、Vector、StringBuffer，後三者由於使用同步機制而導致了性能開銷；
儘量在合適的場合使用單例；

使用單例可以減輕加載的負擔、縮短加載的時間、提高加載的效率，但並不是所有地方都適用於單例，簡單來說，單例主要適用於以下三個方面：

（1）控制資源的使用，通過線程同步來控制資源的併發訪問

（2）控制實例的產生，以達到節約資源的目的

（3）控制數據的共享，在不建立直接關聯的條件下，讓多個不相關的進程或線程之間實現通信
把一個基本數據類型轉爲字符串，基本數據類型.toString()是最快的方式、String.valueOf(數據)次之、數據 + ""最慢；
使用AS自帶的Lint來優化代碼結構（什麼，你不會？右鍵module、目錄或者文件，選擇Analyze → Inspect Code）；
最後不要忘了內存泄漏的檢測；

最後囉嗦幾句：

好的命名規則能夠提高代碼質量，使得新人加入項目的時候降低理解代碼的難度；
規矩終究是死的，適合團隊的纔是最好的；
命名規範需要團隊一起齊心協力來維護執行，在團隊生活裏，誰都不可能獨善其身；
一開始可能會有些不習慣，持之以恆，總會成功的。

附錄

UI控件縮寫表

名稱	縮寫
TextView	tv
EditText	et
ImageButton	ib
Button	btn
ImageView	iv
ListView	lv
GridView	gv
ProgressBar	pb
SeekBar	sb
RadioButtion	rb
CheckBox	cb
ScrollView	sv
LinearLayout	ll
FrameLayout	fl
RelativeLayout	rl
RecyclerView	rv
WebView	wv
VideoView	vv
Spinner	spn
ToggleButton	tb

常見的英文單詞縮寫表

名稱	縮寫
icon	ic （主要用在app的圖標）
color	cl（主要用於顏色值）
average	avg
background	bg（主要用於佈局和子佈局的背景）
selector	sel主要用於某一view多種狀態，不僅包括Listview中的selector，還包括按鈕的selector）
buffer	buf
control	ctrl
default	def
delete	del
document	doc
error	err
escape	esc
increment	inc
infomation	info
initial	init
image	img
Internationalization	I18N
length	len
library	lib
message	msg
password	pwd
position	pos
server	srv
string	str
temp	tmp
window	wnd(win)