我有一个广播接收器，用于监听电源连接事件。每当设备通电时，我都会尝试将文件从APP传输到运行Ubuntu的计算机中的服务器。文件通过蓝牙传输。由于文件的传输很重要，因此，如果由于某种原因传输出错，或者首次尝试连接失败，我最多重试6次，每次尝试之间需要3分钟。
刚开始，我使用asynctask，只要我们仍然可以重试并且文件传输未成功完成，它就可以保持活动状态。我读到，在广播接收器中拥有asynctask并不是一个很好的习惯，这是完全有意义的，尤其是因为我强迫该任务长时间运行。因此，我决定更改为JobIntentService，以便每次接收器捕获电源连接事件时，我都会发出将文件传输到计算机的作业。在作业中，在文件传输完成或失败之后，我将设置一个警报，该警报将向广播发送挂起的意图并再次调用该作业。
我正在运行此程序，但我注意到（与以前不同）在传输过程中出现了太多“对等连接重置”错误，这使我想知道作业是否在完成之前就停止了？ 。这些错误过去在我以前的实现中不会发生。然后，我还注意到，由于某种原因，操作系统似乎再次自行启动了JobIntentService（没有启动它的事件），这导致我的代码不一致并导致我丢失了一些文件（我不应该允许该作业的多个实例同时运行）
我的问题是，为什么您认为该服务已重新启动？ BT传输期间，操作系统可能完成JobIntentService并重新启动它吗？文件很重，因此需要几分钟才能从应用程序传输到计算机。我当时正在考虑尝试使用前台服务而不是JobIntent，并收到有关该服务的通知，或者回到我以前的实现。
有什么建议么？
这就是我所谓的意向工作。
FileTransferJob.isJobAlreadyRunning = true;
Intent intent = new Intent(context, FileTransferJob.class);
intent.putExtra(TRANSFER_DATA_RETRIES, retries);
FileTransferJob.enqueueWork(context,intent);
这是JobIntentService类
public class FileTransferJob extends JobIntentService {
/**
* Unique job ID for this service.
*/
public static boolean isJobAlreadyRunning = false; //This flag will remain true as soon as this JOB is called and as long as retries are still available
public static final int JOB_ID = 1000;
public static int MAX_NUM_OF_RETRIES = 6;//How many times are we going to retry to send the data
private int MINUTES_TO_WAIT = 3; //The minutes we wait between each attempt
public String TAG = "FileTransferJob";
/**
* Convenience method for enqueuing work in to this service.
*/
public static void enqueueWork(Context context, Intent work) {
enqueueWork(context, FileTransferJob.class, JOB_ID, work);
}
@Override
protected void onHandleWork(Intent intent) {
int retriesRemaining = intent.getIntExtra(TRANSFER_DATA_RETRIES,1); //Get the number of retries we have. Default to 1 (this one)
Log.d(TAG, "onHandleWork: About to attempt transfer with remaining retries " + String.valueOf(retriesRemaining));
try {
BluetoothFileTransfer btio = new BluetoothFileTransfer();
Log.d(TAG, "onHandleWork: About to send data over Bluetooth");
btio.sendData(FileTransferJob.this.getApplicationContext());
FileTransferJob.isJobAlreadyRunning = false; //Success, then this is no longer running
Log.d(TAG, "onHandleWork: The data has been sent over Bluetooth");
}catch (Exception e){
Log.d(TAG, "onHandleWork: There was a problem with the BT transfer: " + e.getMessage());
retriesRemaining--; //We reduce the number of retries we have
//If no more retries available, simply do nothing
if (retriesRemaining > 0) {
Log.d(TAG, "onHandleWork: Setting up alarm. Retries ramaining: " + String.valueOf(retriesRemaining));
AlarmManager alarmManager = (AlarmManager) getSystemService(ALARM_SERVICE);
Intent alarmIntent = new Intent(this.getApplicationContext(), DataCollectReceiver.class);
alarmIntent.setAction(TRANSFER_DATA);
alarmIntent.putExtra(TRANSFER_DATA_RETRIES, retriesRemaining);
PendingIntent alarmPendingIntent = PendingIntent.getBroadcast( this.getApplicationContext(), PENDING_INTENT_CODE_FILE_TRANSFER_JOB, alarmIntent, PendingIntent.FLAG_UPDATE_CURRENT);
int totalTime = MINUTES_TO_WAIT*60*1000;
if(alarmManager != null){
alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP,
System.currentTimeMillis() + totalTime,
alarmPendingIntent);
Log.d(TAG, "onHandleWork: Alarm is set, waiting " + String.valueOf(totalTime) + " minutes for next attempt...");
}else{
Log.d(TAG, "onHandleWork: Alarm could not be set. Alarm manager is NULL");
}
}else{
Log.d(TAG, "onHandleWork: There are no more retries");
FileTransferJob.isJobAlreadyRunning = false;
}
}
}
@Override
public void onDestroy() {
super.onDestroy();
Log.d(TAG, "onDestroy: The file transfer JOB has finished");
}
}
日志猫。突出显示的部分显示了我认为操作系统正在创建JobService的新实例并运行它的情况。
最佳答案
让我尝试回答它，因为我已经注意到了这种行为。 JobIntentService / JobService / Worker将在停止后仅运行10分钟，对于JobService / JobIntentService，您可以调用onStopJob / onStopCurrentWork；对于Worker，则可以调用OnStopped。
尽管android文档仅针对Worker解释了此行为，但JobService / JobIntentServie的行为方式相同
一个Worker最多有十分钟的时间来完成其执行，并返回一个ListenableWorker.Result。在此时间到期后，将通知工人停止。
因此，我可以假设您的任务在10分钟内未完成，而Android正在销毁JobIntentService。
现在的事情是所有这些Jobservice / JobIntentService / Worker在指数退避时间即30secs，1min，2mins，4mins之后再次启动（如果过早停止）。
尽管很奇怪的部分是运行了10分钟后就死了的旧线程按照说明开始了，但是随着HandleWork上的回调再次出现，它又启动了另一个线程，该线程重复了该线程所做的工作，这就是为什么我认为您看到不一致之处。
建议您以可以在10分钟窗口内完成的方式来中断工作。或者，我们可以等待Google团队解决此问题。