2014-02-05 1 views
0

Я использовал postDelayed для задержки динамической продолжительности. И я нашел, что это работает неправильно. Вот мой исходный код.PostDelayed не работает правильно

public Runnable service = new Runnable() { 
     public void run() {  
      endTimeHere = System.currentTimeMillis(); 
      Log.d("Time",(endTimeHere-startTimeHere)/1000); 
      switch (step) 
      { 
       case 0: 
        delay = 0; 
        step = 1; 
        break; 
       case 1: 
        delay = 600;  //delay 10 min = 600 sec 
        step = 2; 
        break; 

       case 2:  
        delay = 1200; //delay 20 min = 1200 sec 
        step = 3; 
        break; 
       case 3:  
        delay = 1800; //delay 30 min = 1800 secs 
        step = 0; 
        break; 
       default: 
        break; 
      } 
      startTimeHere = System.currentTimeMillis(); 
      handler.postDelayed(service, delay*1000); 
     } 
    }; 

И начинаю и останавливаю обработчик в BroadcastLintener.

public Handler handler = new Handler();  
private BroadcastReceiver screenReceiver = new BroadcastReceiver() 
    { 
     public void onReceive(Context context, Intent intent) 
     { 
      String action = intent.getAction(); 
      if(Intent.ACTION_SCREEN_ON.equals(action)) 
      { 
       handler.removeCallbacks(service); 
      } 
      else if(Intent.ACTION_SCREEN_OFF.equals(action)) 
      { 
       handler.post(service); 
      } 
     } 
    } 

Я уверен, что postDelayed добавляется в очередь, потому что возвращаемое значение истинно. Однако время, которое я записал, не соответствует заданному значению задержки. Например, я установил задержку = 600 секунд и записанную продолжительность = 958 секунд.

Кто-нибудь знает, почему это произошло?

+1

Вы пробовали этот код с частичным wakelock? – marcinj

+0

Нет. Это связано? – iscnorthwind

+1

стоит попробовать, устройство migt должно спать после ACTION_SCREEN_OFF – marcinj

ответ

0

Обработчики не идеальны при стрельбе, когда им нужно. Другие потоки (например, поток пользовательского интерфейса) могут иметь приоритет. Кроме того, у Android есть накладные расходы для обработки Intent. Другими словами, обработчик может срабатывать с частотой 650 мс из-за задержек в мониторинге потоков из ОС, но тогда необходимо обработать намерение, экземпляр получателя, обработанное намерение и т. Д.

Возможно, вам лучше отправить намерение с данными задержки, а затем настроить службу очереди и часто опросить ее на основе ожидаемой задержки. например событие, запланированное на 500 мс в будущем, возможно, должно быть опрошено каждые 50 мс, чтобы узнать, истекло ли время задержки. В то время как событие в 10 000 мс в будущем может быть опрошено на 5000 мс или 9 000 мс, а затем увеличить частоту опроса по мере приближения времени.