前言
做Android開發(fā)這么多年膀斋，見過很多人寫的代碼(開源代碼除外)飘弧，其中有的寫的代碼很簡潔午磁、很漂亮，讓人看起來很舒服伴嗡；有的寫的那是一塌糊涂，根本就沒有心思再往下看从铲。最近就是在做一個項目瘪校，由于之前的代碼很復(fù)雜，需要對整個軟件進行重構(gòu)名段，我是邊重構(gòu)邊吐槽阱扬。說多了都是淚啊伸辟！所以就準備寫一下這篇文章麻惶。另外說一點，本規(guī)范不是標準信夫，只是我自己在開發(fā)中所遵循的窃蹋。所以大家看看就行了卡啰。
一、命名規(guī)范
1脐彩、包的命名：
包的名字都是由小寫單詞組成碎乃。
1.1、 項目包名(APP的唯一ID)
一般的項目都是 ：com.公司名.項目名
1.2惠奸、功能模塊包名
這個包是項目下的功能模塊分包梅誓，主要有兩個命名方式：
- 按照文件的類型命名：
例如：activity/、adapter/佛南、fragment/ 等梗掰。 - 按照功能模塊命名：
例如：login/、register/嗅回、setting/ 等及穗。
2、類名
遵循兩點
- Java類名遵循大駝峰命名規(guī)范绵载。即：以大寫字母開頭埂陆、由多個單詞組成時，每一個單詞的首字母都大寫娃豹。
- 以功能模塊結(jié)尾焚虱。例如：LoginActivity、FriendListAdapter懂版、UserModel等鹃栽。
3、變量
標準的駝峰命名法躯畴。
4民鼓、靜態(tài)變量、常量蓬抄、枚舉類型
全部大寫丰嘉，由多個單詞組成的時候，每個單詞之間以“_”連接嚷缭。
5供嚎、方法名
- 遵循駝峰命名
- 根據(jù)方法實現(xiàn)功能來命名
- 初始化一般以init開頭
- 帶有返回值的以get開頭
- 設(shè)置數(shù)據(jù)的以set開頭
例如：initView()、userLogin()峭状、private UserModel getUserInfo()克滴、setUserFriendList(List<FriendMode> friendList)等。
6优床、其他
如果代碼中有需要實現(xiàn)的功能劝赔，但是當前沒有實現(xiàn)的代碼為了標記可以打上 //TODO標記
private void initView() {
//TODO
}
二、布局文件優(yōu)化
1胆敞、多用<include />着帽、<merge />標簽
Android方法建議是一個布局文件最多嵌套三層杂伟，這個大家應(yīng)該都知道吧，所以要多用<include />仍翰、<merge />標簽赫粥，這樣的好處有兩點：
- 減少層次的嵌套
- 增強布局的重復(fù)利用性。
2予借、多用style屬性
這個不用多說了吧越平，可以減少不少的代碼量。
3灵迫、文字顯示用"@string/xxx"
這個在做軟件的國際化的時候秦叛，是必須的。就算是不做國際化在需要修改某一個文字時也會很方便瀑粥。
4挣跋、屏幕適配
做Android的應(yīng)該很關(guān)心這一點吧。關(guān)于這一點應(yīng)該網(wǎng)上有很多的教程告訴我們要怎么去做狞换。我這里主要說我常用的方式避咆。
先分析頁面的結(jié)構(gòu)，最外層采用什么樣的layout修噪，如果是LinearLayout 多采用android:layout_weight屬性查库，如果是RelativeLayout就會多采用android:layout_centerxxx和android:layout_alignParentxxx屬性
三、代碼風(fēng)格
1割按、條件判斷
1.1膨报、能用Switch 代替的就用Switch磷籍。說一下我覺得用Switch的優(yōu)點：
- 有很多else if的時候适荣，用switch case比較清晰。
- 有很多else if的時候院领，用switch 的計算量少弛矛。
1.2、多判斷不成立的條件
拿一個登錄的功能做一個對比：
之前的代碼
if (TextUtils.isEmpty(useName)) {
//如果用戶名為空
showMessage("賬號為空比然，請輸入登錄賬號");
} else {
//如果用戶名不為空丈氓，判斷密碼
if (TextUtils.isEmpty(pwd)) {
//如果密碼為空
showMessage("密碼為空，請輸入密碼");
}else{
//如果密碼不為空强法，登錄
userLogin();
}
}
看到這里朋友不要笑万俗，也不要問誰會這樣寫啊，因為我的回答是饮怯，我真的見過有人這樣寫闰歪。代碼的邏輯很清晰，但是if..else..的嵌套太多了蓖墅。而且還加深了代碼的層次库倘。
我們再看看改過之后的代碼：
if (TextUtils.isEmpty(useName)) {
showMessage("賬號為空临扮，請輸入登錄賬號");
return;
}
if (TextUtils.isEmpty(useName)) {
showMessage("密碼為空，請輸入密碼");
return;
}
userLogin();
相比之下教翩，如何杆勇？是不是更簡潔一些？
1.3饱亿、判斷為對象為空和字符串為空字符的寫法
1.3.1蚜退、判斷一個對象是否為null
我見過很多都是這樣寫的
if(null == obj){
return;
}
關(guān)于這種寫法，我不想多說什么路捧，但是我不習(xí)慣這種寫法关霸，所以我們先看一下Android系統(tǒng)是怎么判斷一個字符是否為空或者是空字符的寫法：
public class TextUtils {
...
/** * Returns true if the string is null or 0-length.
* @param str the string to be examined
* @return true if str is null or zero length
*/
public static boolean isEmpty(@Nullable CharSequence str) {
if (str == null || str.length() == 0)
return true;
else
return false;
}
....
}
這個是在android.text包下面的一個工具類。借鑒官方的例子杰扫，我判斷對象是否為空一般寫法是：
if(obj == null){
return;
}
1.3.2队寇、判斷字符是否為空字符
我見過最多的寫法是
if(str.equals(""))
return;
}
可以說我之前帶過的工程師都是這么寫的，看到這種寫法我都會讓他們改章姓。原因很簡單佳遣，如果當str為null的時候，這段代碼是會NullPointerException的凡伊，我的寫法如下零渐，可以規(guī)避NullPointerException。
if("".equals(str)){
return;
}
2系忙、final 诵盼、static、static final 以及 final static 的區(qū)別
為什么要寫這個呢银还，感覺和主題無關(guān)胺缒？是啊蛹疯，本來我也是不想寫這個的戒财，想起之前有人問我：
什么是靜態(tài)變量，什么是常量捺弦，靜態(tài)變量和常量之間誰更省內(nèi)存饮寞？
那這個問題就牽涉到了軟件的內(nèi)存優(yōu)化的問題，所以還是提一下吧列吼。
說一下個人理解：
final
- 修飾類時幽崩，表示此類為最終類，不能被繼承
- 修飾方法(不包括構(gòu)造方法)時寞钥，此方法不可以被子類覆蓋慌申。
- 修飾變量時，就變成了常量(不可變量)凑耻，一般會伴隨static一起使用
static
- 修飾變量太示，即為靜態(tài)變量柠贤，靜態(tài)變量在內(nèi)存中只有一個拷貝(省內(nèi)存)，JVM只為靜態(tài)分配一次內(nèi)存类缤，在加載類的過程中完成靜態(tài)變量的內(nèi)存分配臼勉，可用類名直接訪問，當然也可以通過對象來訪問(不推薦)餐弱。（ps:這就是為什么final的常量會伴隨static一起使用的原因)
- static代碼塊是類加載時宴霸，初始化自動執(zhí)行的。如果static代碼塊有多個膏蚓，JVM將按照它們在類中出現(xiàn)的先后順序依次執(zhí)行它們瓢谢，每個代碼塊只會被執(zhí)行一次。
static{
.....
}
- static方法可以直接通過類名調(diào)用,static方法只能訪問static的變量和方法
上面首先解答了什么是常量驮瞧、什么是靜態(tài)變量的問題氓扛，那么再看一下誰更省內(nèi)存：
一個完整的Java程序運行過程會涉及以下內(nèi)存區(qū)域：
寄存器： JVM內(nèi)部虛擬寄存器，存取速度非陈郾剩快采郎，程序不可控制。
棧： 保存局部變量的值狂魔，包括：a.用來保存基本數(shù)據(jù)類型的值蒜埋；b.保存類的 實例 ，即堆區(qū) 對象 的引用(指針)最楷。也可以用來保存加載方法時的幀整份。
堆： 用來存放動態(tài)產(chǎn)生的數(shù)據(jù)，比如new出來的 對象 籽孙。注意創(chuàng)建出來的對象只包含屬于各自的成員變量烈评，并不包括成員方法。因為同一個類的對象擁有各自的成員變量蚯撩，存儲在各自的堆中础倍，但是他們共享該類的方法烛占，并不是每創(chuàng)建一個對象就把成員方法復(fù)制一次胎挎。
常量池： JVM為每個已加載的類型維護一個常量池，常量池就是這個類型用到的常量的一個有序集合忆家。包括直接常量(基本類型犹菇，String)和對其他類型、方法芽卿、字段的 符號引用(1) 揭芍。池中的數(shù)據(jù)和數(shù)組一樣通過索引訪問。由于常量池包含了一個類型所有的對其他類型卸例、方法称杨、字段的符號引用肌毅，所以常量池在Java的動態(tài)鏈接中起了核心作用。 常量池存在于堆中 姑原。
代碼段： 用來存放從硬盤上讀取的源程序代碼悬而。
全局數(shù)據(jù)段： 用來存放static定義的靜態(tài)成員或全局變量。分配該區(qū)時內(nèi)存全部清0锭汛，結(jié)果變量的初始化為0笨奠。
下圖表示內(nèi)存分配圖：
具體參考：Java中的內(nèi)存處理機制和final、static唤殴、final static總結(jié)
static屬性在類加載般婆，也就是第一次用到這個類的時候初始化，對于后來的實例的創(chuàng)建朵逝，不再次進行初始化蔚袍。
常量在代碼執(zhí)行之前綁定到內(nèi)存單元,并且在整個程序執(zhí)行過程中都指向相同的內(nèi)存單元.
所以，在程序的啟動時配名，常量要相對與靜態(tài)變量占內(nèi)存页响，而在軟件運行過程中，他們是一樣的段誊。但是對于小運行內(nèi)存的手機來說闰蚕，大量的static 和final 是要盡量要避免的。
3连舍、視圖與邏輯處理分開
這一點很重要没陡。這也是我寫這篇文章的最主要目的，我說過索赏，最近是在對一個項目進行重構(gòu)盼玄。其中，有一個自定義的 View,里面充斥著大量的邏輯代碼還有網(wǎng)絡(luò)請求等等潜腻“６看到這種代碼，我是徹底無語了融涣。
以下為個人理解：
View本身只是一個控件童番，可以提供接口或者方法讓外部改變其內(nèi)容或者形狀，并且需要把自己的觸摸事件返回給調(diào)用者威鹿。需要做什么完全交由調(diào)用者自己去實現(xiàn)剃斧。
所以，一個視圖忽你，僅僅是做顯示的幼东，怎么能進行邏輯代碼的處理？不管從任何角度來說，都不應(yīng)該這樣做根蟹。
4脓杉、分模塊，各司其職
在進行代碼重構(gòu)的時候简逮，抽時間學(xué)習(xí)了下MVP(Model View Presenter)模式丽已。這里先說一下Android中的MVC。在說之前先問大家一個問題:
在你們做過的項目中买决，哪些是M,哪些是V,哪些又是C?
先不要往下看沛婴，先仔細想一想。
相信會有很多人包括之前的我在內(nèi)督赤，都會認為M就是寫的一些實體類嘁灯，V就是寫的布局文件，C就是寫在Activity里面的邏輯代碼躲舌。而且有的時候V和C還是混合的丑婿。
但是后來發(fā)現(xiàn)不是這樣的。
MVC for Android
在Android開發(fā)中没卸，比較流行的開發(fā)框架模式采用的是MVC框架模式羹奉，采用MVC模式的好處是便于UI界面部分的顯示和業(yè)務(wù)邏輯，數(shù)據(jù)處理分開约计。那么Android項目中哪些代碼來充當M,V,C角色呢诀拭？
M層：適合做一些業(yè)務(wù)邏輯處理，比如數(shù)據(jù)庫存取操作煤蚌，網(wǎng)絡(luò)操作耕挨，復(fù)雜的算法，耗時的任務(wù)等都在model層處理尉桩。
V層：應(yīng)用層中處理數(shù)據(jù)顯示的部分筒占，XML布局可以視為V層，顯示Model層的數(shù)據(jù)結(jié)果蜘犁。
C層：在Android中翰苫，Activity處理用戶交互問題，因此可以認為Activity是控制器这橙，Activity讀取V視圖層的數(shù)據(jù)（eg.讀取當前EditText控件的數(shù)據(jù)）奏窑，控制用戶輸入（eg.EditText控件數(shù)據(jù)的輸入），并向Model發(fā)送數(shù)據(jù)請求（eg.發(fā)起網(wǎng)絡(luò)請求等）析恋。
具體可參考鏈接：框架模式 MVC 在Android中的使用
同樣的問題良哲，如果采用MVP模式盛卡，在你們做過的項目中助隧，哪些是M,哪些是V,哪些又是P?
View層負責(zé)處理用戶事件和視圖部分的展示。在Android中，它可能是Activity或者Fragment類并村。
Model層負責(zé)訪問數(shù)據(jù)巍实。數(shù)據(jù)可以是遠端的Server API，本地數(shù)據(jù)庫或者SharedPreference等哩牍。
Presenter層是連接（或適配）View和Model的橋梁棚潦。
具體參考鏈接：Android開發(fā)中的MVP架構(gòu)詳解
本文的重點不是研究什么是MVP和什么是MVC,只是想說，不管是在代碼重構(gòu)的時候還是說開發(fā)新項目的時候膝昆，都應(yīng)該采取一種開發(fā)模式丸边，一個是方便代碼的維護，另一個就是方便別人閱讀荚孵。
就拿之前重構(gòu)的那個自定義View類來說妹窖，不出bug還好一點，一旦出現(xiàn)什么問題收叶，那是牽一發(fā)而動全身敖竞簟！代價很大的判没。
先寫這么多吧蜓萄，如果想到什么以后再補充。
以上都是個人觀點澄峰，不當之處嫉沽，敬請諒解。
