处理和解决“过度使用网络(后台)"的正确方法 [英] Proper way to tackle and resolve "Excessive network usage (background)"

问题描述

问题背景

目前，我们面临来自 Android Vital 报告的网络使用过多(背景)".过去 30 天是 0.04%，但我们只是好于 9%

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

因为只有优于 9% 看起来很可怕.我们决定认真研究这个问题.

该应用是一款笔记应用(

<小时>

问题

我的问题是

1. 这种过度使用网络(背景)"警告的实际根本原因是什么?我们如何才能准确地找出根本原因.
2. 其他执行后台同步的应用(如 Google Photo、Google Keep、Google Doc 等)如何解决这个问题?

解决方案

对于您的第一个问题，网络使用过度(后台)"在以下情况下触发:

<块引用>

... 应用程序在后台运行时每小时发送和接收总计 50 MB 的数据，消耗 0.10% 的电池电量.一次电池使用是指两次充满电的间隔时间.

---

对于您的第二个问题，正如您正确识别的那样，WorkManager 很可能是您所追求的.这允许您安排任务以及您希望它发生的窗口.使用它可以让操作系统为您优化任务安排以及其他应用程序的工作.例如，不是 6 个应用每 10 分钟唤醒一次设备以完成每小时的任务，而是可以安排所有 6 个应用同时唤醒设备，从而增加在打盹模式下花费的时间.

请注意，上面的屏幕截图包含一个JobScheduler 作业"；标签.运行分析后，您将能够看到您的工作实际执行情况:

我之前使用过 Firebase JobDispatcher 并取得了巨大的成功(我写的教程)，它扩展了操作系统的 JobScheduler API 并且最终是相似的.

我看到您现在正在使用 WorkManager(Jetpack 的 JobDispatcher 版本)，但是在 8 秒内，操作系统没有机会优化您的作业.有没有什么能力可以将它们安排在最少几秒钟，最多尽可能大的范围内?

---

进一步改进

但是，您当前的任务调度设置可能不是根本原因.这里有一些额外的想法，可以提供您需要的电池改进.在您运行 Battery Historian 并确定根本原因后，它们的用处将变得更加清晰:

1. 考虑仅 wifi 是否是数据同步的可行默认/选项.您将体验到更好的电池使用率、更少的网络问题以及可能更好的客户满意度.

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

Problem Background

Currently, we have facing "Excessive network usage (background)" from Android Vital report. Last 30 days is 0.04%, but we're only Better than 9%

• Last 30 days - 0.04%
• Benchmark - Better than 9%

Since only better than 9% looks like a scary thing. We decide to look into this issue seriously.

The app is a note taking app (https://play.google.com/store/apps/details?id=com.yocto.wenote), which provides an optional feature - sync to cloud in background after the app close.

This is how we perform sync to cloud in background.

1. We use WorkManager.
2. In Application onPause, Schedule OneTimeWorkRequest, with constraint NetworkType.CONNECTED. The worker is scheduled to start with delay 8 seconds.
3. In case failure, we retry using BackoffPolicy.LINEAR, with delay time 1.5 hours.
4. The maximum number of retry is 1 time. That's mean, after the app close till the app re-open again. The maximum number of execution, of sync to cloud process is 2.
5. The size of data is vary, can be few KB till few hundred MB.

---

Additional information how we perform sync

1. We are using Google Drive REST API.
2. We are performing downloading of a zip file from Google Drive App Data folder, perform data merging in local, then zip, and re-upload the single zip file back to Google Drive App Data folder.
3. The zip file size can ranged from few KB, to few hundred MB. This is because our note taking app supports image as attachment.

---

Analysis

The only information we have is https://developer.android.com/topic/performance/vitals/bg-network-usage .

When an app connects to the mobile network in the background, the app wakes up the CPU and turns on the radio. Doing so repeatedly can run down a device's battery. An app is considered to be running in the background if it is in the PROCESS_STATE_BACKGROUND or PROCESS_STATE_CACHED state. ... ... ... Android vitals considers background network usage excessive when an app is sending and receiving a combined total of 50 MB per hour while running in the background in 0.10% of battery sessions.

1. We start the background sync job, 8 seconds after Application's onPause. During that period, will the app inside or outside PROCESS_STATE_BACKGROUND/PROCESS_STATE_CACHED? How can we avoid running inside PROCESS_STATE_BACKGROUND/PROCESS_STATE_CACHED?
2. What does it mean by "running in the background in 0.10% of battery sessions."? How can we avoid such?
3. Another assumption, is sync file is too large, and using too much data. Soon, we notice this assumption might not be true. We notice according to "Hourly mobile network usage (background)", the data size is from 0MB to 5MB.

---

Questions

My questions are

1. What is the actual root cause for such "Excessive network usage (background)" warning? How can we accurately find out the root cause.
2. How does other apps (Like Google Photo, Google Keep, Google Doc, ...) which perform background sync, tackle this problem?

解决方案

For your first question, "Excessive network usage (background)" is triggered when:

... an app is sending and receiving a combined total of 50 MB per hour while running in the background in 0.10% of battery sessions. A battery session refers to the interval between two full battery charges.

Source

To identify what is causing this, try using Battery Historian to analyse your app's battery usage over time. For us, it helped identify a repeating wakelock we didn't intend to introduce.

Here's an example of the output, showing us that excessive BLE scanning is causing a major battery impact:

---

For your second question, WorkManager is likely what you are after, as you correctly identified. This allows you to schedule a task, as well as a window you'd like it to occur in. Using this allows the OS to optimise task scheduling for you, along with other app's jobs. For example, instead of 6 apps all waking the device up every 10 minutes for their hourly task, it can be scheduled to happen for all 6 apps at the same time, increasing the time spent in doze mode.

Notice the screenshot above includes a "JobScheduler Jobs" tab. After running an analysis you'll be able to see how your jobs are actually performing:

I've previously used Firebase JobDispatcher with great success (tutorial I wrote), which extends the OS' JobScheduler API and is ultimately similar.

I see you're using WorkManager now (Jetpack's version of JobDispatcher), but with 8 seconds there's no chance for the OS to optimise your jobs. Is there any capacity of scheduling them with a minimum of a few seconds, and as large a maximum as possible?

---

Further improvements

However, your current task scheduling setup may not be the root cause. Here's a few additional ideas that may provide the battery improvement you need. The usefulness of them will become clearer after you've run Battery Historian and identified the root cause:

1. Consider whether wifi-only is a feasible default / option for data syncing. You'll experience better battery usage, fewer network issues, and likely better customer satisfaction.

2. Why does a note taking app need to sync a few hundred MB? Can you perhaps just sync the note that has changed, instead of the entire list of notes every time?

这篇关于处理和解决“过度使用网络(后台)"的正确方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！