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

2024-09-02 10:33:02 +08:00
 aboutboy

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

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

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

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

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

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

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

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

11971 次点击
所在节点    程序员
106 条回复
ktqFDx9m2Bvfq3y4
2024-09-02 14:27:41 +08:00
低代码?
k9982874
2024-09-02 14:29:50 +08:00
建议废除后端,app 直读数据库
zxc880301
2024-09-02 14:30:36 +08:00
@fov6363 靠谱 我们就是这么做的
unco020511
2024-09-02 14:37:56 +08:00
可以参考 firebase 的 remoteConfig 产品
https://firebase.google.com/docs/remote-config

几个关键点:
1. 有本地默认配置文件,用于各种情况下的兜底配置
2. 配置有分组,支持分组更新/获取
3. 有版本号机制,支持增量更新,绝大部分情况都应该是增量差异更新
4. 可选长链接,实现 real-time 更新机制
5. 扩展可与各种其他产品结合,比如与你的业务 api 网关结合,在 header 中携带客户端配置的版本号,网关中去拦截,如果线上有版本号更新,则触发配置更新,配置更新在客户端可以独立进程,做到业务无感
unco020511
2024-09-02 14:41:35 +08:00
最关键的,就是动态配置是需要定期去固化清理的,比如一段时间去做一些 abtest,或者一些功能的临时开关,过了几个版本业务验证完之后一般是需要有明确数据结论去支撑,然后固化配置的.你现在配置数据有上千个,讲道理不太合理
icyalala
2024-09-02 14:46:41 +08:00
哈哈,FGO 游戏逻辑就是这样,一启动就要下载几十 MB 的 JSON 配置数据,后来嫌大就改成 pb/msgpack 了。
lingalonely
2024-09-02 14:47:40 +08:00
游戏更新的时候不是有个加载过程吗,把这些配置传过来就行,没有必要请求上千次
broken123
2024-09-02 14:49:25 +08:00
app 有个东西叫做启动器
https://blog.csdn.net/jdsjlzx/article/details/129019317 道理都是通用的 每个端都可用 哦
FreshOldMan
2024-09-02 14:58:17 +08:00
app 一进来是首页什么情况下需要上千个配置,这些配置不能在后端配置好再下发吗?
yufeng0681
2024-09-02 15:01:31 +08:00
@Mephisto233 #59 如果是这种需求,是不是资源包在本地,网上只要弄个配置,就能启用第 N 套资源当界面更好? 资源压缩后扩展名改成不可预知的,规避审核人员打开即可。
gaobh
2024-09-02 15:03:07 +08:00
不是应该进啥模块加载啥配置吗……
winglight2016
2024-09-02 15:05:10 +08:00
这既是产品设计的缺陷,也是后端架构设计的缺陷,哪个 APP 需要一次性下载 1000 个配置项?再说了,有什么配置项非要在客户端才能起作用的?

退一万步说吧,即使真的就要启动前加载好 1000 个配置项,也只需要 app 内建一套默认配置,等到用户修改了某项配置再做 diff-merge 操作就够了,我不信哪个用户上来就把 1000 个配置项全部自定义一遍。
lambdaq
2024-09-02 15:06:38 +08:00
不要盲目优化啊。先说加多少钱。

越屎的代码越值钱。
wu00
2024-09-02 15:10:44 +08:00
某几个配置占了 50M ,剩下 99x 个配置占了几百 K ?
yufeng0681
2024-09-02 15:12:24 +08:00
所有配置项梳理分类
1 、按加载重要性排序, 启动必需的,首页必需的,二级页面必需的
2 、按更新频率分类:不更新的(放 app 里),不经常更新的(初始数据放 app 里),频繁更新的(只存网络, 这类配置要精简到极少个)
3 、按功能分类:模块级数据同步,模块级配置接口,系统级配置接口,系统级数据同步 。 不要把所有数据用配置接口获得,可以换成数据同步,这样接口不涉及业务,只是数据同步。 服务端数据文件由各个模块自己负责生成,客户端也是由模块代码负责去获取数据文件。
juzisang
2024-09-02 15:12:49 +08:00
40-50M ,是把图片转 base64 放配置里了吗...要不然纯配置怎么可能这么大,还请求上千次...
lefer
2024-09-02 15:13:55 +08:00
@onichandame #3 我觉得你的方案是可取的。
cBlank
2024-09-02 15:14:17 +08:00
参考游戏的启动流程
xuanbg
2024-09-02 15:14:48 +08:00
这上千个达到 4-50M 之巨的所谓配置数据,不知道有几个是配置项,几个是模版数据,估计 99%其实都是模版数据吧,要不然怎么可能有几十 M 。。。。。

办法很简单,配置项启动一次加载,模版数据完全可以按需加载。
realJamespond
2024-09-02 15:30:55 +08:00
拼成一个 json 一次发过来

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1069523

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX