代码之家  ›  专栏  ›  技术社区  ›  Simon Richter

SQLite数据库作为IntentService,缓存数据库状态?

  •  1
  • Simon Richter  · 技术社区  · 5 年前

    Android的SQLite接口文档提到,数据库访问应该从 IntentService 因为它们可能是长时间运行的操作,所以GUI线程不应该阻塞它们。

    这个 维护服务 一旦停止 Intent s排队等待它,这基本上是在每个请求之后发生的,因此每个查询的数据库句柄也会被建立和销毁,这看起来很浪费。

    • 有办法保持 维护服务 或者以某种方式避免GUI线程之间的竞争 意图 服务部接电话?

    • 我应该问一下吗 意图 s包含应该全部执行的查询列表,或者这会导致消息大小的其他问题吗?

    1 回复  |  直到 5 年前
        1
  •  0
  •   CommonsWare    5 年前

    Android的SQLite接口文档提到,数据库访问应该从IntentService执行,因为它们可能是长时间运行的操作,所以GUI线程不应该阻塞它们。

    所有窗体的I/O都应该在后台线程上执行,以免阻塞主应用程序线程。 IntentService 考虑到Android 8.0+的变化,它本身并不是一个很好的选择。

    现在一种更典型的方法是让数据库访问由单例存储库管理(无论是手动创建的单例还是通过依赖注入框架提供给您的单例)。在后台线程上执行I/O时,存储库可以使用任意数量的方法来提供反应式API,包括:

    • RxJava语言
    • LiveData 以及普通线程、执行器等。
    • 科特林公司

    如果您使用Room作为数据库访问层,它将“免费”为您提供这三个选项。其他一些orm提供类似的功能。

    有办法保持 维护服务 或者以某种方式避免GUI线程发布更多意图和服务响应它们之间的竞争?

    后台服务只能运行一分钟。如果您关心的是打开数据库的开销,请使用单例存储库,并且每次流程调用只打开一次。您也完全有可能不需要服务;如果您有一个前台UI,那么服务可能毫无意义。

    我是否应该让我的查询意图包含一个应该全部执行的查询列表。。。?

    嗯,可能吧,但再说一遍,在这里使用服务可能不是必要的,而且肯定会使问题更复杂。

    因此:使用后台线程进行I/O。这不需要涉及服务。