为什么WRAP_CONTENT火BindView不止一次WRAP_CONTENT、BindView

2023-09-07 03:53:19 作者:树雾

我工作的一个Android应用程序与ListView和我在优化它的过程。它使用自定义光标适配器在一个活动和我注意到bindview()是用于在列表的每行烧成两次。虽然研究的BindView()和NewView的()方法,在这里,我看到一个帖子,有WRAP_CONTENT我的列表视图的宽度是一个坏主意。我切换到FILL_PARENT现在中提琴bindview()和NewView的()每一次只火了每一个项目。

I am working on an Android app with a listView and am in the process of optimizing it. It uses a custom cursor adapter in one activity and I noticed that bindview() was firing twice for each row of the list. While researching the BindView() and NewView() methods here, I read in a post that having Wrap_Content for the width of my listview was a bad idea. I switched it to Fill_Parent and viola now bindview() and newview() each only fire once for each item.

所以,我可以更好地理解的Andorid操作系统的内部,我想知道为什么WRAP_CONTENT造成bindview()火多次。

So that I can better understand the internals of the Andorid OS, I would like to know why Wrap_Content caused bindview() to fire multiple times.

我已经在谷歌做了几个搜索,Android开发文档和这里没有运气。

I have done several searches on Google, the android developer docs and here with no luck.

任何回应,真是AP preciated。

Any response is really appreciated.

谢谢, 乔治

推荐答案

如果我没有记错从谷歌I / O的视频,创下了的ListView的宽度(或高度) WRAP_CONTENT 将导致其测量前3项和基它的尺寸过那些。为了测量这些第3项,它必须调用 bindView()来填充它们。一旦它衡量,它会完全填充,并调用 bindView()再次对这些前3个以及任何后续。

If I recall correctly from a video from Google I/O, setting the width (or height) of a ListView to wrap_content will cause it to measure the first 3 items and base its dimensions off of those. In order to measure those first 3 items, it must call bindView() to populate them. Once it has measured, it will populate fully and call bindView() again on those first 3 and any subsequent.

这是由于这样的事实是,的ListView 只保存在内存中是什么在屏幕上时,你可能有潜在的列表中的项目数量无限。它的目的不是要 WRAP_CONTENT 来你最大的项目,因为它可以停留在图纸阶段,直到永远。

This is due to the fact that the ListView only keeps in memory what is on the screen when you may have potentially an infinite number of items in the list. It is not designed to wrap_content to your largest item because it could be stuck in the drawing phase forever.