IntentService内のAquire部分的なウォークロック

Question

My IntentServiceは、アラームまたはアクティビティによって2つの場所から起動されます。また、持続時間は、Webから取得する必要があるデータの量と関連しています。部分的なwakelockを保持する必要があります。

ここに私の実装です：

 @Override 
    protected void onHandleIntent(Intent intent) { 

    PowerManager pm = (PowerManager) getSystemService(POWER_SERVICE); 
    WakeLock wakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "WakeLock"); 

    try { 
     wakeLock.setReferenceCounted(false); 
     wakeLock.acquire(3600000); 

      ///other code here 
    } 
    catch{ 
    } 
    finally{ 
     if (wakeLock.isHeld()) { 
      wakeLock.release(); 
     } 
    } 

私の質問は：この作品は十分だろうか？ finallyはどんな状況でもワockロックが解放されることを確認しますか？私が知っていることから、onHandleIntentは1つずつインテントを処理するので、同時に2つのインテント/ 2つのウォークロックを持つリスクはありません。

その後編集：

IntentServiceは2通りの方法で呼び出されます。

1. 私の活動から、使用してトリガAlarmから

   startService(new Intent(context, MyService.class).putExtra()..);

2のようにPendingIntent

PendingIntent pendingIntent = PendingIntent.getService(context, someId, myServiceIntent, PendingIntent.FLAG_UPDATE_CURRENT); 

Alarmから実行された場合、サービスにはウォークロックを取得するのに十分な時間がありますか？

Answer 1

ウェイクロックを維持する必要があるかどうかは、Serviceの作業量に関係しないはずです。理論的には、作業量が少ない場合でもデバイスはスリープ状態になる可能性があります。

ウェイクロックは、Serviceの実行中にデバイスがスリープできないことを絶対に確認する必要がある場合にのみ、考慮する必要があります。このようなケースは非常にまれです。いくつかの例：

• 目覚まし時計アプリケーションは
• リアルタイムメッセージングアプリケーションを（デバイスが眠っていても、あなたを目覚めさせる必要がある）

（デバイスがスリープしている場合でも、新しいメッセージについて通知する必要があります）

ほとんどのアプリケーションには厳しいタイミング要件がありません。たとえば、次は、ウェイクロックを使用するための十分な理由ではありません：

• サーバとのデータの定期的な同期（デバイスが目覚めるまで遅延されなければならない）
• 地図上に現在のユーザーの位置を表示して（ときデバイスを得ることができます目覚め;しかし、ウェイクロックは、あなたが本当にデバイスがService実行中に寝ていないことを確認する必要がある場合、あなたは（ウェイク・ロックを取得する必要が

ユーザーのルート全体を監視するアプリケーション）のために必要とされるであろういくつかのタイプのうちの1つ）。これがここに当てはまるとしましょう。

ServiceをアプリケーションのUI（Activity）から開始し、AlarmManagerを使用して起動したいと考えています。

デバイスは、UIと対話するユーザーのためのために、完全に目を覚ましする必要がありますので、あなたは安全にあなたがUI操作に応答してServiceを開始した場合、それはチャンスがあるだろうと仮定することができUI

からスタートウェイクロックを取得します（ただし、Serviceが起動するとすぐに実行します）。

解決策はこのケースをカバーします。 AlarmManager

から始まっ

は残念ながら、AlarmManagerはServiceを開始したとき、それはウェイクロックを保持してServiceは独自のウェイクロックを取得できるようになるという保証（少なくとも無し文書保証）はありません。これは、アラームが発生した後、あなたのServiceがウェイクロックを取得する前に、デバイスがスリープ状態になることを意味します。

これは、この場合、ソリューションが「中断」することを意味します。

AlarmManagerはウェイクロックをお届けしますするだけで文書化スキームは、ブロードキャストが含まれます。

アラームマネージャは限りアラーム 受信者のonReceive（）メソッドが実行されているとして、CPUのウェイクロックを保持しています。これにより、ブロードキャストの処理が完了するまで、 の電話機がスリープ状態にならないことが保証されます。 onReceive（）が返されると、Alarm Managerはこのウェイクロックを解除します。 これは、 のonReceive（）メソッドが完了すると、すぐに電話がスリープすることを意味します。アラーム受信者が Context.startService（）を呼び出した場合、要求されたサービスが起動する前に電話機が をスリープする可能性があります。これを防ぐには、 BroadcastReceiverとサービスは、 サービスが利用可能になるまで、電話機が確実に実行されるように、ロックポリシーを別途起動して ロックポリシーを実装する必要があります。

これはWakefulBroadcastReceiverが非常に便利です。

このスキームを使用する場合、「UI開始」の場合に別のものをサポートする必要はないことに注意してください。どちらの場合も同じ方法を使用してください。

また、@ CommonSWareによって開発されたthis libraryを見てみたいかもしれません（私はそれを使っていませんでした）。