淘宝移动网络库全解析

本期不讲信令网络库设计模式，讲讲客户端静态资源下载网络库设计模式。

先定义一个类供业务方使用：

DownloadNetwork{
StartTask();//全局调用
StopTask();
};

资源由静态类管理，即GetInstance()；好处是可以控制初始化。

讲网络库之前先分享一下quic协议，也就是后面将要标准化的h3协议，目前由淘宝中台技术线喵吉主导落地手淘，现在业界移动端基本都在尝试。

因为quic是基于UDP的，而http2是基于TCP的，对于某些省份（通过埋点发现贵州联通在某些地方禁用UDP），这种场景下就涉及到选路了。

而对于服务层扔过来的任务，首先需要用一个profile（因为涉及到切线程，用智能指针shared_ptr管理，统一由task_manager线程管理其生命周期）。

资源对象设计

Task类需要包含Url、总超时时间、是否可重试等，还会包含一些extend参数，如http语义（Etag、Last-Modify等）。

Task{
HttpUrl url;
int timeout;
bool retry;
Extention ext;
}

任务的数据流向如下：

                           

manager线程管理的task哈希表参考了Java中ConcurrentHashMap的实现，也就是每个索引各自有一个spinlock小锁，不会锁整个表；求模运算选用质数101，可以尽量减少哈希冲突。

这里大概讲讲线程的设计。业务线程不介绍，主要为H5资源或者小程序资源的使用者；manager线程是网络库下载的管理线程，主要完成任务选路、http语义管理等；连接线程可以有多个，当前一个域名对应一个连接。有些程序员做下载设计的时候，会把http的一些异常返回码，如206等放到连接线程中和超时等异常逻辑一起处理，这种设计是低效的。总体而言连接线程只负责数据组装，http语义对于h2线程和quic线程都是一致的，要放到manager线程处理。

第一轮选路

第一轮选路会根据taskprofile携带的参数进行初筛，比如业务方会指定不走quic、不可重试等特性。profile对象包含一个选路标记，如果第一轮选路结果显示该任务还可以走quic和http2，那么就根据网络历史记录再筛选一次。

第二轮选路

选路流程会读取网络历史记录，选路类设计如下：

JsonDao{
//设计为单例模式，只有一个实例操作持久化文件
static JsonDao* Instance()；
QueryRecord();
SaveRecord();
}

对外提供查询和存储两个接口，查询和存储都是先操作缓存cache，未命中再操作磁盘disk，同时更新cache。这里在读取历史记录时使用的json开源库，如cJSON_Parse等接口会在内部申请内存资源，为了写代码时JsonDao接口内部出现重复性的资源释放代码，利用RAII机制设计了Tailup类，用Tailup封装使用的内存资源，在析构函数中自动释放资源，防止内存泄露。

根据手淘灰度埋点结果发现，增加网络历史记录之后对小资源的1s成功率提升极大。因为部分机型/运营商对UDP不支持，当quic任务失败时会进行4小时的抑制，直到超时或者切换到新网络环境再进行网络试探。

另外还有一些设计点，比如是否需要在app初始化时预建连，任务空闲时是否需要保留两个常驻线程（目前设计为20s）等，都需要根据业务迭代AB实验之后根据埋点得到的更优结果再决定。

一般资源下载都会设计断点续传，但是具体如何实现各家有各家的玩法，具体可以参考之前的文章：文件下载的断点续传是如何实现的？TCP的基础特性有哪些？

静态资源下载与平时接触较多的信令网络库还是有区别的，但是可以相互借鉴。如微信开源的mars网络库，里面的动态超时、总超时、阶梯超时设计就很好，比如业务方设计的超时时间为10s，重试次数为3次，如果第二次重试已经耗费了9s，那么就不需要触发第三次任务了，直接返回超时即可。如果第三次重试已经耗时10s，但是资源下载已经超过90%，那么可以再增加2个rtt的时间，而不是直接结束任务。