Android网络：封装自用网络层的心得体会

最近okHttp比较流行，尤其是在retrofit出来后。本来想写一篇分析okhttp源码的文章，但是貌似已经有很多前辈写过了，我就不献丑了。由于我们公司一直处于多app并行开发的状态，所以组件的复用变得很有意义。于是对okhttp进行了统一封装（由于架构和习惯，最终没有决定采用retrofit），整个过程还是很有意思的，分享一些感悟和心得。

1.封装目的：

封装目的一定要明确，不然没有意义，最后也可能会使封装的网络层变得越来越厚重，加入一些其实大家都用不到功能。例如我们这次封装主要目的是为了两点：解耦和代码复用。

2.基本原则

如果一个app的代码以代码的通用性作为维度，分成以下几个部分的话：底层功能；底层功能api；封装解耦层；通用业务逻辑；个性业务逻辑；UI。那么要封装的部分主要在封装解耦层和通用业务逻辑这部分。

结合上文提到的封装目的，首先，使用者不需要关心底层使用的是okhttp还是xutils还是loopj之类的底层，向上提供统一的调用api，其次是通过接口，使用者也可以自己实现底层的网络请求功能。再者，就是将各个android app的通用方法和公共部分封装进来，减少代码重复和精炼逻辑，这包括：多线程多网络请求下ui显示的回调处理，针对服务端的加密，DNS域名解析防劫持，构造请求，针对具体通信协议的对象mapping等等。

关于逻辑的收放，那些应该做统一封装，那些不应该，应该和大家统一商量。我觉得没必要拘泥于一定要层次分明，既然是团队内部用，没有开源的打算，就可以加入一些通用业务。当然可以在中间使用一些接口，为扩展留出空间。

关于一些模棱两可的问题，需要与团队成员多商量，听取大家的意见吧。。。

3.注意事项

一个要供大家使用的依赖网络层的开发体验，与普通app的开发体验还是非常不一样的：

a.文档和注释非常重要。

一定要善用文档注释，和javadoc的各类标签，这会非常有助于大家阅读代码，快速上手和了解使用，比较常用的：{@link ...}或者{@linkplain ...}，再比如{@code ...}和@see等等，用法大家可以去搜索一下。

b.注重代码的质量

这个不必多说吧，反正我在开发的过程中出的问题比想象中稍微多了那么一些呵呵。可以结合findbugs提高代码质量，这个后边再谈。

c.注重代码结构

多运用refactor，把逻辑清晰地拆分开，不要写冗长的方法，不要写回旋镖一样的if语句。

d.三思而后行

这地方我也犯了一些错误：大的框架一旦确定，开始启用框架后，再改就比较麻烦了，一不小心就会招致非议，费力不讨好。

4.具体实践

大致结构如下：

上面这个图有点乱哈，主要是为了看清都有哪些类。

（未完待续）