我们发现在良好的网络连接下,获取远程配置需要6到25秒不等的时间。这是正常现象还是我们做错了什么?我们在应用程序启动时立即初始化它。我们在欧洲和美国进行了测试。
我们发现在良好的网络连接下,获取远程配置需要6到25秒不等的时间。这是正常现象还是我们做错了什么?我们在应用程序启动时立即初始化它。我们在欧洲和美国进行了测试。
已经有相同的问题。
虽然可以使用Firebase实时数据库来获得快速响应,但也有一个推荐的策略:
策略3:为下一次启动加载新值 一种有效的策略是在您的应用的下一次启动时加载新的配置值以激活。在此策略中,在尝试获取新值之前,您的应用会在启动时激活获取到的值,并对其进行操作,假定它可能已经获取了但尚未激活新的配置值。该策略的操作顺序如下:
在启动时,立即激活先前获取的值。这适用于你在之前的会话中从服务器下载的任何值,并且几乎是瞬间完成的。 当用户与你的应用交互时,根据默认的最小获取间隔启动异步调用以获取新值,并添加实时配置更新监听器。实时监听器将在你的应用运行时自动获取服务器上发布的任何值。实时更新会绕过最小获取间隔设置。 在获取调用的完成处理程序或回调中,不执行任何操作。你的应用将保留已下载的值,直到下次启动应用时再次激活它们。 通过这种策略,用户等待时间大大减少。将获取和实时监听策略与应用生命周期中需要的激活()调用相结合,确保用户在与你的应用交互时获得来自远程配置的最新值。
提示:使用fetch()
和addOnConfigUpdateListener()
作为互补方法。建议每次应用启动时调用一次fetch,然后开始实时监听更新并根据需要激活它们。监听实时更新可以在不频繁调用fetch的情况下获取最新的参数值。
还可以通过减少数据量来减少获取时间。
fetchTimeoutInSeconds
设置没有任何效果。 - Baterka