校导网程家兴 | 漫谈Android技术方案的选择

安卓的出现也有好多年了，各种开源类库层出不穷，这也得益于安卓本身是一个开源的系统，方便程序猿们进行再次编译，做二次开发，当然也方便其快速地传播。

正因为如此，当开发者在进行技术选择的时候，时常会感到眼花缭乱。比比皆是的参考，然而开源的作者功力往往参差不齐。笔者以自已多年的经验，以及相关资料的参考，现在对各种技术作一个简单的分析与对比，希望对一些人有帮助。

1.图片加载

图片加载(Universal-Image-Loader，Picasso、Fresco和Glide)

Android不同设备单个进程可用内存是不一样的，可以查看/system/build.prop文件：

# This is a high density device with more memory, so larger vm heaps for it.dalvik.vm.heapsize=24m

上面heapsize参数表示单个进程可用的最大内存，但如果存在如下参数：

dalvik.vm.heapgrowthlimit=16m

largeheaplimit参数表示单个进程内存被限定在16m，即程序运行过程中实际只能使用16m内存。

由此可见，安卓手机端每个应用的运行内存是极其有限，而图片从文件加载成Bitmap在内存中并显示出来，这个过程当中开辟的内存是相当巨大的，稍有不慎，就会引发OOM (OutOfMemory)，所以成熟的图片加载库是一个应用的基础。

（1）Picasso有如下特性：

自动添加磁盘和内存缓存，支持对图片作一些具体的操作。比如：加载圆角矩形图片、裁剪图片为圆形。

缺点：就是这个库我们只能看到结果，无法关心图片的下载过程。

（2）Universal-ImageLoader

这个库有着对加载网络图片的详细配置。可以根据个人的喜好，进行一些配置等等。并且可以实现图片下载过程的监听。且可以支持图片下载完成后，显示圆形或者圆角矩形的图片。

（3）Fresco

Fresco是Facebook推出的一款用于Android应用中展示图片的强大图片库，它能够从网络、本地存储和本地资源中加载图片。而且，为了节省数据和CPU，它拥有三级缓存。

Fresco 是一个强大的图片加载组件，支持加载Gif图，支持WebP格式，目前为止最为强大，与此同时它的包文件也是最大。

（4）Glide

Glide的主要目的有两个，一个是实现平滑的图片列表滚动效果；另一个是支持远程图片的获取、大小调整和展示，支持Gif 动画。

2.网络数据请求

网络数据请求（okhttp,retrofit,android-async-http,volley）

okhttp是高性能的http库，支持同步、异步，而且实现了spdy、http2、websocket协议，api很简洁易用，和volley一样实现了http协议的缓存。

retrofit是在okhttp基础之上做的封装，项目中可以直接来用，与此同时它支持系统默认的httpUrlConnection，它是可以通过RestAdapter.Builder来灵活配置的。okhttp和retrofit由square团队开发。

android-async-http。与volley一样是异步网络库，但volley是封装的httpUrlConnection，它是封装的httpClient，而Android平台不推荐用httpclient了，而且其回调的json数据的解析要在UI线程中执行，故不推荐。

volley是一个简单的异步http库，仅此而已。缺点是不支持同步，这点会限制开发模式；不能post大数据，所以不适合用来上传文件。

个人认为retrofit是最佳选择，接口RESTful风格，对于http协议GET, POST, PUT, DELETE, 和 HEAD全部支持，而且retrofit和rxjava可以结合使用，可以让多个REST调用组合变得更简单。

3.AsyncTask 与rxjava

AsyncTask是在Android里面默认的处理工具，开发者可以在里面做一些长时间的处理工作，而不会阻塞用户界面。

表面上，这似乎很简单，你定义一些代码在后台线程中运行，然后定义一些代码运行在UI线程中，在后台任务处理完之后，它在UI线程会处理从后台任务传递过来的执行结果。

使用AsyncTask的最大的问题是在细节的处理上，让我们谈谈这个问题。

（1）错误处理

这种简单用法的第一个问题就是：如果出现了错误怎么办？

不幸的是，暂时没有非常好的解决方案。所以很多的开发者最终要继承AsyncTask，然后在doInBackground()中包裹一个try/catch，返回一个，然后根据发生的情况，分发到新定义的例如onSuccess()或者onError(),随着时间的推移，这些结果可能不会保持很好的一致性和可预见性。

（2）Activity和Fragment的生命周期

当AsyncTask正在运行的时候，如果我退出Activity或者是旋转设备的话会发生什么？

嗯，如果你只是发送一些数据，之后就不再关心发送结果，那可能是没有问题的。但是如果你需要根据Task的返回结果更新UI呢？如果你不做一些事情阻止的话，那么当你试图去调用Activity或者是View的话，将会得到空指针异常导致程序崩溃，因为他们现在是不可见或者是null的。

同样，在这个问题上AsyncTask没有做很多工作去帮助你。作为一个开发者，你需要保持一个Task的引用，并且要么当Activity正在被销毁的时候取消Task，要么当你试图在onPostExecute()里面更新UI的时候，确保Activity是在一个可达状态。当你只想明确地做一些工作，并且让项目容易维护的时候，这将会继续提高维护项目的难度。

除此之外rxjava相较AsyncTask ，支持多个复杂请求的组合调用，测试代码更加的干净整洁。

4.MVP与非MVP

（1）Android MVP开发模式的概念

Android的MVP是由MVC优化衍生出来的一种模式，MVP将MVC中的Controller层进行了优化而生成了Presenter。Presenter层和MVC的Controller一样，负责核心逻辑，但不一样的是Presenter通过接口协议进行数据传递，并阻断了View和Model的直接联系，从而使View和Model更加专注于自身业务逻辑。

● View

View通常来说就是由Activity、Fragment实现的，View会包含一个或多个Presenter的引用来满足视图的业务逻辑。View和Presenter的交互是双向的，即View层可以调用Presenter的逻辑方法，Presenter也可以控制View的显示。

● Presenter

Presenter作为Model和View的桥梁，负责从Model拿到数据进行处理并返回给View。但Presenter和其他两层的沟通是通过接口协议进行的，所以每个Presenter中通常会包涵一个或多个接口协议。

● Model

和MVC一样，作为数据仓库只负责对APP数据进行处理。

（2）Android MVP开发模式的优点

● View和Model之间的耦合度降低，使其更关注自身业务逻辑，结构清晰，维护方便；

● 便于单元测试；

● 代码复用率提高。

（3）MVP开发模式的缺点

主要表现在每个View都有Presenter ，类相对比较多，代码复杂度和学习成本高，在某些场景下Presenter的复用会产生接口冗余。

每个系统应当根据自已的业务情况，选择合适的方案，才能更好的适应自已。

作者简介：程家兴，英文名Tonyee，现任校导网Android开发工程师，曾任多家公司技术部组长，熟悉服务端与移动端技术，拥有6年开发经验。