Shulou(Shulou.com)06/01 Report--

Most people do not understand the knowledge points of this article "how to improve the performance of ListView in Android", so the editor summarizes the following content, detailed content, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "how to improve the performance of ListView in Android" article.

How does ListView work?

ListView is designed for scalability and high performance requirements. In fact, this means that ListView has the following two requirements:

Create as few View as possible

Just draw and lay out the child View that is visible on the screen.

Understanding the * * point is simple: creating a View and displaying it by laying out xml files is an expensive, time-consuming and resource-consuming operation. Although the layout file has been compiled and packaged in binary form for more efficient syntax parsing, creating a View still needs to go through a special XML tree and instantiate all the View that needs to respond.

ListView solves this problem by recycling some invisible Views, often called "ScrapView (obsolete View)" in Android source code. This also means that developers only need to simply update the contents of each line without creating a View for the layout of each individual line.

To achieve the second point, when we swipe the screen, ListView increases the Views below or above the current window by using the View collector, and the currently active Views is moved to a recyclable pool. In that case, ListView only needs to keep enough Views in memory to fill the layout in the allocated space and some additional recyclable Views, even when your Adapter has hundreds of items fits. It uses different methods to fill the space between rows, from the top or bottom, and so on, depending on how the window changes.

The following figure shows intuitively what happens when you press ListView:

With the above introduction, let's move on to the tips section compared to the fact that we are already familiar with this mechanism of ListView. As described above, ListView makes Adapter's getView () as lightweight as possible by dynamically creating and recycling a lot of View when sliding. All the tricks are to make getView () faster in a variety of ways.

Recovery of View

Each time ListView needs to display a new line on the screen, the method getView () is called from its Adapter. As we all know, the getView () method has three parameters: the position of the line, convertView, and the parent ViewGroup.

The parameter convertView says that it is the ScrapView described earlier. When ListView asks to update the layout of a row, convertView is a non-null value. Therefore, when the convertView value is not empty, you only need to update the content, not the layout of a new line. GetView () is generally in the following form in Adapter:

Public View getView (int position, View convertView, ViewGroup parent) {if (convertView = = null) {convertView = mInflater.inflate (R.layout.your_layout, null);} TextView text = (TextView) convertView.findViewById (R.id.text); text.setText ("Position" + position); return convertView;}

How to write the template by View Holder

One of the most common operations of Android is to find an internal View in the layout file. This is usually done using a View method of findViewById (). The findViewById () method in the View tree, based on a View ID, is called recursively to find its subtree. Although it is perfectly normal to use findViewById () in a static UI layout. However, when sliding, ListView calls getView () in its Adapter very frequently. FindViewById () may affect the performance of ListView slides, especially if your row layout is complex.

Finding an internal view within an inflatable layout is one of the most common operations on Android. This is usually done through a findViewById (view method). This method will recursively go through the view tree to find a child with a given ID code. It's perfectly normal for a static UI layout to use findViewById (), but as you can see, the adapter's getView () is called very frequently when scrolling in ListView. FindViewById () may perceivably hit ListViews, especially scrolling performance, if your line layout is extraordinary.

The pattern of View Holder is to reduce the number of calls to findViewById () in the getView () method in Adapter. In fact, View Holder is a lightweight inner class that references directly to all internal views. After creating the View, you can store it as a tag in the View of each line. In this way, you only need to call findViewById () when the layout is first created. The following is a code example of a View Holder template that uses the above method:

Public View getView (int position, View convertView, ViewGroup parent) {ViewHolder holder; if (convertView = = null) {convertView = mInflater.inflate (R.layout.your_layout, null); holder = new ViewHolder (); holder.text = (TextView) convertView.findViewById (R.id.text); convertView.setTag (holder);} else {holder = convertView.getTag () } holder.text.setText ("Position" + position); return convertView;} private static class ViewHolder {public TextView text;}

Asynchronous loading

In many cases, Android applications display some multimedia content, such as pictures, in each line of ListView. There is no problem with getView () in Adapter using the image resources built into the application, as it can be stored in the Android cache. But when you want to polymorphically display content from your local disk or network, such as thumbnails, resume pictures, etc. In this case, you may not want to load them directly in getView () in Adapter, because the IO process blocks the UI thread. If you do this, ListView looks very stuttered.

In a separate thread, if you want to run IO operations on all lines or any high-load CPU restrictions on asynchronous operations. The trick is to achieve recycling behavior that conforms to ListView. For example, if you use the load of AsyncTask to load data images in getView () in Adapter, the View of the images you are loading may be recycled for use elsewhere before the AsyncTask is complete. So, once the asynchronous operation is complete, you need a mechanism to know if the corresponding View has been recycled.

A simple way to achieve this is by attaching some information that identifies the View with which the row is associated. Then, when the asynchronous operation completes appropriately, check that the View of the target line is consistent with the identified View. There are many ways to achieve this goal. The following is a simple example of implementing this approach:

Public View getView (int position, View convertView, ViewGroup parent) {ViewHolder holder;... Holder.position = position; new ThumbnailTask (position, holder) .executeOnExecutor (AsyncTask.THREAD_POOL_EXECUTOR, null); return convertView;} private static class ThumbnailTask extends AsyncTask {private int mPosition; private ViewHolder mHolder; public ThumbnailTask (int position, ViewHolder holder) {mPosition = position; mHolder = holder;} @ Override protected Cursor doInBackground (Void... Arg0) {/ / Download bitmap here} @ Override protected void onPostExecute (Bitmap bitmap) {if (mHolder.position = = mPosition) {mHolder.thumbnail.setImageBitmap (bitmap);} private static class ViewHolder {public ImageView thumbnail; public int position } the above is the content of this article on "how to improve the performance of ListView in Android". I believe you all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to learn more about the relevant knowledge, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.