WakefulIntentService实现说明

Question

Commonsware的WakefulIntentService运行得很漂亮,但有一些我不太了解的东西.以下是该服务的核心 - 源代码的精简版本:

class WIS extends IntentService {

    private static final String NAME = WIS.class.getName() + ".Lock";
    private static volatile WakeLock lockStatic = null;

    synchronized private static PowerManager.WakeLock getLock(Context context) {
        if (lockStatic == null) {
            PowerManager mgr = (PowerManager) context
                    .getSystemService(Context.POWER_SERVICE);
            lockStatic = mgr.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, NAME);
            lockStatic.setReferenceCounted(true);
        }
        return (lockStatic);
    }

    public static void startWIS(Context ctxt, Intent i) {
        getLock(ctxt.getApplicationContext()).acquire();
        ctxt.startService(i);
    }

    public WIS(String name) {
        super(name);
        setIntentRedelivery(true);
    }

    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        PowerManager.WakeLock lock = getLock(this.getApplicationContext());
        if (!lock.isHeld() || (flags & START_FLAG_REDELIVERY) != 0) { // ?
            lock.acquire();
        }
        super.onStartCommand(intent, flags, startId);
        return (START_REDELIVER_INTENT);
    }

    @Override
    protected void onHandleIntent(Intent intent) {
        try {
            // do your thing
        } finally {
            PowerManager.WakeLock lock = getLock(this.getApplicationContext());
            if (lock.isHeld()) lock.release();
        }
    }
}

问题

• 如果在onReceive()我们的警报接收器返回之后该进程被杀死会发生什么？那就是服务onCreate()(如果服务尚未实例化)或onStartCommand()从不运行.AFAIK一个被杀死的进程会锁定它.或者这是不可能的情况？
• 鉴于以前应该(flags & START_FLAG_RETRY)加入？
• 为什么if (!lock.isHeld())检查？
• 为什么this.getApplicationContext()需要？还this不够吗？

Answer 1

AFAIK一个被杀死的进程会锁定它.

正确.

或者这是不可能的情况？

这是不太可能的,但肯定不是不可能的.

鉴于先前应该添加(flags和START_FLAG_RETRY)？

这应该包括在内START_FLAG_REDELIVERY.AFAIK,有START_REDELIVER_INTENT,没有RETRY没有REDELIVERY.如果你有相反的证据,我很乐意看到它.

为什么if(!lock.isHeld())检查？

调用release()一个WakeLock未持有异常的结果.这只是一个安全毯,以确保我们不会抛出不必要的例外.从理论上讲,永远不需要它; 从理论上讲,我应该有头发.

为什么需要this.getApplicationContext()？这还不够吗？

我们创建一个WakeLock,我们在静态数据成员中保存.可能这个getSystemService()电话并没有结束把Context它叫做里面PowerManager.而且,即使它,可能在Context不被传递给目标WakeLock实例.然而,为了安全起见,通过使用getApplicationContext(),我们获得的WakeLock方式确保Context我们唯一可能"泄漏"的是单身应用程序上下文,作为单身,有效预先泄露.:-)