Using convertView
The method receives, as one of its parameters, a named, by convention, . Sometimes will be null. In those cases, you have to create a new row from scratch (e.g., via inflation), just as we did before.
However, if is not null, then it is actually one of your previously created . This will be the case primarily when the user scrolls the – as new rows appear, Android will attempt to recycle the views of the rows that scrolled off the other end of the list, to save you having to rebuild them from scratch.
Assuming that each of your rows has the same basic structure, you can use to get at the individual widgets that make up your row and change their contents, then return from rather than create a whole new row.
For example, here is the implementation from last time, now optimized via (from the project at http://apress.com/):
Public class extends
Public onCreate
Super onCreate
SetContentView
SetListAdapter new IconicAdapter this
FindViewById
Public onListItemClick
SetText
Class extends
IconicAdapter
Super
This
Public getView
If null
GetLayoutInflater
Inflate null
FindViewById
SetText
FindViewById
If length
SetImageResource
Else
SetImageResource
Return
Here we check to see if the is null and, if so we then inflate our row – but if it is not null, we just reuse it. The work to fill in the contents (icon image, text) is the same in either case. The advantage is that if the is not null, we avoid the potentially expensive inflation step.
This approach will not work in every case, though. For example, it may be that you have a for which some rows will have one line of text and others will have two. In this case, recycling existing rows becomes tricky, as the layouts may differ significantly. For example, if the row we need to create a for requires two lines of text, we cannot just use a with one line of text as is. We either need to tinker with the innards of that , or ignore it and inflate a new .
Of course, there are ways to deal with this, such as making the second line of text visible or invisible depending on whether it is needed. And on a phone every millisecond of CPU time is precious, possibly for the user experience, but always for battery life – more CPU utilization means a more quickly drained battery.
That being said, particularly if you are a rookie to Android, focus on getting the functionality right first, then looking to optimize performance on a second pass through your code rather than getting lost in a sea of Views, trying to tackle it all in one shot.
Дата добавления: 2015-05-16; просмотров: 891;