随着人工智能技术的迅猛发展，将小参数量大模型（如轻量化语音识别模型 SenseVoice-ONNX、声学特征提取器等）直接部署在移动端侧，实现完全离线、低延迟的边缘计算（Edge Computing），已成为当下主流的开发设计方向。
然而，这类离线大模型和底层的 C++ 计算库体积庞大，往往会让打包出来的安装包（APK）从原本的 20MB~30MB 暴增至 300MB 以上。如果某些网络环境受限或对体积敏感的用户只想要轻量级版本，直接维护两套独立的代码分支往往会带来巨大的代码同步与维护灾难。
本文将分享如何通过巧妙的 Gradle 动态依赖配置与 Native 反射加载，设计一套“单一代码库、两用可选编译”的移动端大模型打包方案。
一、 核心痛点与可选编译设计
我们的项目基于混合跨平台工程。目标是实现：
- 轻量版 (Cloud-only Build)：包体积 。由于缺少本地推理库和模型，语音识别（STT）通过 WebSocket 与云端网关长连接进行。
- 重度离线版 (On-device Build)：包体积 。内置完全离线的 ONNX 推理底座和语言声学模型，优先端侧进行模型推理，仅在端侧引擎出错时 fallback 退回云端。
为了避免代码拆分，我们在构建期设计了可选依赖文件探针机制。Gradle 会在执行打包任务前，检测特定的模型包及 jar 包是否被放置在物理目录中。若存在则点亮离线版，若不存在则降级编译为轻量版。
二、 Gradle 动态依赖机制的配置实现
在 Android 项目根目录的 app/build.gradle 中，我们通过检测物理文件存在性，决定是否将大体积 native 库依赖并入打包清单中，并同时向 Java 编译器传递编译环境标：
import java.io.File
apply plugin: 'com.android.application'
// 定义大体积端侧推理库的物理探测路径def sherpaJar = file('libs/sherpa-onnx.jar')def hasSherpaOnnx = sherpaJar.exists()
android { namespace "com.example.edgeapp" compileSdk 34
defaultConfig { applicationId "com.example.edgeapp" minSdk 22 targetSdk 34 versionCode 45 versionName "4.5"
// 将探测状态作为 BuildConfig 常量注入 Java 编译空间 buildConfigField "boolean", "HAS_SHERPA_ONNX", "${hasSherpaOnnx}" }
buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } }
// 针对大体积 ONNX 模型配置不压缩规则，防止模型加载时解压导致内存溢出 aaptOptions { noCompress 'onnx' }
// 动态管理源集 (SourceSets) sourceSets { main { // 如果具备本地推理库，则加入包含底层 C++ 调用封装类的 Java 源码文件夹 if (hasSherpaOnnx) { java.srcDirs += 'src/ondevice/java' } } }}
dependencies { // 基础基础依赖 implementation 'androidx.appcompat:appcompat:1.6.1' implementation 'com.google.android.material:material:1.9.0'
// 动态依赖判定 if (hasSherpaOnnx) { // 只有当文件存在时，才真正把大体积库引入依赖链 implementation files('libs/sherpa-onnx.jar') // 仅在 arm64 架构设备上跑，过滤不必要的 ABI（如 x86）以减小体积 ndk { abiFilters "arm64-v8a" } System.out.println(">>> 编译通知: 检测到本地 sherpa-onnx 推理库，已启用完全离线端侧 STT 构建方案。") } else { System.out.println(">>> 编译通知: 未找到本地推理库，自动降级为轻量化纯云端 STT 构建方案。") }}三、 运行时动态加载与反射解耦设计
因为轻量版在编译时排除了 src/ondevice/java（即不包含离线语音识别类的定义），如果我们在主代码（如 MainActivity）中直接静态引用该类，就会导致编译报错（Class Not Found）。
为了使主工程能够与条件编译的代码完全解耦，我们在原生主入口中采用反射注入 (Reflection Register) 机制来注册插件：
package com.example.edgeapp;
import android.os.Bundle;import android.util.Log;import com.getcapacitor.BridgeActivity;
public class MainActivity extends BridgeActivity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState);
// 利用 Gradle 注入的 BuildConfig 变量进行分支处理 if (BuildConfig.HAS_SHERPA_ONNX) { try { // 通过类名反射，加载仅在离线构建中才会被编译进包的插件类 Class<?> pluginClass = Class.forName("com.example.edgeapp.LocalSttPlugin"); registerPlugin((Class<? extends com.getcapacitor.Plugin>) pluginClass); Log.i("DemoBoot", "成功通过反射注册离线端侧推理插件。"); } catch (Exception e) { Log.e("DemoBoot", "反射注册离线语音插件失败: " + e.getMessage()); } } else { Log.i("DemoBoot", "当前为轻量版构建，已忽略端上离线语音初始化。"); } }}四、 移动平台通道与运行时自适应
在跨平台（如 TypeScript 网页端）逻辑中，应用运行时无需关心当前包体积大小。它只需要在启动时向平台通道发起一次探针查询：
import { registerPlugin } from '@capacitor/core';
interface LocalSttPluginType { isReady(): Promise<{ ready: boolean }>;}
const LocalStt = registerPlugin<LocalSttPluginType>('LocalStt');
async function initSpeechEngine() { try { // 1. 查询端侧离线插件是否已经被成功反射并就绪 const status = await LocalStt.isReady(); if (status.ready) { console.log("端上离线 SenseVoice 引擎就绪，语音数据优先在端侧解码推理。"); enableLocalSpeechRoute(); } else { useCloudFallbackRoute(); } } catch (error) { // 插件未被编译打包时，反射加载不成功，插件调用会报错，自动捕获并无缝回退到云端 console.log("设备离线插件不可用，自动使用云端 WebSocket Fallback 数据通道。"); useCloudFallbackRoute(); }}五、 总结
通过上述的“Gradle 依赖探测 + 编译常量注入 + Java 源码动态源集扩展 + Java 反射动态实例化”四重连环设计，我们做到了在不分裂 Git 代码分支的前提下，仅依靠本地开发人员是否下载大体积模型，即可输出两种体积明显不同的应用安装包，为移动端模型的可选构建提供了一种可维护的工程解法。
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时