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

[aboutboy]

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

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

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

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

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

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

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

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

[qbmiller]

是游戏吗？ 40-50m.
长连接 （ mqtt 那种也行）|| oss

[superedlimited]

hoge ？

[onichandame]

@horizon #29 没访问到的页面的配置项就不需要拉了呀。不过我倒是先入为主地觉得独立的配置项来自不同的独立接口，如果真是一个通用接口调一千次那确实后端有问题

[aduangduang]

@aduangduang 每次 APP 新版本打包的时候可以把当前的配置项一起打包，这样首次启动也不需要大量请求了
可以统一使用增量同步的逻辑

[ShuWei]

你确定这些东西能叫配置项？

[fov6363]

一个类似的解决办法，加一个 BFF 层，将所有接口汇总为两个接口：
1 、/api/config/update
2 、/api/config/list

app 在打包时，自动从 /api/config/list 拉到最新的全量的配置，并返回一个 hashId 来标识这次结果，这样用户打开 app 所有功能都是可用的。

然后 app 定期轮询 /api/config/update?id=$hashId ，如果有变更，就返回 true ，然后 app 端异步更新 diff 数据（复杂点就设计一套 add 、update 、delete 的语法，简单点就全量再拉一遍），如果无变更，就返回 false 。

这样针对相同的 hashId 还可以做 cache ，对后端的压力比较小

[wxf666]

能不能像聊天记录一样，只拉取有更新却没下载过的？

简单做法：配置项放数据库里，标记创建/更新时间。

客户端开启时，拉取 [上次开机时间，现在] 范围内的新配置项？

[henix]

展示加载进度条

[wOuv7i4e7XxsSOR1]

什么样的配置会有 40-50M? 你知道 40M 存文本可以存多少吗？

[xmumiffy]

就算 5000 个吧，50m 每个配置 10k ？
如果有压缩的话，每个配置原始有上百 k 了？那不能说后端没努力了，你们这一个配置就比别人整个配置大了

[Tink]

重构

[hwb]

好想见识一下这个 app

[ruobingm]

我比较想看 到底这上千个配置 都配置了啥？需要在首页获取?
很想知道。。

[fffq]

能跑吗

[3IOhG7M0knRu5UlC]

这配置不得有几千万字了

[MozzieW]

最简单的，加上一个缓存，时间戳没变就不要更新了，1000 个配置频繁变的也没有几个。

还是正在开发的，这个 App 没有人用，放弃吧

[joyoyao]

这玩意交给后端处理不就行了，app 只需要请求后端接口，那些需要展示，接口就返回，不需要展示接口就不返回。垃圾后端，自己不想搞，就恶心前端，交给前端搞。

[burymme11]

oss+cnd 指标不治本、
好好整理下这些配置吧，几千个配置竟然要 40.50M ??
你们不会把用户个人数据全部塞在配置里了吧？

[Mephisto233]

看这需求怎么感觉有点像是马甲包？先用正常 app 过审核，上线后通过配置项直接改界面？

[vipfts]

@Mephisto233 哈哈, 变身🥵