多网络库组件化sdk

背景

个人一直在从事某国际娱乐App的网络优化事项，最初的网络接口的形态相对比较涣散，为了能够更高效、稳定的进行网络优化，我们提出将App的网络进行组件化。经过进一步的讨论，我们提出了以下3个方面：

• 保持业务上层的使用不变，避免大面积的业务逻辑变动，从而给业务同学带来额外的使用成本
• 组件化抹平多网络库的上层稳定Api，提供稳定、可扩展的上层Api
• 在组件化中提供网络优化能力下沉，将网络优化能力在网络组件中进行

优化前后的网络形态对比

没有优化时的网络形态

• 基本上都是直接去实现对应模块的网络数据
• 通用一些的就是使用已经封装好的utils来支撑
• 各个模块非常的零散，这给优化也带来的挑战

优化后的大概层次结构

• 上层使用统一的Api
• 网络组件中支持众多的扩展，更好的支撑来业务的可变性
• 网络组件中抹平了不同网络库之间的差异，提供了口径统一的监控体系
• 组件化网络中提供了Gson、Json、PB、文件下载（支持续传）、重试、网络库、域名的调度能力，能够进一步的提高容错能力

目前状态

目前网络组件已经非常稳定，支撑了目前短链的所有请求。将使用和优化进行分离，业务同学不需要关系当前情况，而只需要简单的了解Api的使用，提高的业务开发对网络的复杂度。

组件化网络库的架构设计

我们先看看网络请求的流程结构图：

• 网络请求流程大体分为以上的流程，该流程不涉及具体的网络库中的处理细节，这里注重的是网络组件化的处理（面向业务）

大致架构的结构图

• 网络组件化主要是面向业务，提供可扩展的业务能力，同时能够在组件化内完成网络优化细节