底部导航场景：不建议用Activity？Fragment性能疑问

Great question—let’s break this down into two clear parts to make it easy to follow.

Short answer: It doesn’t have to—if you implement it correctly. Here’s the breakdown of key factors:

• Lazy loading is your friend: If you initialize all 5 Fragments at once and trigger their data requests on app launch, you’ll definitely hit performance issues (slow start, high memory usage). Instead, use lazy loading: only fetch data and render the layout when the Fragment becomes visible to the user. For example, with ViewPager2, set setOffscreenPageLimit(1) to preload only adjacent Fragments, and trigger data calls in onResume() or use the onPageSelected callback to load data for the active Fragment.
• Memory efficiency: Fragments are lighter than Activities—they share the parent Activity’s Context, Window, and resources. As long as you manage data properly (e.g., store fetched data in a ViewModel instead of holding it directly in the Fragment, avoid memory leaks with weak references), 5 Fragments will use less memory than 5 equivalent Activities.
• Rendering optimization: The complexity of your layout affects performance regardless of whether it’s a Fragment or Activity. Focus on standard optimizations: use RecyclerView instead of nested ScrollViews, enable asynchronous image loading, reduce overdraw, and use view binding to avoid unnecessary findViewById() calls. These steps will keep rendering smooth for both Fragments and Activities.
• Configuration changes: With a single Activity, you can use a shared ViewModel to persist data across configuration changes (like screen rotation). This means you won’t have to re-fetch data every time the screen rotates—something that’s far harder to coordinate across multiple Activities.

Bottom navigation is all about quick, seamless transitions between sections of your app—and Activities are poorly suited for this. Here’s why:

• Higher memory overhead: Each Activity has its own independent instance of Context, task stack entry, and Window. Running 5 Activities in the background (even if paused) consumes significantly more memory than 5 Fragments attached to a single Activity. This increases the risk of the system killing your app in the background, leading to a slow reload when the user returns.
• Clunky transitions: Activity transitions have built-in overhead (the system has to create a new Window, tear down the old one) which often results in visible lag, white/black screens, or rigid system animations. Fragment transitions, on the other hand, are customizable and smooth—you can add fade, slide, or shared element transitions that feel integrated with your app’s design.
• Data sharing headaches: Sharing data between Activities requires workarounds like Intent extras, SharedPreferences, or a central database. With Fragments, you can use a shared ViewModel attached to the parent Activity—any Fragment can read or update data in real-time without complex data passing.
• Messy back stack management: Bottom navigation typically expects that tapping a tab again will either return to the top of that section or do nothing (not create a new instance). With Activities, managing this requires overriding back stack behavior, which is error-prone. Fragments let you use replace() or show()/hide() to control instances easily, ensuring consistent navigation behavior.
• Redundant configuration handling: Each Activity needs its own code to handle configuration changes (rotation, dark mode toggle). With a single Activity, you can handle these changes once, and all Fragments inherit the state from the parent Activity’s ViewModel or SavedInstanceState.

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