1. Adapter.getview ()
Public View GetView (int position, View Convertview, viewgroup parent) {...}
This method is used to get the view that is displayed at the specified location. The official website explains as follows:
Get a View This displays the data at the specified position in the data set. Can either create a View manually or inflate it from XML layout file.
This method is called once when you want to display a view. This method is the key to ListView performance. There's a convertview in the method, and this is the caching mechanism that Android is doing for us.
Each item in ListView is returned and displayed by GetView, and if the item has many, it is obviously unreasonable to create so many objects repeatedly. As a result, Android provides recycler, puts item that is not being displayed in RecycleBin, and then uses this view from RecycleBin when a new view is displayed.
The working principle of recycler is roughly as follows:
Assuming that the screen can see up to 11 item, when the 1th item rolls out of the screen, the item's view goes into RecycleBin, and before the 12th appears, reuse the view from the Recycle Bin (recyclebin) by GetView, and then set the data, Without having to recreate a view.
We use the Apidemos provided by Android to verify this process:
First look at the key code:
Copy Code code as follows:
Public View GetView (int position, View Convertview, ViewGroup parent) {
A Viewholder keeps references to children views to avoid unneccessary calls
To Findviewbyid () on the each row.
Viewholder Holder;
When Convertview isn't null, we can reuse it directly, there is no need
To reinflate it. We only inflate a new View when the Convertview supplied
by ListView is null.
if (Convertview = = null) {
Convertview = minflater.inflate (R.layout.list_item_icon_text, NULL);
LOG.V ("tag", "positon" + position + "Convertview is null," + "NEW:" + Convertview);
Creates a viewholder and store references to the two children views
We want to bind the data to.
Holder = new Viewholder ();
Holder.text = (TextView) Convertview.findviewbyid (R.id.text);
Holder.icon = (ImageView) Convertview.findviewbyid (R.id.icon);
Convertview.settag (holder);
} else {
Get the Viewholder back to get fast access to the TextView
and the ImageView.
Holder = (viewholder) convertview.gettag ();
LOG.V ("tag", "positon" + position + "Convertview is not NULL," + Convertview);
}
Bind the data efficiently with the holder.
Holder.text.setText (Data[position]);
Holder.icon.setImageBitmap ((position & 1) = = 1 Micon1:micon2);
return convertview;
}
Static Class Viewholder {
TextView text;
ImageView icon;
}
Effect Chart:
As you can see, when you open an activity, you see 10 item.
Let's look at the log information:
As you can see, every time the Convertview is null, it is displayed by creating a new view.
When we slide down, the following figure,
Because the ITEM0 and ITEM10 both display half, so the ITEM10 is also new out, but when to show Item11, because the ITEM0 is not on the screen, so ITEM11 reuse the ITEM0 instance. You can see from the following log information:
We analyze log information, we can see that Item11 object is ITEM0, Item12 object is item1, so on.
In this way, by reusing Convertview, you can avoid new view every time, save memory and optimize the sliding effect of ListView.
2. ListView's Layout XML
In addition to the above, there is another important point is ListView in the layout XML description.
First look at the question:
Sometimes, we may see that a listview,getview will be called repeatedly (assuming the screen can see up to 6 Item), as shown in the following figure:
Repeat 0-6, 0-5, 0-5, 0-5, 0-5, 0-5. Moreover, Convertview was the same view at the beginning because of the ListView
Android:layout_height= "Wrap_content".
We modified it to android:layout_height= "fill_parent", log information as follows:
As can be seen, after the modification ListView's GetView invoke recovery and recycler behavior are consistent.
As for why the use of wrap_content will be repeated calls, I have not studied. But the initial thought is because when Android depicts ListView, because the height is not clear, so use an item to test listview in the maximum height of the screen caused. Hope to have known friends can tell, first thank you!
Finally, if there is anything wrong with the above, I hope I can point out the progress of each other.
Add:
In the next use of ListView, also found a very strange phenomenon. After the call to Notifydatasetchanged (), ListView GetView (), all convertview are in reverse order. Take a look at the screenshot below:
This should be caused by the stack structure of the recyclebin.
Other:
1. Disable Divider:
Android:divider= "#00000000"
android:dividerheight= "0DP"
2. Disable ListView selector:
Convertview.setonclicklistener (NULL);
If you just want to remove the color, you can use the android:listselector= "#00000000"
3. Disable Header divider:
Android:headerdividersenabled= "false"
4. Getitemviewtype (int) and getitemviewtype (int)
Getitemviewtype (int) can not return int value larger than Getviewtypecount ().
Otherwise you'll get java.lang.ArrayIndexOutOfBoundsException at android.widget.abslistview$ Recyclebin.addscrapview (abslistview.java:3523)
ListView returns the Convertview of the corresponding type according to the different viewtype.
General wording:
Copy Code code as follows:
GetView () {
Switch (getitemviewtype (position)) {
Case TYPE1:
if (Convertview = = null) {
} else {
}
Break
Case TYPE2:
Default
if (Convertview = = null) {
} else {
}
Break
}
return convertview;
}
Getitemviewtype (int position) {
According to the scene, generally there are:
1. The position of the different item type is fixed, then the ListView data can be stored separately
2. Different item type corresponding to the position is not fixed, then you can put ListView data unified in List<object>,
The instanceof is then used to determine the type of object and then distinguish the view type of position.
}
