Android編程規範不徹底指南

命名規則

1). 類名，接口名：

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

例如 HttpRequest，CourseActivity

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

以小寫字母開頭其餘的單詞首字母大寫，變量名不建議使用下劃線分隔單詞，建議使用駝峯命名法，Android的系統類都採用此方法。

例如 toString()  onCreateView(Bundle savedInstanceState)

3). 靜態常量：所有大寫，單詞之間使用下劃線分開，常量單詞所有大寫，因此單詞之間使用下劃線分隔。

例如 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). 經常使用控件以及類對象命名的規範說明(紅色部分爲建議的前綴或者後綴)：

類名	變量名	類名	變量名
TextView	txtDescription	ProgressBar	progressDescription
Button	btnDescription	SeekBar	seekBarDescription
ImageButton	imgBtnDescription	VideoView	vvDescription
ImageView	imgDescription	Spinner	spinDescription
RadioButton	rbDescription	WebView	webViewDescription
EditText	editDescription	ListView	listViewDescription
ScrollView	scrollDescription	GridView	gridDescription
Handler	descriptionHandler	RatingBar	ratingBarDescription
PullToRefreshListView	pullRefreshViewDescription	Adapter	descriptionAdapter
Fragment	descriptionFragment	Activity	descriptionActivity
List<T>	descriptionList	Map<>	mapDescription
SlidingMenu	slidMenuDescription	ViewPager	viewPagerDescription
CheckBox	chBoxDescription	View	viewDescription
RadioGroup	rgDescription	ExpandableListView	expDescription
FrameLayout	frameLayDescription	SharedPreferences	spDescription
LinearLayout	lineLayDescription	RelativeLayout	relativeLayDescription
startActivityForResult(requestCode)	REQUEST_CODE_DESCRIPTION	msg.what	WHAT_DESCRIPTION

6). 資源命名：

layout資源文件的命名(所有小寫，下劃線分隔)：
activity的資源文件：activity_description1_description2.xml
fragment的資源文件：fragment_description1_description2.xml
listview列表項的資源文件：list_item_description1_description2.xml
可複用(被include)的組件資源文件: control_description1_description2.xml
drawable資源： controlName_description1_description2_selector.xml
controlName表示該資源要用在什麼類型的控件上面，例如若是是按鈕的圖片切換則
應該這麼定義 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可能有不少等級，有時候須要不一樣等級的灰色，沒有那麼多英文名能夠區分，因此名字中能夠直接使用顏色值
<color name=」color_button_pressed」>#4c4c4c</color> 根據功能定義description，表示該顏色用於按鈕被按下

注：不容許出現毫無心義的命名，例如textview1,textview2

關於字面常量

代碼中不容許出現直接硬編碼的字面常量，若是是控件上面顯示的文本，必須放在strings.xml資源文件中。 若是是代碼中用到常量字符串，必須定義成 public static final String類型的常量值，在代碼中使用該定義的常量值。這樣作的好處是之後須要修改該常量值，只須要修改一個地方。若是是硬編碼在代碼中則要修改全部使用它的地方，並且拷貝容易出錯。在Activity之間傳遞參數的時候，intent.putExtra 的key值也要命名規範，而且統必定義爲靜態常量，不能直接硬編碼在代碼中，不然想要修改的時候很麻煩。某一個Activity在被啓動的時候須要接受參數，那麼這些參數的key定義就應該放在該Activity中。

JSON解析

Android中調用服務端的接口通常返回的是json數據，在解析json的時候，不管是使用原始的手工解析方式，仍是使用javabean的解析方式，解析出來的結果在使用的時候必須都進行判空處理。不容許由於服務端的json出問題，致使app在解析json的時候出現崩潰。

類成員初始化

全部類的成員變量必定要賦初始值，不容許只定義，不賦值。

Int類型常量

函數返回的時候，若是返回的int類型的數據並非真實的實用的數據值(例如表示高度，寬度，大小等值)，僅僅表示函數執行成功、失敗、異常的狀態值，而且這些值是有限的幾個值，必需要將這些值使用靜態常量描述，或者使用枚舉，例如：

int  GetJsonString()

該函數返回-1表示獲取解析json數據異常，返回0表示成功，返回1表示網絡鏈接異常，返回2表示json內容中的數據部分爲空。那麼在函數內部的代碼裏不要直接使用這些字面值，這些字面值對於程序員來講是毫無心義的，代碼可閱讀性不好，建議作成下面的模式：

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;

使用這些符號常量值代替字面值的好處是，符號常量值是由大寫的英文單詞組成，是有意義的，能夠幫助程序員更好的理解函數返回值的意義，並且符號常量值對應的具體的賦值在後期是很方便修改的。

Activity接受參數與模塊化

若是一個Activity可能在多個地方被打開，或者一個Fragment可能在多個地方被用到。那麼在設計該Activity和Fragment的時候必定要考慮低耦合，對外提供統一的參數接口，啓動Activity的過程封裝在該Activity類的靜態成員方法裏面，相似以下：

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);
	}
}

參數的傳遞最好是封裝在一個Model實體類中，避免使用Map這種方式進行參數傳遞。建議該實體類實現爲對應的Activity的靜態可序列化的內部類。

AndroidStudio工程目錄組織

AndroidStudio中的項目的包結構應該根據工程各個部分的功能來組織。

Handler的封裝

每個Activity裏面幾乎都會定義一個Handler內部類，可是不少Activity裏面的Handler都使用了重複的消息類型，這裏面是有冗餘代碼的，因此應該把這些Activity都使用到的Handler類的消息部分，提取成一個公用的Handler類。而後在各個Activity裏面使用繼承的方式，來提供該Activity特有的Handler消息類型的Handler類實現。

另外Handler發送消息應該使用Handler類的成員函數，不該該直接使用handler.obtainMessage(xxx).sendToTarget();這種原始的發送消息的方式，這樣不利於下降耦合，這種細節應該隱藏在Handler內的裏面。Handler的消息類型應該定義爲Handler類裏面的靜態常量，而該常量不該是public的，對外部不可見。也就是說使用handler對象發送消息的細節不該該暴露給外部。

List的數據更新

封裝ListView的數據更新，在handlerMessage中更新數據，避免出現 java.lang.IllegalStateException 問題

Activity與Fragment之間傳遞參數

Activity與Fragment的數據傳遞採用interface的方式，這樣能夠下降耦合，有利於Fragment的複用：

網絡請求數據模塊化

通常在Activity中咱們經過網絡請求服務端的接口得到數據，這個過程通常是在一個線程中作的，獲取到數據以後，再經過Activity中的handler發送消息來通知Activity更新數據。該負責獲取數據的線程類，咱們通常都實現爲一個Activity的內部類，該類能夠直接訪問Activity的成員變量，例如handler，數據列表對象等。可是這樣不利於該數據獲取線程的複用。若是另外一個Activity裏面也須要獲取相同的數據，那麼這個功能是不能複用的，因此這個負責數據請求的線程類，不該該與具體的Handler和Activity聯繫過於緊密。應該定義爲一個靜態類，handler應該做爲參數傳遞進來，而不是直接訪問外部類的成員變量。

封裝Log功能

Log功能應該封裝成爲自動將當前所在類的類名變成log輸出的TAG參數，發佈的app最好是能循環寫日誌文件到系統存儲中，而且日誌文件應該使用反覆覆蓋的方式重複利用。下面僅僅是一個不完善的例子：

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");

打印結果

V/myapp MainActivity﹕ hello log

版本控制

使用自動化版本管理，自動生成版本號，使應用程序的版本與版本庫上保持一致。使用hg替換工程目錄下的app目錄下的build.gradle文件便可，若是manifest裏面也有版本號的設置，AndroidStudio仍是以build.gradle爲準。不該該在每次發佈的時候，在AndroidStudio的工程設置裏面手工修改版本號。

爲程序添加全局異常捕獲

應該爲app添加全局異常捕獲，app中總會有一些咱們未捕獲的異常，一旦用戶使用過程當中遇到這樣的異常，程序就會崩潰，咱們應該檢測該類未捕獲的異常信息，程序崩潰的時候經過寫文件日誌，或者發送郵件的方式得到異常信息，以便解決bug。