android - 在后台将Android设备中的数据发送到服务器，对用户的影响最小

Question

我有一个应用程序可以生成最终需要发送到服务器的数据（几个小时的延迟根本没问题）。我希望对用户的影响最小，这对我来说意味着：


电池消耗最少
没有额外的权限，尤其是没有“粗略”的权限
系统没有其他奇怪的变化（请参阅后面的示例）


到目前为止，我发现了三种方法，所有方法都有一些严重的问题：


使用SyncAdapter triggered by a network message：
从技术上讲，这听起来似乎是问题的完美答案：无论何时在网络上做某事时，都要让系统在我的应用程序中调用服务。这样一来，就可以保证网络可用，几乎没有多余的电池消耗，因为收音机已经打开，整个过程都在后台进行。
然后我尝试实际实施它...
不幸的是，这种方法需要对系统进行一些怪异的修改：即使我的应用程序不使用任何帐户，我的应用程序也需要为同步过程创建一个新的虚拟帐户。不幸的是，this account cannot be hidden from the user，因此当用户在系统设置中单击“添加帐户”时，我的应用程序已列出，但是在该应用程序中，没有任何地方显示用户帐户...此外，我还需要进行各种请求奇怪的权限，例如“创建帐户和设置密码”，“打开和关闭切换同步”以及“读取同步设置”。为什么什至没有为我提供用户帐户的应用程序都需要在我的设备上设置密码的权限？？？不酷...删除！！！
使用BroadcastReceiver和checking for connectivity when it fires：
这需要“查看网络连接”的权限，甚至可能需要“查看有关Wi-Fi网络的信息，例如是否启用了Wi-Fi和已连接的Wi-Fi设备的名称” ...为什么此应用会关心我的Wi- fi或网络邻居？令人毛骨悚然...未在我的设备上安装...
关于这种方法的好处是，仅在打开无线电时才会发生网络连接更改（至少更改为“可用”状态）。因此，如果我使用此事件触发上传（尝试），则对电池的影响将很小，因为我不会导致收音机仅为上传而打开。不幸的是，此事件可能很少被调用。更糟糕的是，从文档中听起来，仅当我的应用程序处于恢复状态时，才会调用BroadcastReceiver。因此，在我的应用程序暂停时，我什至无法使用事件...即使用这些广播事件只会比选项3稍微好一点：
只需按固定的间隔盲目启动上传，如果失败，稍后再重试：
这种方法不需要任何奇怪的权限，也不会与任何系统设置混淆。但是，很明显，这是我使用电池最糟糕的情况。因此，尽管可行，但我还是想找到一个更聪明的选择...


有没有一种方法可以解决前两种方法之一的问题？最佳解决方案是没有虚拟用户帐户的SyncAdapter，或者至少具有隐藏的用户帐户，或者系统中已经存在的SyncAdapter ...但是经过数小时的搜索并没有得出任何可用的答案...

还是有另一种更好的方法？

Answer 1

@CommonsWare指出了另外两种方法：


使用JobScheduler：
这允许根据特定的网络连接甚至设备的特定充电状态来调度作业以供将来执行。它说，它尝试为系统上的所有应用程序批量执行作业，如果其他应用程序也具有执行访问网络的作业，则可以通过避免额外的无线电激活来节省电池。但是，如果我的应用程序是唯一需要执行网络请求的应用程序，那么我认为JobScheduler不会提供与网络跳动驱动的SyncAdapter完全相同的电池节省量。不过，这只是基于我目前的理解而得出的猜测。
使用JobScheduler的最大问题是，它需要API级别21，即Android 5.0+。对于某些应用程序，这可能是可以接受的，但对我而言，这不是...
使用Google Play Services'Cloud Messenger API，特别是GcmNetworkManager：
这似乎提供与JobScheduler几乎相同的功能（除了控制重试后退策略），不同之处在于它在安装了Google Play服务v7.5或更高版本的所有设备上都可用。 Google Play服务可用于早于Android 2.3的设备，但v7.5仅在2015年5月发布。因此，尽管v7.5也可用于Android 2.3，但不能保证已安装。
要使用它，（需要非常轻巧的）Google Play服务API库需要添加到应用中，该库提供了方法GoogleApiAvailability.isGooglePlayServicesAvailable(...)，该方法可以检查是否确实安装了Google Play服务并将其更新到API库所需的版本。为了最大程度地提高这种可能性，可以将API库v7.5添加到应用程序（有关获取方法，请参见here和here）。如果检查由于用户可解决的问题而失败，则该库甚至会提供所需的对话框来提示用户解决问题（例如运行更新等）。
这种方法的主要优点是，它不需要该应用程序的任何额外权限，并且不依赖于系统的任何其他更改（模拟用户帐户，...）。因此，它对用户完全透明。


我还发现了另一种方法，与上面的第3点有些相关：


使用AlarmManager.setInexactRepeating(...)：
就像JobScheduler和GcmNetworkManager一样，AlarmManager也尝试一起批处理回调。实际上，查看有时显示为“ AlarmManager：正在检查警报... com.google.android.gms”的LogCat，似乎GCM甚至JobScheduler都使用AlarmManager触发了它们的执行。 AlarmManager缺少的功能包括：禁止基于网络连接或电池充电状态的回调，以及使用后退时间表自动重试失败的执行。从技术上讲，可以轻松添加这些功能，但是其中一些功能（例如检查网络连接性）可能需要其他权限。此方法的主要优点是：几乎所有设备都可用（从API级别3开始）。


目前，我已经实现了GcmNetworkManager方法（第5点），它可以按预期工作。

但是我实际上正在考虑移至AlarmManager.setInexactRepeating（...）（第6点）以最大程度地实现兼容性。检查设备充电状态seems to be possible without extra permissions，而不是检查网络连接，我可以触发http请求并检查它是否失败...我唯一缺少的功能是确定用户是否处于计费连接或不。当然，实现重试，退避，

更新：

看来JobScheduler实际上确实检测到了现有的网络活动（请参阅此JobScheduler introduction），这可能使其优于仅使用AlarmManager，并且与SyncAdapters一样好或更好。...GCM文档还声称基于以下内容的回调优化当前的网络活动（而不仅仅是可用性）...因此，我认为最佳的解决方案是在可用的地方使用JobScheduler，然后退回到不可用的GCM，并退回到也不可用的GCM的AlarmManager ... ..