CODEWITHSUNDEEP
androidperformanceandroid-layoutandroid-listview
Makibo
Makibo

Reputation: 1679

Performance impact of inflating layouts which have elements with visibility=gone

I am trying to improve our list view rendering performance and looking into the fine tuning now. (we use viewHolder, fetch images async, pause image displaying on scroll, disabled scrolling cache already)

Now I was inspecting the layout and came across a setup like the following for the single list item's layout, which gets inflated in getView.

getView() of custom list adapter

if (convertView == null) {
  convertView = inflater.inflate(R.layout.zzz_list_item, null);
  ...save stuff in holder etc.

zzz_list_item.xml

<LinearLayout
    android:id="@+id/layout_success"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="@color/base"
    android:orientation="vertical"
    android:paddingBottom="30dp" >
 ...many lines of a "success" item layout
 </LinearLayout>

  <LinearLayout
    android:id="@+id/layout_failure"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    android:visibility="gone" >
  ...many lines for a failure item layout
 </LinearLayout>

The visibility gets controlled further down in the getView method of our custom listview adapter

getView() method - executed every time

 if(isSuccessfulItem){
   ((LinearLayout) convertView.findViewById(R.id.layout_failure)).setVisibility(View.GONE);
   ((LinearLayout) convertView.findViewById(R.id.layout_success)).setVisibility(View.VISIBLE);
 } else {
   ((LinearLayout) convertView.findViewById(R.id.layout_failure)).setVisibility(View.VISIBLE);
   ((LinearLayout) convertView.findViewById(R.id.layout_success)).setVisibility(View.GONE);
 }

While this also might be a small performance hog (getView is expensive), I wonder if it would make sense to refactor and split the handling for success and failure elements into two different layouts, which would then be inflated respectively using getViewTypeCount() and getItemViewType(int position).

Does the additional failure layout code (and therefore increased file size) for my list item layout affect the performance, even if it is set to visibility=GONE during inflation?

Any insights would be much appreciated, thanks.

Upvotes: 3

Views: 3500

Answers (1)

user
user

Reputation: 87064

Does the additional failure layout code (and therefore increased file size) for my list item layout affect the performance, even if it is set to visibility=GONE during inflation?

Either way the performance gain or loss it's minimal. A view with visibility set to gone doesn't need calculation in the layout and measuring phase as it's ignored but it does consume memory(and this is what you could talk about). With your current implementation even if you don't need/use the failure part of the row layout you do have it occupying memory (multiply this by the number of rows visible on the screen). Splitting the current row in two parts will clear that memory need as each row will have only the views it actually uses.

If I were you I would implement two row types as I think it's cleaner(and it also doesn't add useless views in the memory).

You probably know this but use:

convertView = inflater.inflate(R.layout.zzz_list_item, convertView, false);

also, cache the row views in the holder.

Upvotes: 4

Related Questions