Android多平台适配：Product Flavors实现高通与联发科差异化开发

1. 项目背景与需求解析

在Android应用开发中，我们经常会遇到需要针对不同芯片平台进行差异化适配的情况。最近我在开发一个需要对接硬件厂商SDK的项目时，就遇到了一个典型场景：同一套代码需要分别适配高通(Qualcomm)和联发科(MediaTek)两个平台，而这两个平台提供的framework.jar存在接口差异。

这种需求在智能硬件、物联网设备开发中尤为常见。比如：

• 不同芯片平台的相机API调用方式可能不同
• 音频处理接口的参数格式存在差异
• 传感器数据获取的返回结构不一致

2. 技术方案选型

2.1 基础方案对比

面对这种需求，通常有几种实现方式：

1. 条件编译方案

java复制#if defined(PLATFORM_MTK)
    // 联发科平台代码
#elif defined(PLATFORM_QCOM)
    // 高通平台代码
#endif

缺点：维护困难，代码可读性差

2. 动态加载方案
   通过反射动态调用不同实现
   缺点：性能损耗大，调试困难

3. Product Flavors方案
   利用Gradle的构建变体机制
   优点：编译时确定，类型安全，易于维护

经过实际验证，我最终选择了Product Flavors方案，这也是Google官方推荐的多平台适配方案。

2.2 Product Flavors配置详解

在app模块的build.gradle中配置：

groovy复制android {
    flavorDimensions "platform"
    productFlavors {
        qcom {
            dimension "platform"
            // 高通平台特有配置
        }
        mtk {
            dimension "platform"
            // 联发科平台特有配置
        }
    }
}

3. 具体实现步骤

3.1 目录结构规划

关键是要建立正确的源码集(source set)结构：

code复制app/
├── src/
│   ├── main/          # 公共代码
│   ├── qcom/          # 高通平台代码
│   │   ├── java/
│   │   ├── res/
│   │   └── AndroidManifest.xml
│   └── mtk/           # 联发科平台代码
│       ├── java/
│       ├── res/
│       └── AndroidManifest.xml
├── libs/
│   ├── qcom/          # 高通平台jar包
│   └── mtk/           # 联发科平台jar包
└── build.gradle

3.2 依赖配置技巧

在build.gradle中为不同平台配置不同的依赖：

groovy复制android {
    sourceSets {
        qcom {
            java.srcDirs = ['src/qcom/java']
            jniLibs.srcDirs = ['libs/qcom']
        }
        mtk {
            java.srcDirs = ['src/mtk/java'] 
            jniLibs.srcDirs = ['libs/mtk']
        }
    }
}

dependencies {
    qcomImplementation files('libs/qcom/framework.jar')
    mtkImplementation files('libs/mtk/framework.jar')
}

3.3 平台识别与代码调用

在公共代码中通过BuildConfig自动生成的字段进行平台判断：

java复制public class PlatformUtils {
    public static void init() {
        if (BuildConfig.FLAVOR.equals("qcom")) {
            // 高通平台初始化
        } else if (BuildConfig.FLAVOR.equals("mtk")) {
            // 联发科平台初始化
        }
    }
}

4. 高级技巧与优化

4.1 资源合并策略

不同平台可能需要不同的资源文件：

groovy复制android {
    sourceSets {
        qcom {
            res.srcDirs = ['src/qcom/res']
        }
        mtk {
            res.srcDirs = ['src/mtk/res']
        }
    }
}

4.2 构建变体过滤

如果只需要构建特定平台的APK：

groovy复制android {
    variantFilter { variant ->
        def names = variant.flavors*.name
        if (names.contains("qcom") && !project.hasProperty('buildQcom')) {
            setIgnore(true)
        }
    }
}

4.3 动态依赖注入

通过Gradle插件实现更灵活的依赖管理：

groovy复制afterEvaluate {
    android.applicationVariants.all { variant ->
        def flavor = variant.flavorName
        if (flavor == 'qcom') {
            // 添加高通平台特有依赖
        } else if (flavor == 'mtk') {
            // 添加联发科平台特有依赖
        }
    }
}

5. 常见问题与解决方案

5.1 依赖冲突问题

当平台jar包与Android标准库冲突时：

groovy复制configurations {
    qcomImplementation.exclude group: 'androidx.core', module: 'core'
    mtkImplementation.exclude group: 'com.google.android.material', module: 'material'
}

5.2 代码复用技巧

通过接口抽象实现代码复用：

java复制// 公共接口
public interface IPlatformService {
    void init();
    void doWork();
}

// 高通实现
public class QcomService implements IPlatformService {
    // 实现细节...
}

// 联发科实现 
public class MtkService implements IPlatformService {
    // 实现细节...
}

5.3 调试技巧

在Android Studio中快速切换构建变体：

1. 点击左下角的Build Variants按钮
2. 选择需要的变体组合（如qcomDebug）
3. 同步项目后即可调试特定平台代码

6. 性能优化建议

1. 编译加速：为不同平台配置不同的编译缓存

groovy复制android {
    qcom {
        externalNativeBuild {
            cmake {
                arguments "-DANDROID_PLATFORM=qcom"
                cacheFlags "-DCMAKE_CACHEFILE_DIR=${buildDir}/qcom_cache"
            }
        }
    }
}

2. 代码缩减：为不同平台配置不同的ProGuard规则

groovy复制android {
    buildTypes {
        release {
            productFlavors.qcom.proguardFile 'proguard-qcom.pro'
            productFlavors.mtk.proguardFile 'proguard-mtk.pro'
        }
    }
}

3. 资源优化：移除不需要的资源文件

groovy复制android {
    qcom {
        resConfigs "en", "xxhdpi"
    }
}

7. 扩展应用场景

这种方案不仅适用于芯片平台适配，还可用于：

1. 厂商定制化：为不同手机厂商提供定制实现
2. 地区差异化：根据不同地区法规调整功能
3. AB测试：同时构建多个功能版本进行测试

8. 版本兼容性处理

随着Android版本更新，需要注意：

1. API级别检查：

java复制if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
    // 新平台API调用
} else {
    // 兼容实现
}

2. 动态特性模块：对于大体积的平台差异，可使用Dynamic Feature Module

groovy复制dynamicFeatures = [":qcom_feature", ":mtk_feature"]

3. 回退机制：确保当平台检测失败时有默认实现

java复制try {
    PlatformService.getInstance().doWork();
} catch (UnsupportedOperationException e) {
    DefaultImpl.doWork();
}

9. 持续集成支持

在CI/CD流程中需要特别处理：

1. 并行构建：同时构建多个平台APK

groovy复制gradle.taskGraph.whenReady { graph ->
    if (graph.hasTask(':app:assembleQcomRelease')) {
        // 高通平台构建配置
    }
}

2. 产物命名：区分不同平台输出

groovy复制android {
    applicationVariants.all { variant ->
        variant.outputs.all {
            outputFileName = "app-${variant.flavorName}-${variant.buildType.name}.apk"
        }
    }
}

3. 自动化测试：为不同平台配置测试用例

groovy复制android {
    testOptions {
        unitTests.all {
            if (it.name.contains('Qcom')) {
                systemProperty 'platform', 'qcom'
            }
        }
    }
}

10. 实际项目经验

在最近一个智能家居项目中，我们使用这套方案实现了：

1. 平台检测自动化：通过BuildConfig自动注入平台标识
2. 代码隔离：平台相关代码完全分离，主工程保持干净
3. 热修复兼容：为不同平台生成不同的补丁包

关键收获：

• 接口设计要足够抽象，避免平台细节泄漏到公共代码
• 资源命名要有明确前缀（如qcom_xxx, mtk_xxx）
• 单元测试要覆盖所有平台变体

一个典型的平台服务实现示例：

java复制// 公共接口
public abstract class PlatformService {
    public static PlatformService create(Context context) {
        if (BuildConfig.FLAVOR.equals("qcom")) {
            return new QcomService(context);
        } else {
            return new MtkService(context);
        }
    }
    
    public abstract void init();
    public abstract void start();
}

// 高通实现
class QcomService extends PlatformService {
    // 使用高通SDK实现
}

// 联发科实现
class MtkService extends PlatformService {
    // 使用联发科SDK实现
}

这种架构下，业务代码只需调用：

java复制PlatformService.create(context).start();

而具体的平台实现细节被完全隐藏，后续维护和扩展都非常方便。当需要新增平台支持时，只需添加新的flavor和对应的实现类即可。