命名規則
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。