应用同步时出现奇怪的滞后
Strange lags while app syncing
我正在开发大型应用程序,每隔 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));
Class ScheduledRecevier 正在侦听 SYNC_ACTION 并启动 IntentService。在此服务期间,使用 retrofit2 将多个(大约 25 个)API 调用到同一服务器。一个接一个 - 当一个完成下载并写入数据库时,另一个启动。等等。
我的问题是,虽然我不使用设备,但这个过程会持续不同的时间段。我的意思是:大部分时间大约是 2 分钟,最多 3 分钟,但有时(每天 8-16 次)持续大约 10 分钟 :O
这是日志:
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
为简单起见,我调用了 APIs SyncX 以表明在这两种情况下这是相同的路径。我省略了同步的其余部分并将记录到数据库的内容粘贴为同步开始时间和结束时间。
正如您在第一个案例 11:23 看到的那样,同步从警报开始并在 11:31 结束。在第二种情况下,它开始于 11:36 并结束于 11:37
在这两种情况下,都有相同的数据部分。所有同步都有类似的过程:删除 table、创建 table、插入新数据(集合删除在如此大的数据交换部分不起作用)。 Sync7,Sync8,Sync9在这点上没有区别。
有人知道如何改进它以缩短时间吗?所有调用都使用本地数据库的登录名和密码,需要直接从应用程序调用才能到达服务器(安全工作 space)。
研究 Doze and Standby 以了解您应用的行为。我知道您正在使用 mAlarmManager.setAndAllowWhileIdle()
,即使设备处于打瞌睡或待机模式也会触发警报。它只会触发警报,您的 onReceive()
将被调用,并且在该函数中您正在启动处理数据同步的服务但是
App is still in the Doze or Standby mode
唤醒您 onReceive()
中的 phone,使其在您的服务同步时保持唤醒状态。
我希望它有一些意义。
谢谢!
我正在开发大型应用程序,每隔 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));
Class ScheduledRecevier 正在侦听 SYNC_ACTION 并启动 IntentService。在此服务期间,使用 retrofit2 将多个(大约 25 个)API 调用到同一服务器。一个接一个 - 当一个完成下载并写入数据库时,另一个启动。等等。
我的问题是,虽然我不使用设备,但这个过程会持续不同的时间段。我的意思是:大部分时间大约是 2 分钟,最多 3 分钟,但有时(每天 8-16 次)持续大约 10 分钟 :O
这是日志:
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
为简单起见,我调用了 APIs SyncX 以表明在这两种情况下这是相同的路径。我省略了同步的其余部分并将记录到数据库的内容粘贴为同步开始时间和结束时间。
正如您在第一个案例 11:23 看到的那样,同步从警报开始并在 11:31 结束。在第二种情况下,它开始于 11:36 并结束于 11:37
在这两种情况下,都有相同的数据部分。所有同步都有类似的过程:删除 table、创建 table、插入新数据(集合删除在如此大的数据交换部分不起作用)。 Sync7,Sync8,Sync9在这点上没有区别。
有人知道如何改进它以缩短时间吗?所有调用都使用本地数据库的登录名和密码,需要直接从应用程序调用才能到达服务器(安全工作 space)。
研究 Doze and Standby 以了解您应用的行为。我知道您正在使用 mAlarmManager.setAndAllowWhileIdle()
,即使设备处于打瞌睡或待机模式也会触发警报。它只会触发警报,您的 onReceive()
将被调用,并且在该函数中您正在启动处理数据同步的服务但是
App is still in the Doze or Standby mode
唤醒您 onReceive()
中的 phone,使其在您的服务同步时保持唤醒状态。
我希望它有一些意义。 谢谢!