多步骤流程：单Activity多Fragment还是多独立Activity？

Hey there! Let's dig into your dilemma since you've already put in the work researching and testing both approaches. First off, your test isn't flawed—it's just that the simple list-to-detail scenario you used favors the multi-Activity approach, while your actual target (multi-step workflows like booking) has different tradeoffs.

Let's break down the options, including the Jetpack Navigation component you mentioned:

1. Your Current Approach: Single Activity + Fragments with Backstack #

You've already hit the pain points here: dealing with state restoration (like freezesText and RecyclerView adapter initialization) and manual backstack management. But there are hidden strengths for multi-step flows:

• Seamless data sharing: You can use an Activity-scoped ViewModel to pass data between steps without messy Intent extras or singleton hacks. This is a game-changer for booking flows where each step depends on the previous one's input.
• Smoother transitions: Fragment transitions are generally lighter than Activity transitions, especially when you're switching between steps frequently.
• Centralized state management: All step states live within the same Activity context, making it easier to roll back or persist progress if the user exits mid-flow.

Your custom Fragment container is a clever workaround, but it reinvents the wheel—Jetpack Navigation was built to solve exactly these backstack and transaction headaches.

2. Multi-Activity Approach #

Your test showed this is faster to develop and has smaller code size for simple flows, which makes sense:

• Simpler lifecycle: Each Activity has a clear, isolated responsibility, so you avoid Fragment lifecycle gotchas.
• Lower cognitive load: For small, independent screens, it's easier to reason about code that's split into separate Activities.

But for multi-step workflows like booking, the downsides become critical:

• Data passing friction: Intent bundles have size limits, and passing complex data (like selected seats or product details) between Activities gets messy fast. You'll end up using Parcelable objects or persistent storage, adding extra code.
• State restoration overhead: Restoring progress across Activities requires manual handling of onSaveInstanceState, which is error-prone compared to ViewModel's automatic state retention.
• Higher transition overhead: While your test didn't show a big difference, frequent switches between Activities (e.g., going back from step 4 to step 2) can lead to noticeable lag on lower-end devices.

3. Jetpack Navigation: The Middle Ground You Should Try #

Google's Navigation component is specifically designed for multi-step flows—and it solves almost all the pain points you're facing:

• Automated backstack management: No more manual FragmentTransaction or custom containers. Navigation handles adding/removing Fragments from the backstack, and even supports "up" navigation and deep linking out of the box.
• Built-in state preservation: Pair it with ViewModel and SavedStateHandle, and you won't need to mess with freezesText or reinitializing RecyclerView adapters. ViewModels survive configuration changes and retain data across Fragment switches.
• Single Activity best practices: It enforces a single Activity architecture, which aligns with modern Android development guidelines, while hiding the complexity of Fragment management.
• Visual flow design: The Navigation Editor lets you map out your booking flow visually, making it easier to reason about step transitions and dependencies.

Final Recommendations for Your Booking Flow Scenario #

• Ditch manual Fragment backstack management: Replace your custom container with Jetpack Navigation. It's battle-tested, well-documented, and will save you hours of fixing edge cases.
• Use a single Activity + Navigation + ViewModel: This combination is perfect for multi-step flows where data needs to be shared between steps. The ViewModel will hold all your booking progress, and Navigation will handle the transitions and backstack.
• Stick with multi-Activity only for completely independent screens: If you have a screen that's unrelated to the booking flow (like a settings page), a separate Activity is fine—but for the linear booking steps, the single Activity+Navigation approach is better long-term.

Your test was valid for a simple scenario, but when you scale to a 4-5 step booking flow, the single Activity+Navigation approach will prove more maintainable and less error-prone.

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