app 初始化时需要通过接口获取上千个独立的配置项，如何优化？

[aboutboy]

正在开发一个 app ，用户在使用 app 访问服务时，需要根据对应的服务从后端获取对应的配置文件（ json 格式）。

一共有上千个独立的配置项。

目前是当 app 第一次启动时，会首先通过接口查询配置项清单，然后再依次对各配置项进行请求获取。

这样的问题是，一个 app 就会向后端发起上千个请求。而且可能需要十来分钟甚至更长时间才能把全部配置拉下来。

这样一方面对后端服务器造成压力，另一方面影响用户体验。

如果把配置全部打包在一起的话，大概40-50MB左右。

有些配置项还会更新，这就需要app 在后续的运行过程中对有更新的配置项进行更新。

请问大佬们有什么好的思路？

[icyalala]

给你们看看现实中几十 MB 配置项的例子：
这是 FGO 手游每次启动下载的 JSON 配置数据，80M+，现在更大了所以不用 JSON 了
https://github.com/UnderFGO/MasterDataDumper/releases

[28Sv0ngQfIE7Yloe]

@icyalala #81 这种一般是放在 OSS 获取吧

[FireKey]

应用的话配置 copy 一份存本地,配置版本变化时再更新对应项.如果运行中需要及时更新,考虑将配置版本加入 headers 中,版本更新了接口走更新流程

[panlatent]

纯色背景配上点大字：


”嗨，别来无恙“
”一切即将准备就绪“
”这可能需要几分钟“
”马上就好“

[ysw]

json 放 cdn ，然后按需加载，应该就差不多了

[icyalala]

@Morii 这个配置数据变动还没那么频繁可以放静态，但用户数据游戏进度就不行了，那个同样也不小。
如果不换架构的话，最简单的办法就是换格式，用 protobuf/msgpack 再压缩一下，客户端选个高性能的解析库，这个量级基本还是够用的。

[2owe]

按需缓存吧，首先获取一下当前需要更新的配置，只获取有更新的部分

[veightz]

问题还挺多， 不是单方面的。整体方案就挺奇怪的，感觉没有沟通好设计。。

客户端的问题：
1. 用户体验问题肯定要客户端解决。不可能同步等这份配置吧，这个数据量的下载，反序列化，都是不小的开销。一般来说是同步读客户端缓存，异步刷新数据。
2. 配置同步做下版本管理， 记录下版本的上一次同步时间。 做好缓存时间控制。

服务端问题：
1. 上千个配置下是同构的吧？ 一个读结构不同的配置项 key 吧？ 要支持批量的接口。
2. 服务端都做热缓存吧， 有内存缓存的话， 我觉得性能本身倒是还好。 但是目前方案我觉得你们的第一个瓶颈是带宽。
3. 我觉得可以的方式是读 cdn ， 配置大概率也不是高频更新的，可以结合 etag 等手段， 确定有数据变更了再回拉。

[xiangyuecn]

能用上你们的 app 的客户也是倒了八辈子霉🐶

[Ritr]

什么 APP ，说出来我避雷

[shunia]

游戏不就是这样的吗？
一万个配置文件也可以做一个更新列表，有更新的才拉，没更新的用缓存。
基本只有冷启动会全量下载，热启动基本很难遇到大量更新的情况。

[simo]

如果你说的 50M 的配置必须所有人都加载，那就分析下，拆分请求，按需，数据压缩，缓存，cdn 。

[murmurkerman]

这个明显要用增量更新，可以看看有没有类似于 remote config 的国内替代。没有的话只能自己撸一个。也可以借助 s3 ，oss 实现，s3 文件下载都会返回一个文件内容的 hash 值，可以用 head 请求判断是否更新了。然后就是拉配置的时候需要有一个请求队列，安卓 okhttp 自带，不用担心网络并发。

配置下载也可以加一个分页接口，一次下载 n 项。
最好还是用 protobuff 缩小配置文件传输大小。

[caqiko]

@panlatent #84 请坐和放宽，海内存知己，天涯若比邻

[prosgtsr]

放在一个接口全部请求回来。
还可以带上版本号，每次通过版本号获取更新的数据。
我们公司的 app 就是这么干的，没什么问题。

[jzphx]

启动一次 app 40-50M ，用户流量不要钱的吗

[duanxianze]

不明白，什么样的应用会有这种需求？

[ArianX]

上千个配置为什么会有 40M

[Huelse]

区分启动配置和分页配置，另外很多配置都是应该存本地的，更改时发送一份到服务端记录就行了，不需要再次下载。

[p1gd0g]

配置不放 cdn 上？不做缓存？没有增量更新？