開發一個Android應用之前，應該考慮點什麼？
本文原創，轉載請註明出處。
歡迎關注我的 簡書 ，關注我的專題 Android Class 我會長期堅持爲大家收錄簡書上高質量的Android相關博文。
寫在前面：
昨天參加了秋百萬大大組織的北京GDG活動，收穫頗豐。又跟幾個有寫作習慣的朋友建立了一個“神祕組織”，每兩週爲一個週期，每人都會產出一篇原創的文章，互相校驗和探討，意在督促組員之間學習和分享開源技術。而簡書上的平臺就交給我維護了，不出意外，幾天之內大家就可以看到我們的主頁和第一期成員的文章啦，敬請期待~
前幾天接手了一個老員工遺留下來的代碼，別提多痛苦了，甚至有了讓我推倒重寫的衝動，很多地方的設計問題頗多，老大也快無法忍受了。。。上學的時候寫一篇作文，要想好主題立意和分段，解數學題的時候也得在草稿紙上梳理清楚邏輯之後再下筆。其實開發一個Android也應是如此，不做準備，埋頭苦寫，最後會導致問題頗多。所以本文會根據網絡上優秀內容和我實際的開發經驗討論總結一下，開發一個Android應用之前，都應該做哪些準備。
編碼規範
編碼規範的問題是我最先想強調的，因爲我接手的項目命名就極其混亂，甚至在一個類中的命名都沒有統一化（生無可戀臉）。代碼可能不是你自己一個人寫，保證代碼可讀性是非常必要的。而規範存在的意義就是淡化每個人的習慣而達到統一。不多說，下面就介紹Android的編碼規範。
- 除了註釋，代碼中不出現中文
- 每個類寫上必要的註釋，類的說明，作者，聯繫方式
- 方法加上必要的註釋說明，方便以後維護
包管理
- base:存放基礎類的包，裏面的類以Base爲前綴，例如BaseActivity；
- activity:存放activity的包，每個activity命名以Activity結尾，例如MainActivity;
- fragment:存放fragment的包，每個fragment命名以Fragment結尾，例如ChatFragment;
- receiver:存放receiver的包；
- service:存放service的包；
- adapter:存放adapter的包，每個adapter命名以Adapter結尾，例如EventItemAdapter;
- common:存放一些公共常量，例如後端接口、SharedPreferenceKey、IntentExtra等;
- utils:存放工具類的包，比如常見的工具類：LogUtils、DateUtils；
- entity:存放實體類的包；
- widget:存放自定義View的包；
以上是一些常見的包，但不侷限於此，視項目的具體情況而定。
命名
大駝峯命名(UpperCamelCase)：每個單詞的第一個字母都大寫。
小駝峯命名(lowerCamelCase)：除第一個單詞以外，每一個單詞的第一個字母大寫。
命名的基本原則:
- 儘可能地使用統一的命名規範；
- 不使用漢語拼音；
- 除了常見的英文縮寫，儘量少地使用縮寫；
包命名
- 小寫字母，參見上文包管理；
- 連續的單詞直接連接起來，不使用下劃線；
Java類命名
- 大駝峯命名 UserListAdapter；
- 除常見的縮寫單詞以外，不使用縮寫，縮寫的單詞每個字母都大寫 RequesURLList；
- 公共的工具類建議以Utils、Manager爲後綴，如LogUtils；
- 接口命名遵循以上原則，以able或ible爲後綴；
變量命名
- 成員變量命名
- 小駝峯命名；
- 不推薦使用谷歌的前面加m的編碼風格（如果使用團隊中使用m，則統一使用）；
- 常量命名
- 單詞每個字母均大寫；
- 單詞之間下劃線連接；
- 控件變量命名
- 小駝峯命名；
- 建議使用 控件縮寫+邏輯名稱 格式，例如 tvPostTitle、etUserName；
- 對應的控件的id的命名控件縮寫_邏輯名稱，單詞均小寫，用下劃線連接，例如：tv_post_title、
- et_user_name；
- 常見的控件縮寫如下：
控件 縮寫
Linearlayout ll
RelativeLayout rl
TextView tv
EditText et
Button btn
ImageView iv
CheckBox chb
ListView lv
GridView gv
RadioButton rb
方法命名
- 小駝峯命名；
- Getter和Setter方法，推薦使用自動生成的，寫起來也很方便。注意，bool類型的變量Getter方法寫成isTrue這種；
- 方法名應當保證見名知義的原則，儘量不使用or或者and，遵循“do one thing”原則；
佈局文件命名
- activity、fragment佈局文件名以對應的類別名稱爲前綴，邏輯名稱放在其後，以下劃線連接，例如activity_home、fragment_chat_list，方便查找；
- ListView、GridView的item佈局文件建議以list_item、gird_item爲前綴，加上對應的邏輯名稱，例如
list_item_post、grid_item_photo； - Dialog的佈局文件以dialog爲前綴，邏輯名稱放在其後，下劃線連接，例如dialog_warnning;
包含項佈局命名以include開頭，在加上對應的邏輯名稱，例如include_foot - 控件的id命名參見控件變量命名；
資源命名
- 圖標資源以ic爲前綴，例如ic_chat，指聊天圖標；
- 背景圖片以bg爲前綴，例如bg_login，指的是登錄頁的背景圖；
- 按鈕圖片以btn爲前綴，例如btn_login，指的是登錄按鈕的圖片，不過這隻有一種狀態，需要加上狀態的可以在後面添加，例如btn_login_pressed，表示登錄按鈕按下的圖片；
- 當使用shape和selector文件爲背景或者按鈕時，命名參照以上說明；
項目架構
項目框架
一個好的項目架構可以降低項目的複雜性，並且易擴展、易維護，耦合低，結構清晰，功能內聚。
MVC，MVP，MVVM還有一些設計模式，結合你app的業務，自行選擇一個最合適的一條路走到黑，建議不要“混搭”。
開源框架
開源框架的選擇分兩大類，一是權威性毫無爭議，放心選擇的這類幫助我們快速開發的，比如：
- 網絡 Retrofit + OkHttp+ RxJava、Volley、android-async-http
- 依賴注入 Dagger2、ButterKnife、RoboGuice
- 事件總線 otto、EventBus
- 圖片加載 Fresco、Glide、Picasso
- 數據庫 GreenDao、Ormlite、LitePal
- 日誌輸出 logger、LogUtils
- 當然不能忘了Google提供的兼容support全家桶
還有一類框架雖然不是毫無爭議，但是也能極大節省我們的時間，提升開發效率，對於這類項目，要在Github上長期淘寶了。找那種star很多，issues解決很快，長期維護的項目，這種坑會比較少。
代碼細節
抽取基類
即使目前你沒有需要，也一定要抽取一個BaseActivity和BaseFragment，因爲早晚會用到，切記！
比如：
public abstract class BaseActivity extends Activity{
@Override
public void onCreate(Bundle savedInstanceState, PersistableBundle persistentState) {
super.onCreate(savedInstanceState, persistentState);
init();
}
private void init() {
setContentView(R.layout.activity_main);
initView();
initData();
initListener();
}
/**
* 初始化佈局
*/
protected abstract void initView();
/**
* 初始化數據
*/
protected abstract void initData();
/**
* 初始化偵聽
*/
protected abstract void initListener();
}BaseFragment也同理，隨着業務的增加和抽象，基類會繼續擴展。其實不僅僅是BaseActivity和BaseFragment，如果你一個業務模塊中有很多相似和相同的邏輯，也可以抽取一個BaseXXX這是非常好的一個習慣。
還有一些建議，不做展開，大家請自行搜索：
- Android Studio上好用的插件
- selector
- 圖片的.9處理
- Resources xml文件中，記得用註釋分割每個類用到的資源，建議不共用
- 慎用static關鍵字
- 定期code review，不斷代碼重構
性能優化
推薦一個我曾經寫過的總結：
寫在後面：
本文做了一個初步總結，未來會慢慢擴展和完善，如果有遺漏，大家可以補充~