java - 自 Google Fit App 更新以来，Google Fit 数据模式发生了变化，实现显然已中断

Question

我们已经在我们的用户群中发现，自上次 google fit 应用程序更新以来，数据急剧下降，自开始以来，我们一直试图找出代码中的问题。给出时间，我们认为我们使用的版本(当时是 18.0)是问题所在。
升级到 SDK 20.0 并没有改善结果，但阻止了数据停滞。目前我们可以假设 50-60% 通过 SDK 连接到 google fit 的用户不再根据(以前工作的)实现正确检索数据。它们并没有丢失，它们仍然在这里和那里发送一些比特，但它不再是以前的样子。
这张图表展示了事件的时间线，这些事件让我们得出结论，一方一定做错了什么。

为了便于阅读，下面的代码示例已经去除了大多数数据处理代码，但它仍然存在。
我们的健身客户要求 FitnessOptions.ACCESS_READ对于下面提到的所有类型，以及取决于应用程序的其他类型，每次初始化时，无论是在前台还是后台，确保我们只请求用户接受的那些。
我们可以确认下一个数据类型在请求每日总计或本地设备每日总计时不再返回任何值，但在非聚合读取中请求时确实返回同一时期的数据块:

DataType.TYPE_STEP_COUNT_DELTA
DataType.TYPE_CALORIES_EXPENDED
DataType.TYPE_HEART_RATE_BPM

我们还尝试将那些可能的更改为它们的聚合对应项，但无济于事:

DataType.AGGREGATE_CALORIES_EXPENDED
DataType.AGGREGATE_STEP_COUNT_DELTA

这是我们当前的 getDailyTotal 实现，在更新之前工作，and is written straight out as the examples on the developer site show :

    Fitness.getHistoryClient(context, account)
                .readDailyTotal(type)
                .addOnSuccessListener {
                    Logger.i("${type.name}::DailyTotal::Success")
                    onResponse(it)
                }

无论一天中的哪个时间被询问，这当前都返回 0。
然后我们有我们的补充代码，它模拟了 getDailyTotal 在内部所做的事情，也根据开发人员站点示例:
from: 一天开始于 00:00:00, UTC+1
至:一天结束时间 23:59:59，UTC+1
类型:任何数据类型。

    val readRequest = DataReadRequest.Builder()
                    .enableServerQueries()
                    .aggregate(type)
                    .bucketByTime(1, TimeUnit.DAYS)
                    .setTimeRange(from.time, to.time, TimeUnit.MILLISECONDS)
                    .build()
            val account = GoogleSignIn
                    .getAccountForExtension(context, fitnessOptions!!)
            GFitClient.request(context, account, readRequest) {
                if (it == null) {
                    aggregatedRequestError(type)
                } else {
                    Logger.i(TAG, "Aggregated ${type.name} received.")
                }
            }

这里的常见结果是 1) 空或空结果，2) 实际得到结果(在 DataType.TYPE_STEP_COUNT_DELTA 有时 的情况下)或 3) APIException code 5012, this datatype can't be aggregated.我们使用的是单一聚合，因为它可以被 (type, type.aggregate) 调用。尽管一些开发人员站点示例仍在使用它，但自几个版本以来已被弃用。.enableServerQueries()的使用(或不使用)不修改最终结果。
最后，我们假设最坏的情况，无论如何我们都会要求当天的任何内容，然后我们手动聚合。这通常会报告结果，而其他人则没有。遗憾的是，这些结果从来都不足以让人感到舒服。

    val readRequest = DataReadRequest.Builder()
                        .enableServerQueries()
                        .read(type)
                        .bucketByTime(1, TimeUnit.DAYS)
                        .setTimeRange(from.time, to.time, TimeUnit.MILLISECONDS)
                        .build()
                val account = GoogleSignIn
                        .getAccountForExtension(context, fitnessOptions!!)

这往往可行，但鉴于数据集、存储桶和整个数据集结构的复杂嵌套性质，数据的手动处理很复杂。
我们也注意到了在获取fit app上清晰可见但sdk上没有的数据时出现的问题，例如华为健康 Activity 出现在app上，而sdk只返回其中的一个子集，反之亦然周围，​​SDK 向我们返回数据(例如，一整晚的 sleep session (轻度、快速、深度...)，而 fit 应用程序显示与没有任何 session 的单个 Sleep 块相同的 sleep 。
第三方应用程序中显示的 sleep session ，使用 SDK 返回给我们的相同数据:

Google 健身应用中显示的相同 sleep session :

至于文档说:

For the Android APIs, read by data type and the Fit platform will return the merged stream by default. This automatically includes all data available to your app, including data written by other apps. You won't be able to see a list of which apps or devices the data came from with the Android APIs.

我们认为合并的流行为不正常，不是实时的(这可以通过应用程序直接从后端显示数据与尚未写入数据的 SDK 之间的延迟来解释)，但也不是问题数分钟或数小时的差异，有时从未出现。
为了理解我们如何检索这些数据，我们有一个背景 WorkerManager CouroutineJob每隔一段时间(当系统允许时，给予打盹模式权限，但我们更喜欢(并通过 WorkerManager 配置询问)是每小时或几个小时一次，以使数据保持最新显示在健身应用程序中)，我们请求从上次更新到最后一天结束日的数据或/和我们请求今天的每日总数(或截至当前时间，取决于我们走多远的“不工作”漏斗，以及也是在上次更新的日期)。

我们的实现有什么问题吗？

google fit 是否改变了向连接的应用程序报告数据的方式？

我们能以某种方式获得更真实的数据吗？

有什么方法可以更有效地以不同方式请求相同的数据？我们最感兴趣的是获取每日摘要、总数和平均值，而不是时间段/ session 。我们请求两者，但它们会进入涵盖不同用例的不同数据 channel 。

Answer 1

目前还没有答案。
我们的解决方案最终对数据进行了一系列粗暴的检查，并且在每次失败时我们都会尝试不同的方式。