心得：android开发网络层

前言：习惯多问一句为什么。因为不管代码怎么写，总有这么写的缘由道理，明白了为什么，自然也知道了一些不容易发现的点、问题，这样 写代码也就有了目标，也容易理解记忆，这么写只是解决这种问题的一种方法。以后还可能接触到其他方法，有两个方法了，就会有比较，理解了两种方法的优缺点，我们对程序的理解就有了更进一步的认识。

这几天一直在处理关于网络请求的一些bug，总结了一些自己遇到的问题和想到的处理办法，分享并记录下来。

网络是一个客户端app非常重要的一部分，纵观一个app，除了展示（UI）就是数据，数据从哪来，大部分都是网络请求的，而且网络请求是非常普遍的，贯穿于我们整个app的代码。如果在一个项目中，能够根据自己的项目类型，封装出适合自己的网络层，让自己的代码看起来非常的简洁干净（通常网络请求都会有回调，然而在代码中掺杂很多回调是一件非常让人头疼的事儿，整个代码的通读性非常差，甚至影响心情），基本只是UI的显示，那真是极好的。

关于网络：

1、首先要定义网络使用什么框架，是使用Volley，还是thread+handler，还是AsyncTask，还是第三方的XUtils等等
2、其次根据自己做的项目的类型和需求，对网络层进行封装，并对网络层的机制和统一处理进行初步的定义与规划。比如请求超时时间， 请求失败后是否有重试机制，请求头的统一设置还有请求错误的接口定义与统一处理等等，就算当时定不下来，也应该保证代码的低耦合度，以后也方便统一处理。 比如对请求的success 和 failed的接口定义和意义，参数含义的定义。还有对错误的处理的定义，cancel的处理等等。

3、网络请求接口的实现与调用。我们应该从本质上清楚地知道，网络请求是干什么的。其实，网络请求就是 从数据库或者文件等等一些存储介质中里面 取数据(和用户状态有关的操作也是刷新数据的一种)。就像Android开发文档里面写的一样，数据的存储一般有以下几种方式，SharedPreference、SQLite、ContentProvider、assets raw等文件，还有就是网络。所以 我们应当尽量让网络请求和UI分离。

比如说我们需要某个数据，我们只需要调用某个方法就好了，这个方法通过网络请求就能返回我们想要的值。对不同的需求这里有两种比较好的实现，一种是面向实时刷新的数据，我们可以启动一个service，使用观察者模式，每一个要使用此数据的都要bindService，当service刷新到新的数据之后通知给与它绑定的观察者，若没有任何人bind则停止请求数据。另一种是我们普通的网络请求，问题的提出有两个原因，一是老总总说的网络请求与UI相分离，就是说我需要的时候我就发请求，有数据回来我就显示，没有就算了，并不一定需要通过Toast类似的告诉用户说我没有请求到，因为我可能同时请求好几个接口，若只是用户没有联网或者网络不好打开你的app后，老是Toast给用户Toast一些东西是非常影响用户体验的。二是我遇到的一个问题，就是有一个数据在第一层的 入口一 需要初始化，因为入口一的下一层都要用到此数据，但是呢，如果在进入入口一的时候网络出了点问题，这个数据没有请求回来，那么我下一层的所有东西全不能用了，因为上一层没有请求到数据，为了解决这种问题，而且又不至于请求数据好几遍，所以有了以下思路：每个Activity和Fragment都实现一个网络请求的回调接口，成功与否，然后在onCreate的时候需要什么数据就一句话调用，告诉网络说我需要这个数据就不用管了，之后在统一实现的回调中处理，就像onActivityResult一样，为了区分，我们也可以加上标记，这里可能不用code，用url就行。比如上面那个问题，我在第二层里面想用数据的时候我可以直接去第一层拿，发现第一层并没有数据，那么我就调一下接口，在回调中赋给上一层值，并使用。