Fragment过渡卡顿问题：由缓慢的measure/layout阶段引发

Great question! Let's tackle this problem step by step. First off, your preferred solution (letting the old Fragment exit normally while delaying the new Fragment's enter animation until its layout is fully measured) is absolutely achievable — and Android has built-in tools to make this clean and efficient, no need for hacky workarounds.

How to Implement Your Preferred Solution (Option 3) #

The key here is using Android's postponeEnterTransition() and startPostponedEnterTransition() methods, designed specifically for scenarios where you need to wait for a Fragment's content to be fully ready before starting its entrance animation. Here's how to adapt your code:

1. Modify the SlowFragment to delay its enter transition:

   class SlowFragment : Fragment() {
       override fun onCreateView(inflater: LayoutInflater, parent: ViewGroup?, state: Bundle?): View {
           // Tell the system to hold off on starting the enter animation
           postponeEnterTransition()
           
           val view = inflater.inflate(R.layout.fragment, parent, false)
           
           // Listen for when the view finishes measuring and laying out
           view.viewTreeObserver.addOnPreDrawListener(object : ViewTreeObserver.OnPreDrawListener {
               override fun onPreDraw(): Boolean {
                   // Clean up the listener
                   view.viewTreeObserver.removeOnPreDrawListener(this)
                   // Now that the view is ready, start the enter animation
                   startPostponedEnterTransition()
                   return true
               }
           })
           
           return view
       }
   }
   

2. Keep your existing FragmentTransaction code:
   Your original transaction setup stays the same — the setCustomAnimations call will still handle the old Fragment's exit animation normally, while the new Fragment's enter animation is delayed until its layout is complete.

   supportFragmentManager.beginTransaction()
       .setCustomAnimations(R.anim.slide_in, R.anim.slide_out)
       .replace(R.id.container, SlowFragment().apply {
           arguments = Bundle().apply {
               putInt("color", colors[i++ % colors.size])
           }
       })
       .commit()
   

Why This Works:

• The old Fragment's exit animation (slide_out) runs immediately on the main thread, so users get instant feedback.
• postponeEnterTransition() pauses the new Fragment's enter animation until we explicitly trigger it with startPostponedEnterTransition().
• The OnPreDrawListener fires right before the view is drawn, which guarantees the view has finished its measure() and layout() phases. This means the main thread won't be blocked by those expensive operations during the animation.

For a complex RecyclerView (like your FlexBoxLayoutManager setup), you can tweak this to wait until the RecyclerView has fully laid out its visible items:

class SlowFragment : Fragment() {
    override fun onCreateView(inflater: LayoutInflater, parent: ViewGroup?, state: Bundle?): View {
        postponeEnterTransition()
        
        val view = inflater.inflate(R.layout.fragment_with_recycler, parent, false)
        val recyclerView = view.findViewById<RecyclerView>(R.id.recycler_view)
        
        // Configure your RecyclerView (LayoutManager, Adapter, etc.)
        recyclerView.layoutManager = FlexboxLayoutManager(context)
        recyclerView.adapter = YourComplexAdapter()
        
        // Wait for the RecyclerView to finish laying out all visible items
        recyclerView.addOnLayoutChangeListener(object : View.OnLayoutChangeListener {
            override fun onLayoutChange(
                v: View?, left: Int, top: Int, right: Int, bottom: Int,
                oldLeft: Int, oldTop: Int, oldRight: Int, oldBottom: Int
            ) {
                recyclerView.removeOnLayoutChangeListener(this)
                if (recyclerView.layoutManager?.isLayoutComplete == true) {
                    startPostponedEnterTransition()
                }
            }
        })
        
        return view
    }
}

Additional Optimizations to Fix the Root Cause #

While delaying the enter animation solves the immediate frame drop issue, you should also optimize the measure()/layout() performance of your complex RecyclerView to make the overall experience smoother:

• Simplify Item Layouts: Reduce view hierarchy depth (use ConstraintLayout instead of nested LinearLayouts/RelativeLayouts) to cut down on measurement time.
• Avoid Heavy Work in onMeasure(): Move any complex calculations (like size calculations based on content) to background threads, and cache results where possible.
• Leverage RecyclerView Caching: Use recyclerView.setItemViewCacheSize() to increase the number of cached ViewHolders, reducing the need to recreate and re-measure items.
• Async Inflation: Use AsyncLayoutInflater to inflate RecyclerView item layouts off the main thread, reducing main thread load during initial setup.
• Fixed Size Hint: If your RecyclerView's size doesn't change after initial layout, set recyclerView.setHasFixedSize(true) — this tells the RecyclerView it doesn't need to re-measure itself when items are added/removed.

Final Notes #

Your Option 3 is not only feasible but also the most user-friendly solution here: users get immediate feedback from the old Fragment's exit animation, and the new Fragment's animation starts smoothly once its content is fully ready. The built-in postponeEnterTransition() API handles all the thread coordination for you, so you don't have to worry about conflicting main thread operations.

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