0

我有一个意图服务，它实际上无限地运行，直到静态 kill Boolean 设置为 true 或某些特定条件调用 stopSelf()。（这是个好主意吗？）我的服务依赖于查询内容提供者。现在我不想“轮询”提供者以进行更改，所以我尝试了

getContentResolver().registerContentObserver(uri, false, contentObserver);

我这样定义我的 ContentObserver ：

private final ContentObserver contentObserver = new ContentObserver(new Handler(Looper.getMainLooper())) {
        @Override
        public void onChange(boolean selfChange) {
            super.onChange(selfChange);
            if(kill) {
                Log.i("Downloader", "Unregister observer");
                getContentResolver().unregisterContentObserver(contentObserver);
                return;
            }
            //Must submit to a thread else, UI gets blocked
            executor.execute(updater);
        }
    };

private final Executor executor = Executors.newSingleThreadExecutor();

“updater”是简单的 Runnable，它重新查询我正在观察的对象。

到目前为止，这种模式似乎正在奏效。当我观察的 URI 被删除时，我使用 stopSelf() 退出我的服务。基本上，此服务启动以监视特定 URI 的更改。意图服务的内置队列对我来说真的很有效。我有 2 个问题：

  1. 有没有比使用主 Looper 更好的方法来提供处理程序？如果我使用我的服务线程的处理程序，所有“消息”都会在我的服务终止后传递给 onChange（如果我不取消注册观察者）
  2. 这个模型合理吗？
4

1 回答 1

0

这是一个好主意吗 ？

恕我直言，不。使用常规Service并管理您自己的后台线程。然后使用，或通过，而不是“静态杀死布尔值”stopService()传递给服务的消息。startService()

有没有比使用主 Looper 更好的方法来提供处理程序？

使用常规Service并 fork 你自己的HandlerThread，然后使用它的Looper. 然后你就可以摆脱单独Executor的Looper.

于 2015-03-01T20:15:21.150 回答