RecyclerView OnLayout耗时过长（160-250ms），寻求Android性能优化方案

Hey there, let's tackle this RecyclerView performance issue together—those 160-250ms frame times are way above the 16ms target for smooth 60fps rendering, so let's break down actionable fixes based on your setup:

1. Clean Up the Card Layout (ConstraintLayout Redundancies) #

Your ConstraintLayout has unnecessary attributes that can add extra measurement overhead. Let's trim those first:

• Remove android:layout_alignParentTop="true" and android:layout_alignParentBottom="true" from both tvTitle and tvSubTitle—these are RelativeLayout-specific attributes and don't do anything in ConstraintLayout, but they might force extra layout passes.
• Simplify the vertical chain: Since you're using packed chain style, you can remove redundant bias attributes that don't add value (like app:layout_constraintVertical_bias="0.0" on tvTitle unless you specifically need it).
• Consider a lighter layout alternative: For this simple vertical arrangement (ImageView → Title → Subtitle), a vertical LinearLayout might be more efficient than ConstraintLayout, as it requires fewer measurement calculations. Try swapping it temporarily to test performance differences.

2. Optimize RecyclerView Core Behavior #

• Enable setHasFixedSize(true) on your RecyclerView: Since your card height is wrap_content but the overall RecyclerView size doesn't change when items are added/removed, this tells the system it doesn't need to recalculate the RecyclerView's size every time, saving layout time.
• Use DiffUtil for list updates: If you're updating the list, DiffUtil ensures only changed items are rebound, instead of reloading the entire list. This cuts down on unnecessary bind operations.
• Avoid heavy work in onBindViewHolder: Make sure you're not doing synchronous image decoding, font loading, or data processing here. All expensive operations should be offloaded to background threads.

3. Optimize Image Loading #

Even a 10KB PNG can cause jank if decoded synchronously on the main thread:

• Use an image loading library like Glide or Coil: These libraries handle asynchronous decoding, caching, and downsampling automatically. For example, with Glide:

  Glide.with(itemView.context)
       .load(R.drawable.your_image)
       .override(64.dpToPx(), 64.dpToPx()) // Match your ImageView's exact size
       .into(holder.iv)
  

• Provide density-specific drawables: Create mdpi, hdpi, xhdpi versions of your PNG so the system doesn't have to scale the image at runtime, which saves CPU cycles.
• Check for transparency overhead: If your PNG has unnecessary transparency, it can cause extra rendering layers—try converting it to an opaque format if possible.

4. Reduce Overdraw and Drawable Overhead #

• Check for overdraw: Use Android Studio's Profile GPU Overdraw tool to see if your card's background, foreground, or ImageView are causing excessive overdraw. If so:
  • Simplify @drawable/card_background—avoid nested shapes or complex gradients if possible.
  • Replace the custom ripple foreground with the system default (?attr/selectableItemBackground) to eliminate unnecessary drawable processing.
• Remove redundant elevation: If your card's background already includes a shadow, android:elevation="2dp" might be redundant and add an extra layer to render.

5. Dig Deeper with Systrace #

Since you already have a Systrace capture, focus on these key bottlenecks:

• Measure/Layout phases: If these take most of the time, double down on layout optimizations (step 1 above).
• Draw phase: If drawing is slow, overdraw or complex drawables are likely the culprit (step 4).
• Image decoding: If you see DecodeBitmap calls blocking the main thread, fix your image loading strategy (step 3).

Quick Isolation Tests #

To narrow down the root cause quickly:

1. Temporarily replace your custom card layout with a super simple one (just a single TextView) and check frame times. If they drop significantly, the issue is in your card layout or its contents.
2. Remove the ImageView entirely—if frame times improve, image loading is the main problem.

内容的提问来源于stack exchange，提问作者toasty