【问题标题】:Room - Slow Query in BackgroundRoom - 后台慢查询
【发布时间】:2018-05-23 08:55:36
【问题描述】:

我目前正在实施 Room 来替换我的旧 SQL 代码,但我遇到了一个问题,即在后台运行时我的查询非常慢。

例如,我有两个相同的查询,一个在 UI 线程上运行,另一个返回 Single。我正在使用allowMainThreadQueries() 来测试这个案例。

    @Query("SELECT * FROM event ORDER BY `begin` ASC LIMIT $LIMIT")
    fun getUIThreadSchedule(): List<Event>


    @Query("SELECT * FROM event ORDER BY `begin` ASC LIMIT $LIMIT")
    fun getSchedule(): Single<List<Event>>

现在,当我运行这两种方法并比较时间得出结果时,它们是非常不同的。

这需要大约 6 毫秒才能完成。

    val events = database.getUIThreadSchedule()

这需要大约 360 毫秒才能完成。

    database.getSchedule()
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe({
                   // elements are now here
                }, {
                    // show an error view
                })

我尝试使用其他选项,例如Flowable,但结果是一样的。

有人知道我做错了什么吗?

谢谢。

【问题讨论】:

    标签: android performance rx-java2 android-room


    【解决方案1】:

    在对问题进行了大量调查后,我发现了为什么此调用比阻塞调用花费的时间更长。

    调用getSchedule() 时,查询完成时订阅块未正确运行。它必须等待 UI 线程,所以如果它在另一方面被阻塞,它将不得不等待。

    // start query
    database.getSchedule()
                    .subscribeOn(Schedulers.io())
                    .observeOn(AndroidSchedulers.mainThread())
                    .subscribe({
                       // once ui thread is available, display content
                    }, {
                        // ...
                    })
    

    我的 UI 线程被阻塞的原因是因为我正在冷启动测试,所以我的 Fragment 会创建,我的查询会被触发,但是它必须等待 UI 其余部分的第一帧在我处理 getSchedule() 结果之前进行渲染。

    通过阻塞调用,它已经有了 UI 线程,所以没有等待。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多