``'让'制作数据的副本吗?
在我的ViewModel中,我有此livedata
列表:
val liveList: LiveData<List<Int>>
在我的活动中,在某个时候,我访问列表中的数据:
viewModel.liveList.value?.let { letList ->
while (letList.size < 10)
delay(100)
某些数据被添加到livelist
同时。 (上面的摘要在主线程中不运行)。 Letlist
会查看对livelist
的这些更新吗?因此,Letlist
仍然连接到livelist
吗?
还是Letlist
livelist
在时间点上制作的列表的副本LET
执行?因此,如果livelist
此时的元素恰好少于10个元素,则循环永远不会终止,无论将多少元素添加到livelist ?
In my ViewModel I have this LiveData
list:
val liveList: LiveData<List<Int>>
In my Activity, at some point I access the data in the list like this:
viewModel.liveList.value?.let { letList ->
while (letList.size < 10)
delay(100)
Some data gets added to liveList
concurrently. (Above snippet doesn't run in the main thread). Will letList
see these updates made to liveList
? Thus, is letList
still connected to liveList
?
Or is letList
a copy of the list in liveList
made at the point in time the let
is executed? Thus, if liveList
happens to have less than 10 elements at this point, the while
loop will never terminate, no matter how many elements are added to liveList
?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
是的,它指向同一对象。
它不是真正的“连接”。这只是对同一对象的引用。
不,这不是副本。
可能是这种情况,因为包含的列表实例本身可能已在包含的Livedata中被替换。如果将列表实例替换为Livedata内部的新列表,并且该列表会随着时间的流逝而更改,则该循环将永远不会看到新尺寸的列表,因为它会粘在原始列表上。
尽管我质疑这是否是手头任务的最佳方法。也许您应该在列表上设置一个观察者,并在已知会更改时做某事,而不是忙于循环。
Yes, it points to the same object.
It's not really "connected". It's just a reference to the same object.
No, it is not a copy.
That could be the case, since the contained list instance itself might have been replaced in the containing LiveData. If the List instance is replaced with a new one inside the LiveData, and that list get changed over time, then the loop will never see a newly sized list since it will be stuck on the original.
Though I question if this is the best approach to the task at hand. Maybe you should set up an observer on the list and do something whenever it's known to change, rather than busy-looping on it.
该代码将其编译到类似的内容(我将使用Kotlin语法,但您会得到这个想法):
So
Letlist
是一个唯一的 variable ,分配了当前值viewModel.livelist.value
。这就是为什么运行LET
在无效上的block
是安全的 - 即使可以通过另一个线程将原始var设置为null,也您正在使用自己的私人副本分配给原始值。您知道在未经检查之后不会变得无效 - 实际上,它根本不会改变!对于捕获该值的快照非常有用,另一面是该变量的值 - 它是对
list
对象的引用。如果其他内容具有相同的list
的引用,如果它添加或删除了某些项目,您也会看到这些更改 - 因为它都是您都在寻找的列表,这是您需要的东西小心 - 您可能需要创建自己的列表副本,以免发生这种情况。您不一定知道
livedata
是如何产生列表值 - 它是否每次创建一个新的list
,所以它推动的每个列表都是独立的?还是它会突变一个列表,并且基本上每次都会推动相同的对象,同时用作“这是当前列表”和“如果您有早期列表的副本,它只是更新了?复制列表可以像
thelist.tolist()
一样简单,但是它将是不同的list
object 包含相同项目对象。如果这些项目对象可以被突变(例如,如果它们具有可以更改的var
),那么即使在完全独立的列表中引用该对象,也可以看到该对象。您必须知道您正在使用的是什么,什么可以保证它给您的That code compiles to something like this (I'm going to use Kotlin syntax but you get the idea):
so
letList
is a unique variable which is assigned the current value ofviewModel.liveList.value
. That's why running alet
block on a nullablevar
is safe - even if the original var could be set to null by another thread, you're working with your own private copy assigned to the original value. You know it's not going to become null after it's been null-checked - in fact it's not going to change at all! Very useful for capturing that snapshot of a valueThe other side to this is just what the value of that variable is - it's a reference to a
List
object. If something else has a reference to that sameList
, if it adds or removes some items, you'll see those changes too - because it's the same list you're both looking atThat's something you need to be careful about - you might want to create your own copy of that list so that this can't happen. You don't necessarily know how that
LiveData
is producing list values - is it creating a newList
each time, so every list it pushes is independent? Or is it mutating a single list, and basically pushing the same object every time, acting as both "here's the current list" and "if you have a copy of that list from earlier, it just updated"?Copying a list could be as simple as
theList.toList()
, but it'll be a differentList
object containing the same item objects. If those item objects can be mutated (e.g. if they have avar
that can be changed) then wherever that object is referenced, even if it's in completely separate lists, that change will be visible. You have to know what you're working with and what guarantees it gives you