在我的 Android 應(yīng)用程序中,我有一個非?;镜腞ecyclerView實(shí)現(xiàn),它使用帶有分頁庫的Room來顯示數(shù)據(jù)庫中的條目。從數(shù)據(jù)庫中獲取條目的 Dao 方法:@Query("SELECT * FROM entries")abstract fun findAll(): DataSource.Factory<Int, Entry>這就是LiveData從DataSource.Factorymy 中返回的構(gòu)造方法ViewModel:private val config = PagedList.Config.Builder() .setEnablePlaceholders(false) .setInitialLoadSizeHint(512) .setPrefetchDistance(256) .setPageSize(256) .build()val entries = LivePagedListBuilder(entryService.findAll(), config).build()// (entryService here just calls through to the Dao)我只是對此進(jìn)行觀察LiveData并將更新的內(nèi)容傳遞PagedList給我的RecyclerView.Adapter.相應(yīng)的RecyclerView.Adapter片段:private val differ = AsyncPagedListDiffer<Entry>(this, DIFF_CALLBACK)fun submitList(list: PagedList<Entry>) { differ.submitList(list)}(我不使用PagedListAdapter,因?yàn)樯院笪覍⑿枰谖业倪m配器中進(jìn)行更細(xì)粒度的控制)看起來一切正常,但是當(dāng)我開始監(jiān)視應(yīng)用程序的內(nèi)存使用情況時,我開始懷疑這些PagedList項(xiàng)目沒有得到正確處理。我已經(jīng)添加了下面Callback的submitList():list.addWeakCallback(differ.currentList?.snapshot(), object : PagedList.Callback() { override fun onChanged(position: Int, count: Int) { Log.d("_tag", "Position: $position | Changed: $count" + " | Size: ${list.size}") } override fun onInserted(position: Int, count: Int) { Log.d("_tag", "Position: $position | Inserted: $count" + " | Size: ${list.size}") } override fun onRemoved(position: Int, count: Int) { Log.d("_tag", "Position: $position | Removed: $count" + " | Size: ${list.size}") }})在此之后,我向數(shù)據(jù)庫中插入了 5 000 個條目,相應(yīng)的日志條目如下:D/_tag: 位置: 0 | 插入:512 | 尺寸:512這很好,這是預(yù)期的輸出。但是當(dāng)我開始在列表中向下滾動時,日志條目如下:D/_tag: 位置: 512 | 插入:256 | 尺寸:768D/_tag: 位置: 768 | 插入:256 | 尺寸:1024D/_tag:位置:1024 | 插入:256 | 尺寸:1280D/_tag:位置:1280 | 插入:256 | 尺寸:1536然后日志停在這里,不再有日志條目,無論我在此之后向下滾動多少。我對這種行為的問題:為什么onRemoved()從不調(diào)用?是PagedList一個不斷增長的列表并且項(xiàng)目留在內(nèi)存中嗎?分頁的目的不是按需加載新條目并刪除舊的(不可見的)條目嗎?為什么日志在第 1536 個條目后停止,即使我滾動通過該條目?奇怪的是,即使?jié)L動到列表底部,條目也能正確顯示。如果有人能向我解釋這種行為,我將不勝感激。
添加回答
舉報(bào)
0/150
提交
取消