Question

我正在开发大型应用程序，每隔X分钟（测试时间为5分钟）由AlarmManger调用：

mAlarmManager.setAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, nextSyncTime.getMillis(), PendingIntent.getBroadcast(this, INTERVAL_SYNC_SERVICE_REQ_CODE, new Intent(SYNC_ACTION), PendingIntent.FLAG_UPDATE_CURRENT));

类ScheduledRecevier正在侦听SYNC_ACTION并启动IntentService。在此服务期间，使用retrofit2将多个（大约25个）API称为同一服务器。一个接一个 - 当一个人完成下载并写入Datebase时，将启动另一个。等等。

我的问题是，虽然我没有使用设备这个过程持续不同时期。我的意思是：如果时间大概是2分钟，最多3分钟，但有时候（每天8-16次）大约持续10分钟：O

这是log：

11:23:09.064 8388-8388/myApp V/ScheduledReceiver: Sync from alarm
11:23:09.154 8388-9007/myApp V/SynchronizationService: Sync started
11:23:10.474 8388-9007/myApp V/Sync1: Sync completed
11:23:10.604 8388-9007/myApp V/Sync2: Sync completed
11:23:10.724 8388-9007/myApp V/Sync3: Sync completed
11:23:11.555 8388-9007/myApp V/Sync4: Sync completed
11:23:11.766 8388-9007/myApp V/Sync5: Sync completed
11:24:18.248 8388-9007/myApp V/Sync6: Sync completed
11:24:18.496 8388-9007/myApp V/Sync7: Sync completed
11:25:19.813 8388-8399/myApp I/art: Background sticky concurrent mark sweep GC freed 127447(6MB) AllocSpace objects, 3(204KB) LOS objects, 37% free, 11MB/19MB, paused 1.257ms total 104.434ms
11:26:27.355 8388-9007/myApp V/Sync8: Sync completed
11:31:20.562 8388-8388/myApp I/Timeline: Timeline: Activity_idle id: android.os.BinderProxy@2d78961 time:67843774
11:31:22.592 8388-8388/myApp I/Timeline: Timeline: Activity_launch_request id:com.santander.msantander time:67845808
11:31:22.722 8388-8388/myApp D/SecWifiDisplayUtil: Metadata value : SecSettings2
11:31:22.852 8388-8388/myApp I/Timeline: Timeline: Activity_idle id: android.os.BinderProxy@efae967 time:67846063
11:31:24.642 8388-8388/myApp I/Timeline: Timeline: Activity_idle id: android.os.BinderProxy@2d78961 time:67847852
11:31:30.302 8388-9007/myApp V/Sync9: noUpdate
11:31:30.472 8388-8399/myApp I/art: Background sticky concurrent mark sweep GC freed 245773(8MB) AllocSpace objects, 0(0B) LOS objects, 29% free, 20MB/28MB, paused 1.481ms total 156.454ms
11:31:30.982 8388-9007/myApp V/Sync10: Sync completed

BEGIN_DATE  
2017-02-24 11:23:07.617
END_DATE
2017-02-24 11:31:32.303

11:36:35.162 8388-8388 /myApp V/ScheduledReceiver: Sync from alarm
11:36:35.172 8388-13586/myApp V/SynchronizationService: Sync started
11:36:37.202 8388-13586/myApp V/Sync1: Sync completed
11:36:37.392 8388-13586/myApp V/Sync2: Sync completed
11:36:37.572 8388-13586/myApp V/Sync3: Sync completed
11:36:38.232 8388-13586/myApp V/Sync4: Sync completed
11:36:38.482 8388-13586/myApp V/Sync5: Sync completed
11:36:39.812 8388-13586/myApp V/Sync6: Sync completed
11:36:40.072 8388-13586/myApp V/Sync7: Sync completed
11:36:40.632 8388-13586/myApp V/Sync8: Sync completed
11:36:49.432 8388-8399/ myApp I/art: Background sticky concurrent mark sweep GC freed 266493(10MB) AllocSpace objects, 1(68KB) LOS objects, 40% free, 15MB/26MB, paused 1.661ms total 125.890ms
11:36:54.392 8388-8399/ myApp I/art: Background partial concurrent mark sweep GC freed 301387(10MB) AllocSpace objects, 1(68KB) LOS objects, 50% free, 15MB/31MB, paused 1.572ms total 145.270ms
11:36:56.992 8388-13586/myApp V/Sync9: noUpdate
11:36:57.172 8388-13586/myApp V/Sync10: Sync completed


BEGIN_DATE
2017-02-24 11:36:34.180
END_DATE
2017-02-24 11:37:00.540

为简单起见，我打电话给API SyncX，以表明在两种情况下都是相同的路径。我省略了其余的同步并将记录到datebase的内容粘贴为同步开始时间和结束时间。

正如你在第一个案例中看到的那样，在11:23同步从闹钟开始并在11:31结束。在第二种情况下，它已于11:36开始，并于11:37结束

在这两种情况下都有相同的数据部分。所有同步都有类似的过程：drop table，create table，insert new data（collection delete不能在如此大的数据部分中进行交换）。 Sync7，Sync8，Sync9在这方面没有什么不同。

任何人都知道如何在短时间内改善这一点？所有呼叫都使用本地数据库的登录名和密码，需要直接从应用程序调用以到达服务器（安全工作区）。

Answer 1

研究Doze and Standby以了解您应用的行为。我知道您使用mAlarmManager.setAndAllowWhileIdle()即使设备处于打盹或待机模式也会触发警报。它只会触发警报并且您的onReceive()将被调用，并且在该功能中您正在启动处理数据同步的服务但是

应用程序仍处于打盹或待机模式

以onReceive()唤醒手机，使其在您的服务正在同步时保持唤醒状态。

我希望它有道理。谢谢！

应用同步

1 个答案: