我已经开始了大约一两个月，我必须开发一个基于 Wifi 指纹识别的室内定位系统。我需要一个定期扫描 wifi AP 并将结果数据发送到服务器的应用程序。

到目前为止，我创建了一个应用程序，它能够扫描 wifi AP 并在检测到不同连接时获取结果。我正在使用广播接收器在主要 Activity 中执行此操作。该应用程序还能够将数据发送到服务器。

我现在想要的是将这个过程转移到后台的周期性过程中，即使智能手机处于 sleep 模式。

我已经阅读了一些有关如何执行此操作的主题，但都不清楚。我的问题是最好的方法是什么？将 Service/IntentService 与 Timer/TimerTask 一起使用？

谢谢。

编辑: 谢谢!! AlarmManager 和服务工作正常!

最佳答案

我认为 AlarmManager满足您的需求，使用 setRepeating设置每 X 次重复一次

Schedule a repeating alarm. Note: for timing operations (ticks, timeouts, etc) it is easier and much more efficient to use Handler. If there is already an alarm scheduled for the same IntentSender, it will first be canceled.

Like set(int, long, PendingIntent), except you can also supply a period at which the alarm will automatically repeat. This alarm continues repeating until explicitly removed with cancel(PendingIntent). If the stated trigger time is in the past, the alarm will be triggered immediately, with an alarm count depending on how far in the past the trigger time is relative to the repeat interval.

If an alarm is delayed (by system sleep, for example, for non _WAKEUP alarm types), a skipped repeat will be delivered as soon as possible. After that, future alarms will be delivered according to the original schedule; they do not drift over time. For example, if you have set a recurring alarm for the top of every hour but the phone was asleep from 7:45 until 8:45, an alarm will be sent as soon as the phone awakens, then the next alarm will be sent at 9:00.

If your application wants to allow the delivery times to drift in order to guarantee that at least a certain time interval always elapses between alarms, then the approach to take is to use one-time alarms, scheduling the next one yourself when handling each alarm delivery.

Note: as of API 19, all repeating alarms are inexact. If your application needs precise delivery times then it must use one-time exact alarms, rescheduling each time as described above. Legacy applications whose targetSdkVersion is earlier than API 19 will continue to have all of their alarms, including repeating alarms, treated as exact.

Parameters

type One of ELAPSED_REALTIME, ELAPSED_REALTIME_WAKEUP, RTC, or RTC_WAKEUP.

triggerAtMillis time in milliseconds that the alarm should first go off, using the appropriate clock (depending on the alarm type).

intervalMillis interval in milliseconds between subsequent repeats of the alarm.

operation Action to perform when the alarm goes off; typically comes from IntentSender.getBroadcast().

正如注释所说

Note: as of API 19, all repeating alarms are inexact. If your application needs precise delivery times then it must use one-time exact alarms, rescheduling each time as described above. Legacy applications whose targetSdkVersion is earlier than API 19 will continue to have all of their alarms, including repeating alarms, treated as exact.

但我认为如果它不精确，您不会太在意。

或者您可以使用 setInexactRepeating

Schedule a repeating alarm that has inexact trigger time requirements; for example, an alarm that repeats every hour, but not necessarily at the top of every hour. These alarms are more power-efficient than the strict recurrences traditionally supplied by setRepeating(int, long, long, PendingIntent), since the system can adjust alarms' delivery times to cause them to fire simultaneously, avoiding waking the device from sleep more than necessary.

Your alarm's first trigger will not be before the requested time, but it might not occur for almost a full interval after that time. In addition, while the overall period of the repeating alarm will be as requested, the time between any two successive firings of the alarm may vary. If your application demands very low jitter, use one-shot alarms with an appropriate window instead; see setWindow(int, long, long, PendingIntent) and setExact(int, long, PendingIntent).

As of API 19, all repeating alarms are inexact. Because this method has been available since API 3, your application can safely call it and be assured that it will get similar behavior on both current and older versions of Android.

Parameters

type One of ELAPSED_REALTIME, ELAPSED_REALTIME_WAKEUP, RTC, or RTC_WAKEUP.

triggerAtMillis time in milliseconds that the alarm should first go off, using the appropriate clock (depending on the alarm type). This is inexact: the alarm will not fire before this time, but there may be a delay of almost an entire alarm interval before the first invocation of the alarm.

intervalMillis interval in milliseconds between subsequent repeats of the alarm.

Prior to API 19, if this is one of INTERVAL_FIFTEEN_MINUTES, INTERVAL_HALF_HOUR, INTERVAL_HOUR, INTERVAL_HALF_DAY, or INTERVAL_DAY then the alarm will be phase-aligned with other alarms to reduce the number of wakeups. Otherwise, the alarm will be set as though the application had called setRepeating(int, long, long, PendingIntent). As of API 19, all repeating alarms will be inexact and subject to batching with other alarms regardless of their stated repeat interval. operation Action to perform when the alarm goes off; typically comes from IntentSender.getBroadcast().

虽然我的回答目的是说出一种每 X 次重复一个 Action 的一般方法，但正如其他人注意到的那样，您将需要 Wifi Lock , Wake lock并使用 RTC_WAKEUP作为 AlarmManager 类型。

RTC_WAKEUP: Alarm time in System.currentTimeMillis() (wall clock time in UTC), which will wake up the device when it goes off.

关于android - Android中的后台wifi扫描，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22812886/