如何兼顾可测试性与可读性声明Fragment依赖？

Great question! The two approaches you outlined each have clear tradeoffs, but there are absolutely better ways to handle fragment dependencies that combine the clarity of constructor-style injection with the flexibility of avoiding Parcelable constraints. Let’s break down your options:

Third Approach: Use a Dependency Injection (DI) Framework #

This is the most robust solution for most production apps, as it eliminates the downsides of both your original methods entirely:

• No Parcelable requirement: You can inject any dependency (DAOs, repositories, even complex business logic classes) directly into your fragment, no need to serialize anything.
• Explicit dependencies: Dependencies are declared in the fragment’s constructor or via field injection, so there’s no "hidden" dependency on the hosting Context.
• Easier testing: DI frameworks let you swap real implementations with mocks/fakes during unit/instrumented tests without modifying your fragment code.

For example, using Hilt (Google’s recommended DI framework for Android):

@AndroidEntryPoint
class MyFragment : Fragment() {
    // Inject your repository directly—no newInstance or onAttach hacks needed
    @Inject lateinit var myRepository: MyRepository

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        // Use myRepository normally
    }
}

Hilt handles injecting the repository instance into the fragment automatically, and you don’t have to worry about passing it around or fetching it from the Context.

Optimizing Your Existing Approaches #

If you don’t want to adopt a full DI framework right now, you can tweak your original methods to mitigate their flaws:

Optimizing the newInstance Approach: Use a Fragment Factory #

AndroidX’s FragmentFactory lets you create fragments with constructor parameters that don’t need to be Parcelable. This keeps your dependency declaration explicit (like constructor injection) while avoiding serialization constraints:

1. Define your fragment with a constructor that accepts dependencies:

class MyFragment(private val myRepository: MyRepository) : Fragment() {
    // Fragment logic here
}

2. Create a custom FragmentFactory to handle instantiation:

class MyFragmentFactory(private val myRepository: MyRepository) : FragmentFactory() {
    override fun instantiate(classLoader: ClassLoader, className: String): Fragment {
        return when (className) {
            MyFragment::class.java.name -> MyFragment(myRepository)
            // Handle other fragments if needed
            else -> super.instantiate(classLoader, className)
        }
    }
}

3. Set the factory on your Activity’s FragmentManager:

class MainActivity : AppCompatActivity() {
    private val myRepository: MyRepository = MyRepository()

    override fun onCreate(savedInstanceState: Bundle?) {
        supportFragmentManager.fragmentFactory = MyFragmentFactory(myRepository)
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
}

Now you can launch the fragment normally (e.g., supportFragmentManager.beginTransaction().replace(R.id.container, MyFragment::class.java).commit()) and the factory will pass the correct dependency.

Optimizing the onAttach Approach: Define a Clear Contract #

Instead of silently fetching dependencies from the Context, formalize the requirement with an interface. This makes the dependency explicit and enforces that the hosting component provides it:

1. Create an interface that defines the dependencies your fragment needs:

interface MyFragmentDependencies {
    fun provideMyRepository(): MyRepository
}

2. Update your fragment to check for this interface in onAttach:

class MyFragment : Fragment() {
    private lateinit var myRepository: MyRepository

    override fun onAttach(context: Context) {
        super.onAttach(context)
        // Enforce that the hosting Context implements the contract
        require(context is MyFragmentDependencies) {
            "Hosting Activity/Context must implement MyFragmentDependencies"
        }
        myRepository = context.provideMyRepository()
    }
}

3. Have your Activity implement the interface:

class MainActivity : AppCompatActivity(), MyFragmentDependencies {
    private val myRepository: MyRepository = MyRepository()

    override fun provideMyRepository(): MyRepository {
        return myRepository
    }
}

This way, the dependency is no longer hidden—anyone reading the fragment code will immediately see that it requires a MyFragmentDependencies implementation, and tests can easily mock this interface.

Final Recommendation #

If you’re building a medium-to-large app, go with a DI framework like Hilt or Koin—it’s the most scalable and maintainable option. For smaller apps or quick prototypes, the Fragment Factory approach is a great middle ground that keeps dependencies explicit without adding framework overhead.

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