Instant App各模块依赖配置咨询：Gradle 3.0规则及库放置方案

Hey Andrew, great questions about structuring dependencies for your Instant App—let's break this down clearly based on Gradle 3.0+ best practices and Instant App conventions:

1. Base Feature Module & Room Placement #

You’re absolutely right about using the api configuration for your Base Feature module. Since it’s designed to be a shared foundation that other Feature modules depend on, api ensures that any dependencies declared here are exposed to the modules that consume Base Feature—critical for an Instant App where sharing common code across features helps keep app sizes lean.

As for Room: If multiple Feature modules will use your Room entities, DAOs, or the shared database instance, placing Room in the Base Feature with api is the perfect call. This way, all dependent features can access these Room components without having to re-declare the dependency themselves. If only one feature uses Room, you could tuck it into that specific Feature module with implementation, but given Instant Apps’ focus on shared code reuse, putting core Room infrastructure in Base Feature is generally the better approach.

2. Feature Modules & implementation Configuration #

Your understanding here is spot-on—always use implementation for dependencies in Feature modules! Here’s why this is non-negotiable:

• Prevents dependency leakage: Upper-level modules (or other features) won’t accidentally inherit dependencies that are only meant for a specific feature’s internal use.
• Enforces module independence: Each feature can evolve its own dependencies without risking breakage in other parts of the app.
• Boosts build speed: implementation dependencies don’t trigger recompiles of dependent modules unless the public API of the dependency changes—huge win as your app grows.

Quick Tip for Your Star Wars API Retrofit Setup #

Since you’re using Retrofit to hit the Star Wars API, consider splitting your Retrofit configuration:

• Put the core setup (like your OkHttpClient instance, base Retrofit client builder) in the Base Feature with api—this lets all features reuse the same networking setup.
• Keep feature-specific API interfaces and service classes in their respective Feature modules with implementation—this keeps each feature’s networking code isolated and focused on its own use cases.

Feel free to share more details if you want to dive deeper, and the community would love to check out your repo to suggest tweaks or submit PRs!

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