07-性能优化-网络

React-Native 内部集成了 OkHttp 作为网络底层实现，上层直接调用 fetch api 即可发起网络调用。 除非你对网络有特殊要求，否则现有的环境应该是足以满足需要的。

但是一般而言，国内大厂都有自己内部的整套网络工具，实现了流量统计、异常监控、网络性能调优等操作，不会直接使用未经任何改造的原始的 Okhttp。

所以在真实环境下，网络能力都需要和公司整体 IT 环境保持统一。那么这里主要需要做的就是把 react-native 的网络访问能力替换掉。

Step1

方案一

简单点的方案， 废弃掉 fetch api。重新实现一套自己的 fetch，native 层也通过 NativeModule 向 React-Native 暴露 api 和自己的 fetch 进行对接。

这个方案实现成本很低，也比较易于维护。但是对成员要求性相对较高，团队成员人少的时候比较适用，而且作用域仅限于团队内维护的模块，第三方模块涉及到的网络访问没有办法控制。

方案二

从底层替换掉 React-Native 内的网络模块。

查阅 React-Native 的源码很容易发现，自定义的 NativeModule 和原生的 NativeModule 都是一样的，所以我们可以把原生的 NetworkingModule 内的实现替换掉，让它不依赖 Okhttp 库，而是公司内部的网络库。

具体如何替换需要看各家内的网络库 api 如何设计，这里就不做多讲解，而且 NetworkingModule 的实现也很简单，稍微阅读一下就能理清其中的脉络。

这个方案对上层隔离，而且可以作用于全局，是比较理想的方案。但是会有个问题，因为涉及到 React-Native 源码的修改，所以需要自行 fork 一份源码单独维护，成本比较高。这种类似的点还有很多，也是各家在实践 React-Native 都需要锁定版本的原因之一。只能期望未来 facebook 把这块机制设计的更灵活一些了。

Step2

调用网络能力基础的 API 是 Fetch， 但是直接使用 fetch 也是一件很麻烦的事情。 这里基于 fetch 做了一个简单的 rpc-client 包装, 主要特点：

1. 简化 get、post 调用。 其他方法暂未扩展
2. 支持 rpc 状态检查，取消、超时操作
3. 支持特定的几种 content-type 类型，并可方便扩展