再谈网络层框架设计

背景

随着公司业务的不断扩展，我们需要做的APP也越来越多，团队从几个人上升到了十几个人，维护五六个app，各端架构和框架使用的不一致，无形中增加了维护的成本，如果一个人一直负责一个项目还好，但这是不可能的，总会遇到江湖救急，哪端重要，资源就会偏向哪端，通过大家的讨论，准备从网络框架入手，做一个统一的示范，找到适合我们团队的统一方式。

封装的意义

我的观点，封装的核心意义是代码复用，减少样板代码，隐藏实现细节，让上层只关注业务逻辑，完善产品而不是想着完善技术。还有就是减少新成员的试错成本，有一个好且稳定的框架，可以让其稳定输出，无形中提高代码质量。封装可以做到一种特定领域的解决方案，更专注一种领域模型，可以做到极致。

封装的原则

首要原则要保证扩展性：为什么这么讲，举个例子，比如你在okhttp的基础上，加了很多便捷的实现，各个团队都做了集成，突然有一天一个端的朋友说，我要加一个功能，需要断点续传，而你没有留入口提供扩展，你说等两天，开发完了再通知你，你有没有发现一个矛盾点，如果一个人来找你需要等两天，如果团队一百人呢，很可怕的，所有你不光要封装起来，还要做好扩展的准备，哪怕不来找你，也可以通过扩展实现，再说了，如果这些功能都加框架上，有些团队说我们不需要这个功能，为啥要加给我，还要占我们包的大小，毕竟C端产品包体大小又是一个很高的衡量标准。

接口原则：在保证框架不被改变原有功能的情况下，提供接口替换功能，这就是所谓的依赖接口，而不依赖实现。这里强调不是所有功能都要暴露出来，而是在不影响框架本身行为的情况下。

不要为上层做过多的假设：这是我们讨论这么多次，对我感触最深的一点，这是一种吃力不讨好的做法，把应用需要做的事情，全揽过来自己做，但又不能满足应用的所有场景，图个啥？倒不如给个接口，你自己来吧，我有默认实现，想用就用，不用就自己实现对吧。

轻量级：说白了就是说，一定不要把框架封装的太重，我只需要一棵树，你给我一片森林，保持轻量，按需所取。

弱侵入性：就是减少对你的依赖，能在一处依赖就ok的时候，绝不能说，我需要用的时候就要对你有一次依赖，如果我想换掉怎么办，疯了吧，改那么多地方，在这一点大家都做过一件事就是，自己实现一个类专门去调你的，比如日志的包装类，为啥要有，不就是为了后期换了日志框架轻而易举，改一个类OK了。

封装实践

经历多次的讨论，我们定出了以下方案，架构图：

架构图

最上层是我们的业务APP，中间层可有可无，有是为什么？为了兼容原有的业务代码，让其以最小的改动，将Retrofit和okhttp的依赖直接下沉到框架层的内部。降低侵入性。
JLRetrofit是对Retrofit的扩展，我们更倾向去重写一个，因为我们用的其实也就几个依赖注入，比如@POST。这样也更便于跟okhttp的包装结合。
okhttp封装功能规划：

功能就不一一介绍了，一看就明白。

总结

再统一的道路上坎坎坷坷，有很多的技术观点的碰撞，但我们每个人都在成长。