android - WakefulIntentService 实现说明

Question

Commonsware 的 WakefulIntentService效果很好，但有些东西我不太明白。下面是该服务的核心 - source 的精简版:

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()？ 这个还不够吗？

Answer 1

AFAIK a process killed takes its locks with it.

正确。

Or is this an impossible scenario ?

这不太可能，但肯定不是不可能。

In view of the previous should (flags & START_FLAG_RETRY) be added ?

这应该包含在 START_FLAG_REDELIVERY 中。 AFAIK，有了START_REDELIVER_INTENT，没有REDELIVERY 就没有RETRY。如果您有相反的证据，我很乐意看到。

Why the if (!lock.isHeld()) check ?

在未保留的 WakeLock 上调用 release() 会导致异常。这只是一个安全毯，以确保我们不会抛出不必要的异常。从理论上讲，永远不需要它；理论上，我应该有头发。

Why is this.getApplicationContext() needed ? is not this enough ?

我们创建一个 WakeLock，我们将其保存在一个静态数据成员中。 可能 getSystemService() 调用最终没有将调用它的Context 放入PowerManager 中。而且，即使这样做了，可能 Context 也不会传递给生成的 WakeLock 实例。但是，为了安全起见，通过使用 getApplicationContext()，我们获得 WakeLock 的方式确保了我们可能获得的唯一 Context leak”是单例应用程序上下文，作为单例，它是有效地预泄漏的。 :-)