Android网络请求心路历程

本文从入门级开始介绍Android网络请求的实践历程,涵盖HTTP请求与响应、同步与异步请求、缓存机制等内容,并深入探讨Volley、OkHttp、Retrofit等流行库的应用,以及网络图片加载优化方案。
摘要由CSDN通过智能技术生成
网络请求是android客户端很重要的部分。下面从入门级开始介绍下自己Android网络请求的实践历程。希望能给刚接触Android网络部分的朋友一些帮助。

本文包含:


Android网络请求心路历程

网络请求是android客户端很重要的部分。下面从入门级开始介绍下自己Android网络请求的实践历程。希望能给刚接触Android网络部分的朋友一些帮助。
本文包含:

HTTP请求&响应

既然说从入门级开始就说说Http请求包的结构。
一次请求就是向目标服务器发送一串文本。什么样的文本?有下面结构的文本。
HTTP请求包结构

请求包

例子:

POST /meme.php/home/user/login HTTP/1.1
    Host: 114.215.86.90
    Cache-Control: no-cache
    Postman-Token: bd243d6b-da03-902f-0a2c-8e9377f6f6ed
    Content-Type: application/x-www-form-urlencoded

    tel=13637829200&password=123456

请求了就会收到响应包(如果对面存在HTTP服务器)
HTTP响应包结构


响应包

例子:

HTTP/1.1 200 OK
    Date: Sat, 02 Jan 2016 13:20:55 GMT
    Server: Apache/2.4.6 (CentOS) PHP/5.6.14
    X-Powered-By: PHP/5.6.14
    Content-Length: 78
    Keep-Alive: timeout=5, max=100
    Connection: Keep-Alive
    Content-Type: application/json; charset=utf-8

    {"status":202,"info":"\u6b64\u7528\u6237\u4e0d\u5b58\u5728\uff01","data":null}

Android网络请求心路历程

网络请求是android客户端很重要的部分。下面从入门级开始介绍下自己Android网络请求的实践历程。希望能给刚接触Android网络部分的朋友一些帮助。
本文包含:

HTTP请求&响应

既然说从入门级开始就说说Http请求包的结构。
一次请求就是向目标服务器发送一串文本。什么样的文本?有下面结构的文本。
HTTP请求包结构

请求包

例子:

请求了就会收到响应包(如果对面存在HTTP服务器)
HTTP响应包结构

响应包

例子:

浏览器缓存机制

注意服务器返回304意思是数据没有变动滚去读缓存信息。
曾经年轻的我为自己写的网络请求框架添加完善了缓存机制,还沾沾自喜,直到有一天我看到了下面2个东西。(/TДT)/

Volley&OkHttp

Volley&OkHttp应该是现在最常用的网络请求库。用法也非常相似。都是用构造请求加入请求队列的方式管理网络请求。

先说Volley:
Volley可以通过 这个库进行依赖.

Volley在Android 2.3及以上版本,使用的是HttpURLConnection,而在Android 2.2及以下版本,使用的是HttpClient。
Volley的基本用法,网上资料无数,这里推荐郭神的博客

Volley存在一个缓存线程,一个网络请求线程池(默认4个线程)。
Volley这样直接用开发效率会比较低,我将我使用Volley时的各种技巧封装成了一个库RequestVolly.

我在这个库中将构造请求的方式封装为了函数式调用。维持一个全局的请求队列,拓展一些方便的API。

不过再怎么封装Volley在功能拓展性上始终无法与OkHttp相比。
Volley停止了更新,而OkHttp得到了官方的认可,并在不断优化。
因此我最终替换为了OkHttp

OkHttp用法见 这里很友好的API与详尽的文档。

这篇文章也写的很详细了。

OkHttp使用Okio进行数据传输。都是Square家的。

但并不是直接用OkHttp。Square公司还出了一个Retrofit库配合OkHttp战斗力翻倍。


Retrofit&RestAPI

Retrofit极大的简化了网络请求的操作,它应该说只是一个Rest API管理库,它是直接使用OKHttp进行网络请求并不影响你对OkHttp进行配置。毕竟都是 Square公司出品。

RestAPI是一种软件设计风格。
服务器作为资源存放地。客户端去请求GET,PUT, POST,DELETE资源。并且是无状态的,没有session的参与。
移动端与服务器交互最重要的就是API的设计。比如这是一个标准的登录接口。


你们应该看的出这个接口对应的请求包与响应包大概是什么样子吧。
请求方式,请求参数,响应数据,都很清晰。
使用Retrofit这些API可以直观的体现在代码中。


然后使用Retrofit提供给你的这个接口的实现类 就能直接进行网络请求获得结构数据。

注意Retrofit2.0相较1.9进行了大量不兼容更新。google上大部分教程都是基于1.9的 这里有个2.0的教程。

教程里进行异步请求是使用Call。Retrofit最强大的地方在于支持RxJava。就像我上图中返回的是一个Observable。RxJava上手难度比较高,但用过就再也离不开了。Retrofit+OkHttp+RxJava配合框架打出成吨的输出,这里不再多说。

网络请求学习到这里我觉得已经到顶了。。


网络图片加载优化

对于图片的传输,就像上面的登录接口的avatar字段,并不会直接把图片写在返回内容里,而是给一个图片的地址。需要时再去加载。

如果你直接用HttpURLConnection去取一张图片,你办得到,不过没优化就只是个BUG不断demo。绝对不能正式使用。
注意网络图片有些特点:

  1. 它永远不会变
    一个链接对应的图片一般永远不会变,所以当第一次加载了图片时,就应该予以永久缓存,以后就不再网络请求。
  2. 它很占内存
    一张图片小的几十k多的几M高清无码。尺寸也是64*64到2k图。你不能就这样直接显示到UI,甚至不能直接放进内存。
  3. 它要加载很久
    加载一张图片需要几百ms到几m。这期间的UI占位图功能也是必须考虑的。
说说我在上面提到的 RequestVolley里做的图片请求处理(没错我做了,这部分的代码可以去github里看源码)。

三级缓存

网上常说三级缓存--服务器,文件,内存。不过我觉得服务器不算是一级缓存,那就是数据源嘛。

  • 内存缓存
    首先内存缓存使用LruCache。LRU是Least Recently Used 近期最少使用算法,这里确定一个大小,当Map里对象大小总和大于这个大小时将使用频率最低的对象释放。我将内存大小限制为进程可用内存的1/8.
    内存缓存里读得到的数据就直接返回,读不到的向硬盘缓存要数据。
  • 硬盘缓存
    硬盘缓存使用DiskLruCache。这个类不在API中。得复制使用。看见LRU就明白了吧。我将硬盘缓存大小设置为100M。

@Override
  public void putBitmap(String url, Bitmap bitmap) {
      put(url, bitmap);
      //向内存Lru缓存存放数据时,主动放进硬盘缓存里
      try {
          Editor editor = mDiskLruCache.edit(hashKeyForDisk(url));
          bitmap.compress(Bitmap.CompressFormat.JPEG, 100, editor.newOutputStream(0));
          editor.commit();
      } catch (IOException e) {
          e.printStackTrace();
      }
  }

  //当内存Lru缓存中没有所需数据时,调用创造。
  @Override
  protected Bitmap create(String url) {
      //获取key
      String key = hashKeyForDisk(url);
      //从硬盘读取数据
      Bitmap bitmap = null;
      try {
          DiskLruCache.Snapshot snapShot = mDiskLruCache.get(key);
          if(snapShot!=null){
              bitmap = BitmapFactory.decodeStream(snapShot.getInputStream(0));
          }
      } catch (IOException e) {
          e.printStackTrace();
      }
      return bitmap;
  }

  • DiskLruCache的原理不再解释了(我还解决了它存在的一个BUG,向Log中添加的数据增删记录时,最后一条没有输出,导致最后一条缓存一直失效。)
  • 硬盘缓存也没有数据就返回空,然后就向服务器请求数据。

这就是整个流程。
但我这样的处理方案还是有很多局限。

  • 图片未经压缩处理直接存储使用
  • 文件操作在主线程
  • 没有完善的图片处理API

以前也觉得这样已经足够好直到我遇到下面俩。

Fresco&Glide

不用想也知道它们都做了非常完善的优化,重复造轮子的行为很蠢。

Fresco是Facebook公司的黑科技。光看功能介绍就看出非常强大。使用方法官方博客说的够详细了。
真三级缓存,变换后的BItmap(内存),变换前的原始图片(内存),硬盘缓存。
在内存管理上做到了极致。对于重度图片使用的APP应该是非常好的。
它一般是直接使用SimpleDraweeView来替换ImageView,呃~侵入性较强,依赖上它apk包直接大1M。代码量惊人。

所以我更喜欢Glide,作者是bumptech。这个库被广泛的运用在google的开源项目中,包括2014年google I/O大会上发布的官方app。

这里有详细介绍。直接使用ImageView即可,无需初始化,极简的API,丰富的拓展,链式调用都是我喜欢的。

丰富的拓展指的就是这个。另外我也用过Picasso。API与Glide简直一模一样,功能略少,且有半年未修复的BUG。

图片管理方案

再说说图片存储。不要存在自己服务器上面,徒增流量压力,还没有图片处理功能。
推荐七牛阿里云存储(没用过其它 π__π )。它们都有很重要的一项图片处理。在图片Url上加上参数来对图片进行一些处理再传输。
于是(七牛的处理代码)

public static String getSmallImage(String image){
        if (image==null)return null;
        if (isQiniuAddress(image)) image+="?imageView2/0/w/"+IMAGE_SIZE_SMALL;
        return image;
    }

    public static String getLargeImage(String image){
        if (image==null)return null;
        if (isQiniuAddress(image)) image+="?imageView2/0/w/"+IMAGE_SIZE_LARGE;
        return image;
    }

    public static String getSizeImage(String image,int width){
        if (image==null)return null;
        if (isQiniuAddress(image)) image+="?imageView2/0/w/"+width;
        return image;
    }

既可以加快请求速度,又能减少流量。再配合Fresco或Glide。完美的图片加载方案。
不过这就需要你把所有图片都存放在七牛或阿里云,这样也不错。

图片/文件上传也都是使用它们第三方存储,它们都有SDK与官方文档教你。
不过图片一定要压缩过后上传。上传1-2M大的高清照片没意义。




评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值