Expo Updates 自定义更新服务器

引言

先说EAS。EAS就是Expo Application Service，它提供了打包、发布热更新、提交应用商店等软件服务。
为什么要用它呢？为什么不用code-push或者pushy呢？答案很简单，首先他与Expo兼容性高，你在使用打包或者上传tf的时候，顺便就能发布热更新了，不需要再用其他工具链，其次它免费，当然前提是跟着这篇文章，自己搭建热更新服务器。

搭建更新服务器

众所周知，热更新本质上就是动态替换JS Bundle。那么首先我们需要一个地方存储这些JS Bundle，还需要一个索引，用于根据版本号和其他信息，查找对应的包。

EAS实现热更新流程

sequenceDiagram
    participant 客户端
    participant 服务端
    客户端->>服务端: 携带当前版本信息，询问有无更新版本
    服务端-->>客户端: （如有）返回更新包信息，其中包含下载地址
    客户端->>服务端: 下载更新包
    服务端-->>客户端: 返回更新包
    客户端->>客户端: 安装更新

可以看到，本质上客户端到服务端其实就两次通信，对应两个接口，第一次问服务端要最新版本的信息，第二次根据第一次返回的结果，去下载更新包，最后应用JS Bundle即可。
对于客户端而言，只需要在app.json中配置updates.url和runtimeVersion即可，前者指定热更新服务器的地址，后者表示当前应用程序的版本号。详见官方文档。

实现接口

查询版本更新信息

updates.url虽然是我们手动指定的，但是实际调用是Expo Updates包在执行，它在调用这个URL的时候会携带客户端的基础信息，比如版本号，平台等。

假设我们指定了URL为：https://www.example.com/api/manifest，Expo Updates会在请求头和URL Query中携带基本信息：

• 获取当前客户端的版本号，从header的expo-runtime-version字段或者URL Query的runtime-version字段。
• 获取当前客户端的平台，从header的expo-platform字段或者URL Query的platform字段。热更新通常来说只支持安卓和iOS。

以上是两个必要字段，版本号用于确定有没有新版本，平台用于区分不同平台的包，通常来说热更新跟平台也没关系，两个平台一般都是一起热更新的，所以判断版本号就够了。

流程走完后，服务端按照格式返回新版本信息。如果没有或者HTTP状态码不正确，则代表没有更新版本。按照这个JSON格式：

export type ExpoUpdatesManifest = {
  id: string; /// 此次更新的唯一ID，可以根据SHA256生成
  createdAt: string;
  runtimeVersion: string; /// 此次更新的版本号
  launchAsset: ManifestAsset; /// 下载地址
  assets: ManifestAsset[];
  metadata: object;
  extra?: ManifestExtra;
};

export type ManifestAsset = {
  url: string;
};

未完待续…