我的 Android 開發(fā)實戰(zhàn)經驗總結
2018-07-20 來源：編程學習網
以前一直想寫一篇總結 Android 開發(fā)經驗的文章，估計當時的我還達不到某種水平，所以思路跟不上，下筆又捉襟見肘。近日，思路較為明朗，于是重新操起鍵盤開始碼字一番。先聲明一下哈，本人不是大廠的程序猿。去年畢業(yè)前，就一直在當前創(chuàng)業(yè)小團隊從事自己熱愛的打碼事業(yè)至今。下面總結是建立在我當前的技術水平和認知上寫的，如有不同看法歡迎留下評論互相交流。
1.理解抽象，封裝變化
目前 Android 平臺上絕大部分開發(fā)都是用著 Java ，而跟 Java 這樣一門面向對象的語言打交道，不免要觸碰到 抽象 和 封裝 的概念。我身邊接觸過的一些開發(fā)者，有一部分還對這些概念停留在寫一個抽象類、接口、或者一個方法（或抽象方法）。至于為什么，我不大清楚是他們表達不出來，還是不理解。下面我也不高談闊論，直接舉例子來解釋我所理解的抽象。
//Activity 間使用 Intent 傳遞數據的兩種寫法 下面均是偽代碼形式，請忽略一些細節(jié)
//寫法一
//SrcActivity 傳遞數據給 DestActivity
Intent intent = new Intent(this,DestActivity.class);
intent.putExtra("param", "clock");
SrcActivity.startActivity(intent);
//DestActivity 獲取 SrcActivity 傳遞過來的數據
String param = getIntent.getStringExtra("param");
//寫法二
//SrcActivity 傳遞數據給 DestActivity
Intent intent = new Intent(this,DestActivity.class);
intent.putExtra(DestActivity.EXTRA_PARAM, "clock");
SrcActivity.startActivity(intent);
//DestActivity 獲取 SrcActivity 傳遞過來的數據
public final static String EXTRA_PARAM = "param";
String param = getIntent.getStringExtra(EXTRA_PARAM);
寫法一，存在的問題是，如果 SrcActivity 和 DestActivity 哪個把 "param" 打錯成 "para" 或者 "paran" ，傳遞的數據都無法成功接收到。而寫法二則不會出現此類問題，因為兩個 Activity 之間傳遞數據只需要知道 EXTRA_PARAM 變量即可，至于 EXTRA_PARAM 變量到底是 "param" 、 "para" 、"paran" 這一點并不需要關心，這就是一種對可能發(fā)生變化的地方進行抽象封裝的體現，它所帶來的好處就是降低手抖出錯的概率，同時方便我們進行修改。
基于抽象和封裝，Java 本身很多 API 在設計上就有這樣的體現，如 Collections 中的很多排序方法：
Collections中的排序API
這些方法都是基于 List 這個抽象的列表接口進行排序，至于這是一個用什么樣的數據結構實現 List（ArrayList 還是 LinkedList），排序方法本身并不關心�？�，是不是體現了 JDK 的設計人員的一種抽象編程的思維，因為 List 的具體實現可能有千萬種，如果每一類 List 都要寫一套排序方法，估計要哭瞎了。
小結：把容易出現變化的部分進行抽象，就是對變化的一種封裝。
2.選好"車輪"
一個項目的開發(fā)，我們不可能一切從0做起，如果真是這樣，那同樣要哭瞎。因此，善于借用已經做好的 "車輪" 非常重要，如：
網絡訪問框架：okhttp、retrofit、android-async-http、volley
圖片加載框架：Android-Universal-Image-Loader、Glide、Fresco、Picasso
緩存框架：DiskLruCache、 Robospice
Json解析框架：Gson、Fastjson、Jackson
事件總線：EventBus、Otto
ORM框架：GreenDAO、Litepal
還有其他各種各樣開源的自定義控件、動畫等。除了以上提到的開源框架，也包括一些不開源的SDK
數據統計：友盟統計，百度統計...
奔潰搜集：騰訊bugly、bugtags...
云存儲：七牛...
即使通訊：環(huán)信、融云、阿里百川...
推送：小米推送、騰訊推送、百度推送...
安全加固：360加固寶、愛加密...
一般情況下，我在選擇是否引入一些開源框架主要基于以下幾個因素：
- 借助搜索引擎，如果網上有一大波資料，說明使用的人多，出了問題好找解決方案；當然，如果普遍出現差評，就可以直接Pass掉了
- 看框架的作者或團隊，如 JakeWharton大神、Facebook團隊等。大神和大公司出品的框架質量相對較高，可保證后續(xù)的維護和bug修復，不容易爛尾；
- 關注開源項目的 commit密度，issue的提交、回復、關閉數量，watch數，start數，fork數等。像那種個基本不怎么提交代碼、提issue又不怎么回復和修復的項目，最好就pass掉；
針對不開源SDK的選擇，也主要基于以下幾點去考慮：
- 借助搜索引擎，查明口碑；
- 很多第三方SDK的官網首頁都會告訴你，多少應用已經接入了此SDK，如果你看到有不少知名應用在上面，那這個SDK可以考慮嘗試一下了。諸如，友盟官網：
接入友盟的App
- 查看SDK使用文檔、它們的開發(fā)者社區(qū)、聯系客服。好的SDK，使用文檔肯定會詳細指引你。出了問題，上開發(fā)者社區(qū)提問，他們的開發(fā)工程師也會社區(qū)上回答。實在不行只能聯系客服，如果客服的態(tài)度都讓你不爽，那就可以考慮換別家的SDK了。
小結：選好 "車輪" ，事半功倍
3.抽象依賴第三方框架
為什么要抽象依賴于第三方框架呢？這里和第1點是互相照應的，就是降低我們對具體某個框架的依賴性，從而方便我們快速切換到不同的框架去。說到這里，你可能覺得很抽象，那我直接舉一個加載圖片的例子好了。
假設你當前為項目引入一個加載圖片的框架 —— Android-Universal-Image-Loader，最簡單的做法就是加入相應的依賴包后，在任何需要加載圖片的地方寫上下面這樣的代碼段。
ImageLoader imageLoader = ImageLoader.getInstance(); // Get singleton instance
// Load image, decode it to Bitmap and display Bitmap in ImageView (or any other view
// which implements ImageAware interface)
imageLoader.displayImage(imageUri, imageView);
// Load image, decode it to Bitmap and return Bitmap to callback
imageLoader.loadImage(imageUri, new SimpleImageLoadingListener() {
@Override
public void onLoadingComplete(String imageUri, View view, Bitmap loadedImage) {
// Do whatever you want with Bitmap
}
});
這種做法最簡單粗暴，但是帶來的問題也最嚴重的。如果我有幾十上百個地方都這么寫，而在某一天，我聽說Facebook出了個神器 Fresco，想要換掉 Android-Universal-Image-Loader ，你就會發(fā)現你需要喪心病狂的去改動幾十上百個地方的代碼，不僅工作量大，而且還容易出錯。造成這樣的原因，就在于項目和加載圖片的框架之間形成了強耦合，而實際上，項目本身不應該知道我具體用了哪個加載圖片的框架。
正確的方式，應該是對框架做一個抽象的封裝，以應對未來發(fā)生的變化，我直接舉自己的開源項目 AndroidAlbum 中的一種封裝做法好了。
AndroidAlbum
大致代碼如下：
//1、聲明 ImageLoaderWrapper 接口，定義一些抽象的加載接口方法
public interface ImageLoaderWrapper {
/**
* 顯示 圖片
*
* @param imageView 顯示圖片的ImageView
* @param imageFile 圖片文件
* @param option 顯示參數設置
*/
public void displayImage(ImageView imageView, File imageFile, DisplayOption option);
/**
* 顯示圖片
*
* @param imageView 顯示圖片的ImageView
* @param imageUrl 圖片資源的URL
* @param option 顯示參數設置
*/
public void displayImage(ImageView imageView, String imageUrl, DisplayOption option);
/**
* 圖片加載參數
*/
public static class DisplayOption {
/**
* 加載中的資源id
*/
public int loadingResId;
/**
* 加載失敗的資源id
*/
public int loadErrorResId;
}
}
// 2、將 UniversalAndroidImageLoader 封裝成繼承 ImageLoaderWrapper 接口的 UniversalAndroidImageLoader ，
//這里代碼有點長，感興趣可以查看項目源碼中的實現 https://github.com/D-clock/AndroidAlbum
// 3、做一個ImageLoaderFactory
public class ImageLoaderFactory {
private static ImageLoaderWrapper sInstance;
private ImageLoaderFactory() {
}
/**
* 獲取圖片加載器
*
* @return
*/
public static ImageLoaderWrapper getLoader() {
if (sInstance == null) {
synchronized (ImageLoaderFactory.class) {
if (sInstance == null) {
sInstance = new UniversalAndroidImageLoader();//<link>https://github.com/nostra13/Android-Universal-Image-Loader</link>
}
}
}
return sInstance;
}
}
//4、在所有需要加載圖片的地方作如下的調用
ImageLoaderWrapper loaderWrapper = ImageLoaderFactory.getLoader();
ImageLoaderWrapper.DisplayOption displayOption = new ImageLoaderWrapper.DisplayOption();
displayOption.loadingResId = R.mipmap.img_default;
displayOption.loadErrorResId = R.mipmap.img_error;
loaderWrapper.displayImage(imagview, url, displayOption);
這樣一來，切換框架所帶來的代價就會變得很小，這就是不直接依賴于框架所帶來的好處。當然，以上只是我比較簡單的封裝，你也可以進行更加細致的處理。
小結：預留變更，不強耦合于第三方框架
4.從 MVC 到 MVP
說實話，在沒接觸 MVP 的架構之前，一直都是使用 MVC 的模式進行開發(fā)。而隨著項目越來越大，Activity或者 Fragment里面代碼越來越臃腫，看的時候想吐，改的時候想屎...這里撇開其他各種各樣的架構不談，只對比MVC 和 MVP 。
MVC
- View：布局的xml文件
- Controller：Activity、Fragment、Dialog等
- Model:相關的業(yè)務操作處理數據（如對數據庫的操作、對網絡等的操作都應該在Model層里）
你會發(fā)現，如果 View 層只包含了xml文件，那我們 Android 項目中對 View 層可做操作的程度并不大，頂多就是用include復用一下布局。而 Activity 等簡直就是一個奇葩，它雖然歸屬于 Controller 層，但實際上也干著 View 層的活（View 的初始化和相關操作都是在Activity中）。就是這種既是 View 又是 Controller 的結構，違背了單一責任原則，也使得 Activity 等出現了上述的臃腫問題。
