加载中…我的 Android 开发实战经验总结
(2016-03-28 09:37:53) 我的 Android 开发实战经验总结
文/D_clock （简书）
本文系作者授权“清南”发布
以前一直想写一篇总结 Android 开发经验的文章，估计当时的我还达不到某种水平，所以思路跟不上，下笔又捉襟见肘。近日，思路较为明朗，于是重新操起键盘开始码字一番。先声明一下哈，本人不是大厂的程序猿。去年毕业前，就一直在当前创业小团队从事自己热爱的打码事业至今。下面总结是建立在我当前的技术水平和认知上写的，如有不同看法欢迎留下评论互相交流。
1.理解抽象，封装变化
目前 Android 平台上绝大部分开发都是用着 Java ，而跟 Java
这样一门面向对象的语言打交道，不免要触碰到
//Activity间使用 Intent 传递数据的两种写法 下面均是伪代码形式，请忽略一些细节//写法一//SrcActivity 传递数据给 DestActivityIntent intent = new Intent(this,DestActivity.class);
intent.putExtra("param","clock");
SrcActivity.startActivity(intent);//DestActivity获取 SrcActivity 传递过来的数据String param = getIntent.getStringExtra("param");//写法二//SrcActivity 传递数据给 DestActivityIntent intent = new Intent(this,DestActivity.class);
intent.putExtra(DestActivity.EXTRA_PARAM,"clock");
SrcActivity.startActivity(intent);//DestActivity获取 SrcActivity 传递过来的数据public final static String EXTRA_PARAM = "param";
Stringparam = getIntent.getStringExtra(EXTRA_PARAM);
写法一，存在的问题是，如果 SrcActivity 和 DestActivity 哪个把 "param" 打错成 "para" 或者 "paran" ，传递的数据都无法成功接收到。而写法二则不会出现此类问题，因为两个 Activity 之间传递数据只需要知道 EXTRA_PARAM 变量即可，至于 EXTRA_PARAM 变量到底是 "param" 、 "para" 、"paran" 这一点并不需要关心，这就是一种对可能发生变化的地方进行抽象封装的体现，它所带来的好处就是降低手抖出错的概率，同时方便我们进行修改。
基于抽象和封装，Java 本身很多 API 在设计上就有这样的体现，如 Collections 中的很多排序方法：
http://upload-images.jianshu.io/upload_images/912181-43d91c09b0cf8c8c.jpg?imageMogr2/auto-orient/stripAndroid
Collections中的排序API
这些方法都是基于 List 这个抽象的列表接口进行排序，至于这是一个用什么样的数据结构实现 List（ArrayList 还是 LinkedList），排序方法本身并不关心。看，是不是体现了 JDK 的设计人员的一种抽象编程的思维，因为 List 的具体实现可能有千万种，如果每一类 List 都要写一套排序方法，估计要哭瞎了。
小结：把容易出现变化的部分进行抽象，就是对变化的一种封装。
2.选好"车轮"
一个项目的开发，我们不可能一切从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...
云存储：七牛...
即使通讯：环信、融云、阿里百川...
推送：小米推送、腾讯推送、百度推送...
安全加固：360加固宝、爱加密...
一般情况下，我在选择是否引入一些开源框架主要基于以下几个因素：
-
借助搜索引擎，如果网上有一大波资料，说明使用的人多，出了问题好找解决方案；当然，如果普遍出现差评，就可以直接Pass掉了
-
看框架的作者或团队，如
JakeWharton大神、Facebook团队等。大神和大公司出品的框架质量相对较高，可保证后续的维护和bug修复，不容易烂尾； -
关注开源项目的 commit密度，issue的提交、回复、关闭数量，watch数，start数，fork数等。像那种个基本不怎么提交代码、提issue又不怎么回复和修复的项目，最好就pass掉；
针对不开源SDK的选择，也主要基于以下几点去考虑：
-
借助搜索引擎，查明口碑；
-
很多第三方SDK的官网首页都会告诉你，多少应用已经接入了此SDK，如果你看到有不少知名应用在上面，那这个SDK可以考虑尝试一下了。诸如，友盟官网：
http://upload-images.jianshu.io/upload_images/912181-982d790a074e1669.jpg?imageMogr2/auto-orient/stripAndroid
接入友盟的App
-
查看SDK使用文档、它们的开发者社区、联系客服。好的SDK，使用文档肯定会详细指引你。出了问题，上开发者社区提问，他们的开发工程师也会社区上回答。实在不行只能联系客服，如果客服的态度都让你不爽，那就可以考虑换别家的SDK了。
小结：选好 "车轮" ，事半功倍
3.抽象依赖第三方框架
为什么要抽象依赖于第三方框架呢？这里和第1点是互相照应的，就是降低我们对具体某个框架的依赖性，从而方便我们快速切换到不同的框架去。说到这里，你可能觉得很抽象，那我直接举一个加载图片的例子好了。
假设你当前为项目引入一个加载图片的框架 —— Android-Universal-Image-Loader，最简单的做法就是加入相应的依赖包后，在任何需要加载图片的地方写上下面这样的代码段。
ImageLoaderimageLoader = 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 callbackimageLoader.loadImage(imageUri, new SimpleImageLoadingListen er() { @Override
public void onLoadingComplete(String imageUri, View view, Bitmap loadedImage) { // Do whatever you want with Bitmap
}
});
这种做法最简单粗暴，但是带来的问题也最严重的。如果我有几十上百个地方都这么写，而在某一天，我听说Facebook出了个神器 Fresco，想要换掉 Android-Universal-Image-Loader ，你就会发现你需要丧心病狂的去改动几十上百个地方的代码，不仅工作量大，而且还容易出错。造成这样的原因，就在于项目和加载图片的框架之间形成了强耦合，而实际上，项目本身不应该知道我具体用了哪个加载图片的框架。
正确的方式，应该是对框架做一个抽象的封装，以应对未来发生的变化，我直接举自己的开源项目
http://upload-images.jianshu.io/upload_images/912181-13f53797171d0be8.jpg?imageMogr2/auto-orient/stripAndroid
AndroidAlbum
大致代码如下：
//1、声明ImageLoaderWrapper 接口，定义一些抽象的加载接口方法public interface ImageLoaderWrapper {
public void displayImage(ImageView imageView, File imageFile, DisplayOption option);
public void displayImage(ImageView imageView, String imageUrl, DisplayOption option);
public static class DisplayOption {
public int loadingResId;
public int loadErrorResId;
}
}//2、将 UniversalAndroidImageLoa der 封装成继承 ImageLoaderWrapper 接口的 UniversalAndroidImageLoa der ，//这里代码有点长，感兴趣可以查看项目源码中的实现 https://github.com/D-clock/AndroidAlbum// 3、做一个ImageLoaderFactorypublic class ImageLoaderFactory { private static ImageLoaderWrapper sInstance; private ImageLoaderFactory() {
}
public static ImageLoaderWrapper getLoader() { if (sInstance == null) { synchronized (ImageLoaderFactory.class) { if (sInstance == null) {
sInstance = new UniversalAndroidImageLoa der();//https://github.com/nostra13/Android-Universal-Image-Loader
}
}
}