命名規(guī)則

1). 類名，接口名：

以大寫開頭，如果一個類的類名由多個單詞組成，所有單詞的首字母必須大寫，單詞盡量寫全稱，不要簡寫，除非約定俗成的名字，例如：URL，RTMP，RTSP 這些廣泛使用的專有名詞，可以全部大寫，也可以首字母大寫。

例如 HttpRequest，CourseActivity

2). 局部變量，類的成員變量，類的成員函數(shù)，函數(shù)參數(shù)：

以小寫字母開頭其他的單詞首字母大寫，變量名不建議使用下劃線分隔單詞，建議使用駝峰命名法，Android的系統(tǒng)類都采用此方法。

例如 toString()  onCreateView(Bundle savedInstanceState)

3). 靜態(tài)常量：全部大寫，單詞之間使用下劃線分開，常量單詞全部大寫，所以單詞之間使用下劃線分隔。

例如 WHAT_EMPTY_CONTENT

4). 控件變量的命名，控件的ID命名：

建議：xml布局文件中的控件的id的命名與*.java的代碼文件中的控件對象的命名一致。

class  MyActivity extends Activity{ 
TextView  txtUserName  ; 
… 
protected void onCreate(Bundle savedInstanceState) { 
  txtUserName =  (TextView) findViewById(R.id.txtUserName); 
} 
} 

5). 常用控件以及類對象命名的規(guī)范說明(紅色部分為建議的前綴或者后綴)：

6). 資源命名：

layout資源文件的命名(全部小寫，下劃線分隔)：
activity的資源文件：activity_description1_description2.xml
fragment的資源文件：fragment_description1_description2.xml
listview列表項的資源文件：list_item_description1_description2.xml
可復(fù)用(被include)的組件資源文件: control_description1_description2.xml
drawable資源： controlName_description1_description2_selector.xml
controlName表示該資源要用在什么類型的控件上面，例如如果是按鈕的圖片切換則
應(yīng)該這么定義 button_bg_sendmessage_selector.xml
selector表示該資源的形式，例如還有shape等
圖片資源的名字：同上
顏色值的命名：  color_description  以color為前綴，全部小寫，下劃線分隔。description既可以是該顏色值使用的功能描述，也可以是該顏色值的英文描述，也可以是具體的顏色值，例如：

<color name="color_white">#ffffff</color> 
<color name="color_grey_ccc">#cccccc</color> 
<color name="color_grey_ddd">#dddddd</color> 

因為grey可能有很多等級，有時候需要不同等級的灰色，沒有那么多英文名可以區(qū)分，所以名字中可以直接使用顏色值
<color name=”color_button_pressed”>#4c4c4c</color> 根據(jù)功能定義description，表示該顏色用于按鈕被按下

注：不允許出現(xiàn)毫無意義的命名，例如textview1,textview2 

關(guān)于字面常量

代碼中不允許出現(xiàn)直接硬編碼的字面常量，如果是控件上面顯示的文本，必須放在strings.xml資源文件中。 如果是代碼中用到常量字符串，必須定義成 public static final String類型的常量值，在代碼中使用該定義的常量值。這樣做的好處是以后需要修改該常量值，只需要修改一個地方。如果是硬編碼在代碼中則要修改所有使 用它的地方，而且拷貝容易出錯。在Activity之間傳遞參數(shù)的時候，intent.putExtra 的key值也要命名規(guī)范，并且統(tǒng)一定義為靜態(tài)常量，不能直接硬編碼在代碼中，否則想要修改的時候很麻煩。某一個Activity在被啟動的時候需要接受參 數(shù)，那么這些參數(shù)的key定義就應(yīng)該放在該Activity中。

JSON解析

Android中調(diào)用服務(wù)端的接口一般返回的是json數(shù)據(jù)，在解析json的時候，無論是使用原始的手工解析方式，還是使用javabean的解 析方式，解析出來的結(jié)果在使用的時候必須都進行判空處理。不允許因為服務(wù)端的json出問題，導(dǎo)致app在解析json的時候出現(xiàn)崩潰。

類成員初始化

所有類的成員變量一定要賦初始值，不允許只定義，不賦值。

Int類型常量

函數(shù)返回的時候，如果返回的int類型的數(shù)據(jù)并不是真實的實用的數(shù)據(jù)值(例如表示高度，寬度，大小等值)，僅僅表示函數(shù)執(zhí)行成功、失敗、異常的狀態(tài)值，并且這些值是有限的幾個值，必須要將這些值使用靜態(tài)常量描述，或者使用枚舉，例如：

int  GetJsonString() 

該函數(shù)返回-1表示獲取解析json數(shù)據(jù)異常，返回0表示成功，返回1表示網(wǎng)絡(luò)連接異常，返回2表示json內(nèi)容中的數(shù)據(jù)部分為空。那么在函數(shù)內(nèi)部的代碼里不要直接使用這些字面值，這些字面值對于程序員來說是毫無意義的，代碼可閱讀性很差，建議做成下面的模式：

public static final int RESULT_PARSE_JSON_EXCEPTION = -1; 
public static final int RESULT_SUCCESS = 0; 
public static final int RESULT_NETWORK_EXCEPTION = 1; 
public static final int RESULT_NO_DATA = 2; 

使用這些符號常量值代替字面值的好處是，符號常量值是由大寫的英文單詞組成，是有意義的，可以幫助程序員更好的理解函數(shù)返回值的意義，而且符號常量值對應(yīng)的具體的賦值在后期是很方便修改的。

Activity接受參數(shù)與模塊化

如果一個Activity可能在多個地方被打開，或者一個Fragment可能在多個地方被用到。那么在設(shè)計該Activity和Fragment 的時候一定要考慮低耦合，對外提供統(tǒng)一的參數(shù)接口，啟

動Activity的過程封裝在該Activity類的靜態(tài)成員方法里面，類似如下： 
 
class MyActivity extends Activity{ 
... 
public static void startActivity(Context context,Params param){ 
  Intent intent = new Intent(context, MyActivity.class);  
  intent.putExtra("param", param); 
  startActivity(intent); 
} 
 
public static void startActivityForResult(Context context,Params param){ 
  Intent intent = new Intent(context, MyActivity.class);  
  intent.putExtra("param", param); 
  startActivityForResult(intent,REQUEST_CODE); 
} 
} 

參數(shù)的傳遞***是封裝在一個Model實體類中，避免使用Map這種方式進行參數(shù)傳遞。建議該實體類實現(xiàn)為對應(yīng)的Activity的靜態(tài)可序列化的內(nèi)部類。

AndroidStudio工程目錄組織

AndroidStudio中的項目的包結(jié)構(gòu)應(yīng)該根據(jù)工程各個部分的功能來組織。

Handler的封裝

每一個Activity里面幾乎都會定義一個Handler內(nèi)部類，但是很多Activity里面的Handler都使用了重復(fù)的消息類型，這里面 是有冗余代碼的，所以應(yīng)該把這些Activity都使用到的Handler類的消息部分，提取成一個公用的Handler類。然后在各個Activity 里面使用繼承的方式，來提供該Activity特有的Handler消息類型的Handler類實現(xiàn)。

另外Handler發(fā)送消息應(yīng)該使用Handler類的成員函數(shù)，不應(yīng)該直接使用handler.obtainMessage(xxx).sendToTarget();這 種原始的發(fā)送消息的方式，這樣不利于降低耦合，這種細節(jié)應(yīng)該隱藏在Handler內(nèi)的里面。Handler的消息類型應(yīng)該定義為Handler類里面的靜 態(tài)常量，而該常量不應(yīng)是public的，對外部不可見。也就是說使用handler對象發(fā)送消息的細節(jié)不應(yīng)該暴露給外部。

List的數(shù)據(jù)更新

封裝ListView的數(shù)據(jù)更新，在handlerMessage中更新數(shù)據(jù)，避免出現(xiàn) java.lang.IllegalStateException 問題

Activity與Fragment之間傳遞參數(shù)

Activity與Fragment的數(shù)據(jù)傳遞采用interface的方式，這樣可以降低耦合，有利于Fragment的復(fù)用：

網(wǎng)絡(luò)請求數(shù)據(jù)模塊化

一般在Activity中我們通過網(wǎng)絡(luò)請求服務(wù)端的接口獲得數(shù)據(jù)，這個過程一般是在一個線程中做的，獲取到數(shù)據(jù)之后，再通過Activity中的 handler發(fā)送消息來通知Activity更新數(shù)據(jù)。該負責獲取數(shù)據(jù)的線程類，我們一般都實現(xiàn)為一個Activity的內(nèi)部類，該類可以直接訪問 Activity的成員變量，例如handler，數(shù)據(jù)列表對象等。但是這樣不利于該數(shù)據(jù)獲取線程的復(fù)用。如果另一個Activity里面也需要獲取相同 的數(shù)據(jù)，那么這個功能是不能復(fù)用的，所以這個負責數(shù)據(jù)請求的線程類，不應(yīng)該與具體的Handler和Activity聯(lián)系過于緊密。應(yīng)該定義為一個靜態(tài) 類，handler應(yīng)該作為參數(shù)傳遞進來，而不是直接訪問外部類的成員變量。

封裝Log功能

Log功能應(yīng)該封裝成為自動將當前所在類的類名變成log輸出的TAG參數(shù)，發(fā)布的app***是能循環(huán)寫日志文件到系統(tǒng)存儲中，并且日志文件應(yīng)該使用反復(fù)覆蓋的方式重復(fù)利用。下面僅僅是一個不完善的例子：

public class MyLog { 
  public static final String TAG = "myapp "; 
  public static void v(Object o,String message) 
  { 
      Log.v(TAG+o.getClass().getSimpleName(),message); 
  } 
} 

使用

MyLog.v(this,"hello log"); 

打印結(jié)果

V/myapp MainActivity﹕ hello log 

版本控制

使用自動化版本管理，自動生成版本號，使應(yīng)用程序的版本與版本庫上保持一致。使用hg替換工程目錄下的app目錄下的build.gradle文件 即可，如果manifest里面也有版本號的設(shè)置，AndroidStudio還是以build.gradle為準。不應(yīng)該在每次發(fā)布的時候，在 AndroidStudio的工程設(shè)置里面手工修改版本號。

為程序添加全局異常捕獲

應(yīng)該為app添加全局異常捕獲，app中總會有一些我們未捕獲的異常，一旦用戶使用過程中遇到這樣的異常，程序就會崩潰，我們應(yīng)該檢測該類未捕獲的異常信息，程序崩潰的時候通過寫文件日志，或者發(fā)送郵件的方式獲得異常信息，以便解決bug。