解决和解决“网络使用率过高（后台）”的正确方法

Question

问题背景

当前，我们面临Android Vital报告中的“ 网络使用率过高（背景）”。最近的 30天为0.04％，但我们优于9％

• 过去30天-0.04％
• 基准-优于9％

因为只有好于9％看起来才是可怕的事情。我们决定认真研究这个问题。

该应用程序是一个笔记应用程序（https://play.google.com/store/apps/details?id=com.yocto.wenote），它提供了一项可选功能-在应用程序关闭后同步到后台的云中。

这是我们在后台执行到云同步的方式。

1. 我们使用WorkManager。
2. 在应用程序onPause中，调度OneTimeWorkRequest，约束为NetworkType.CONNECTED。该工作人员计划延迟8秒钟开始。
3. 万一失败，我们将使用BackoffPolicy.LINEAR重试，延迟时间为1.5小时。
4. 最大重试次数为1次。意思是，在应用程序关闭之后，直到应用程序再次重新打开。同步到云进程的最大执行次数为2。
5. 数据大小各不相同，从几KB到几百MB不等。

---

有关我们如何执行同步的其他信息

1. 我们正在使用Google Drive REST API。
2. 我们正在从Google Drive App Data文件夹中下载一个zip文件，在本地执行数据合并，然后进行zip，然后将单个zip文件重新上传回Google Drive App Data文件夹中。
3. zip文件的大小范围从几KB到几百MB。这是因为我们的笔记应用程序支持图像作为附件。

---

分析

我们仅有的信息是https://developer.android.com/topic/performance/vitals/bg-network-usage。

  

当应用在后台连接到移动网络时，该应用   唤醒CPU并打开无线电。反复这样做可以运行   降低设备电池的电量。应用被认为正在   如果它位于PROCESS_STATE_BACKGROUND或   PROCESS_STATE_CACHED状态。   ...   ...   ... Android生命体认为，当   应用每小时发送和接收总计50 MB的数据，而   在0.1％的电池会话中在后台运行。

1. 我们在Application的{​​{1}}之后8秒钟开始后台同步作业。在此期间，应用在onPause / PROCESS_STATE_BACKGROUND内部还是外部？我们如何避免在PROCESS_STATE_CACHED / PROCESS_STATE_BACKGROUND内部运行？
2. “ 在0.1％的电池会话中在后台运行”是什么意思？我们如何避免这种情况？
3. 另一个假设是同步文件太大，并且使用了太多数据。很快，我们注意到这个假设可能不正确。我们注意到，根据“ 每小时移动网络使用量（背景）”，数据大小为0MB至5MB。

---

问题

我的问题是

1. 这种“ 网络使用过多（背景）”警告的真正根源是什么？我们如何才能准确找出根本原因。
2. 执行后台同步的其他应用（例如Google Photo，Google Keep，Google Doc等）如何解决此问题？

Answer 1

对于第一个问题，在以下情况下会触发“网络使用率过高（背景）”：

  

...一个应用程序在后台运行时，每小时发送和接收总计50 MB的内存，占电池会话的0.10％。电池会话是指两次充满电之间的间隔。

Source

要确定是什么原因造成的，请尝试使用Battery Historian分析应用随着时间的消耗情况。对于我们来说，它有助于确定我们不打算引入的重复唤醒锁。

以下是输出示例，向我们展示了过多的BLE扫描会严重影响电池：

---

对于第二个问题，如您正确识别的那样，WorkManager可能是您追求的目标。这使您可以计划任务以及希望其发生的窗口。使用此功能，操作系统可以为您以及其他应用程序的作业优化任务计划。例如，可以将6个应用程序安排为同时执行所有6个应用程序，而不是每10分钟将其唤醒一次，而不是每10分钟将设备唤醒一次，从而增加了在打ze模式下花费的时间。

请注意，上面的屏幕截图包含“ JobScheduler作业”标签。运行分析后，您将能够看到您的工作实际如何执行：

我以前使用Firebase JobDispatcher取得了很大的成功（tutorial I wrote），它扩展了OS的JobScheduler API，并且最终很相似。

我看到您现在正在使用WorkManager（Jetpack的JobDispatcher版本），但是在8秒钟内，操作系统没有机会优化您的工作。是否有能力在最少几秒钟的时间内安排它们，并尽可能最大地安排它们？

---

进一步的改进

但是，您当前的任务计划设置可能不是根本原因。以下是一些其他想法，可能会为您提供所需的电池改进。在您运行Battery Historian并确定了根本原因之后，它们的用途将变得更加清楚：

1. 请考虑是否仅wifi上网是可行的数据同步默认/选项。您会遇到更好的电池使用情况，更少的网络问题以及可能更好的客户满意度。

2. 笔记应用程序为什么需要同步几个数百 MB？您是否可以只同步已更改的笔记，而不是每次都同步整个笔记列表？