你的 App 还在"联网问 AI"？Gemma 4 已经住进 Android 了

有一个有点反直觉的现象：

2025 年，全球 AI 应用爆炸式增长，但你打开绝大多数"AI 功能"的 Android App，依然是 往服务器发一个请求，等结果回来。

网络不好？等。服务器繁忙？等。账号到期？凉了。

更尴尬的是——用户的隐私数据，就这样每次都绕了一圈云端。

但这件事，正在 2026 年被根本性地改变。

Google 在这个月同时扔了三颗炸弹：

• Gemma 4 集成进 Android Studio，本地 Agentic 编码能力上线；

• AICore Developer Preview 开放 Gemma 4 系统级调用接口；

• Google 官方把 Gemma 4 定调为"Android 本地 Agentic 智能新标准"。

三个信号叠加，意味着一件事：端侧 AI 在 Android 上，终于不是 demo 了，是正经的生产力工具了。

今天聊聊这背后到底发生了什么，开发者该怎么接。

01 Gemma 4 是什么，为什么这次不一样

先讲清楚 Gemma 家族的定位。

Google 有两条 AI 模型产品线：一条是 Gemini——强、大、贵，主要跑在云端；另一条是 Gemma——开源、轻量、专门为端侧设计的。

Gemma 4 是这个系列目前最强的版本，几个关键特性让它区别于前代：

• 多模态原生支持：不只是文字，图像理解也内置进来了；

• Agentic 能力提升：对工具调用（Tool Use）的理解更准确，复杂指令执行成功率显著提高；

• 推理效率优化：在移动端 NPU/GPU 上的推理速度相比 Gemma 3 有明显提升；

• 量化友好：4-bit、8-bit 量化精度损失更小，在资源有限的设备上跑起来效果更实用。

但光有好模型不够。以前开发者想在 Android 上跑本地模型，要自己解决模型下载、运行时初始化、内存管理、线程调度……一套下来，光环境搭建就能把人搞崩。

这次 Google 做的事，是把整个"模型接入层"做成了系统服务。

02 AICore：系统级推理框架，你不需要再造轮子

AICore 是 Android 系统层的 AI 推理框架，从 Android 14 开始随系统预装。你可以把它理解成一个"AI 运行时"——就像 Android 系统提供 WebView 让你不用自带浏览器内核一样，AICore 让你不用自带大模型。

AICore Developer Preview 开放 Gemma 4 调用之后，你的 App 接入本地 AI 的代码，变成这样：

// 1. 检查设备 AICore 是否可用，且 Gemma 4 是否已下载
val availability = AICore.checkAvailability(context)
if (availability != AICore.Status.AVAILABLE) {
    // 引导用户下载模型或降级到云端
    return
}

// 2. 创建推理会话（系统统一管理生命周期）
val session = AICore.createSession(
    model = GemmaModel.GEMMA_4_NANO,   // 端侧用 nano 版，约 2B 参数
    config = SessionConfig.builder()
        .temperature(0.7f)
        .maxOutputTokens(512)
        .build()
)

// 3. 发请求，和调云端 API 差不多
val response = session.generate("帮我总结这段日记的情绪：$userInput")
textView.text = response.text

注意几个细节：

• 你不持有模型文件。模型由系统统一存储在设备上，多个 App 共享同一份模型权重，节省存储空间；

• 推理在硬件加速单元上运行（NPU / GPU），不占用主 CPU，不干扰 UI 线程；

• 数据不出设备。整个推理过程在本地完成，天然满足隐私保护需求。

当然，现阶段有几个限制需要清楚：

• AICore Developer Preview 还不是正式 API，接口可能变动；

• Gemma 4 Nano 在设备上占用约 2–3GB 存储，不是所有用户设备都装得下；

• 低端机型（RAM

03 Android Studio 里的 Gemma 4：Agentic 编码的本地化

另一条线是开发者工具侧的变化。

Android Studio 从 Panda 系列开始就在重押 AI 辅助编码——Gemini in Android Studio 是其中主线。但问题是，Gemini 的推理跑在云端，每次代码补全都要联网，在网络不稳定的环境下体验就很差。

这次 Android Studio 接入 Gemma 4，把一部分 AI 推理能力本地化了。

具体来说，Gemma 4 在 IDE 里主要承担几类任务：

• 代码补全：常见模式的补全（如 Jetpack Compose 组件、Room DAO 模板）可以在本地完成，无需等云端响应；

• Agentic 任务拆解：当你说"帮我把这个 Fragment 改成 ViewModel + Repository 架构"，本地模型先做意图理解和任务分解，再决定哪些步骤需要调用更强的云端模型；

• 隐私敏感内容的处理：如果你的代码里有内部接口、密钥配置等敏感内容，本地推理意味着这些数据不会被发到外部服务器。

这个分层架构很值得关注——不是把云端 Gemini 换成本地 Gemma，而是本地处理轻量任务 + 云端处理复杂任务的混合模式。

对 Android 开发者来说，感知上最直接的变化是：代码补全的响应速度快了，在飞机上或者咖啡馆地下室也能用 AI 辅助编码了。

04 端侧 AI 的落地姿势：云端降级策略怎么设计

好，现在回到开发者最关心的问题：我要在 App 里用端侧 AI，实际怎么设计？

给一个我认为比较合理的分层策略：

// 封装一个 AI 推理路由，优先本地，按需降级云端
class AiInferenceRouter(
    private val aiCore: AICoreClient,
    private val cloudApi: GeminiCloudApi
) {
    suspend fun generate(prompt: String, context: RequestContext): String {
        // 判断是否适合本地推理
        val useLocal = aiCore.isAvailable()
            && context.privacySensitive          // 隐私敏感 → 强制本地
            || (context.complexity == LOW        // 简单任务 → 优先本地
                && aiCore.isAvailable())

        return if (useLocal) {
            try {
                aiCore.generate(prompt)
            } catch (e: AICoreException) {
                // 本地推理失败 → 降级云端
                cloudApi.generate(prompt)
            }
        } else {
            // 复杂任务 → 直接云端
            cloudApi.generate(prompt)
        }
    }
}

几个关键的设计决策：

1. 按任务复杂度路由，不要一刀切

情感分析、关键词提取、短文本分类这类任务，本地 Gemma 4 Nano 完全 OK。需要大量知识检索、多轮深度推理的任务，还是给云端。

2. 隐私敏感的内容要强制本地

用户的日记、私信、健康数据——这类内容的 AI 处理，不管本地推理速度怎样，都应该保持在设备内。这是对用户的基本尊重，也会变成未来竞争的差异化点。

3. 首次使用做好模型下载引导

AICore 的模型是按需下载的，不是预装进 App 里。用户第一次触发本地 AI 功能，需要下载 Gemma 4 Nano（约 2GB）。这个过程需要：

• 提前给用户解释为什么要下载，下载完能做什么；

• 允许在 Wi-Fi 下后台静默下载；

• 下载未完成时的降级方案。

4. 模型版本和 API 兼容性检查

AICore 还在 Developer Preview 阶段，API 变动风险存在。建议把 AICore 调用封装在单独的模块里，便于后续更新。

05 Compose Hot Reload 真机落地：顺便说一个让开发体验爆炸的新玩意

这周还有一条值得单独提的消息：Jetpack Compose 的 Hot Reload 终于可以在真实 Android 设备上跑了。

借助 compose-hotswan 方案，你改一个 Composable 函数，不需要重新编译整个 APK，几秒内就能在手机上看到变化。

很多 Compose 开发者对 Hot Reload 有点"听说过但没体验到"的感觉——因为官方的实现一直只在模拟器上比较稳定，真机上要么不支持，要么需要复杂配置。

compose-hotswan 的思路是绕开 R8/D8 的全量编译，通过字节码补丁的方式只替换改动的 Composable，配合 Compose 本身的重组机制触发 UI 刷新。

接入方式相当简洁：

// build.gradle.kts（app module）
plugins {
    id("com.tunjid.hotswan") version "1.0.0-beta"
}

hotswan {
    enabled = true
    watchPaths = listOf("src/main/java") // 监听 Composable 变化
}

然后在 debug 构建时，修改任意 Composable 保存，IDE 插件会自动推送补丁到设备。

对于 UI 迭代密集的项目（比如复杂的设计稿还原、动画调试），这个工具能省去大量等待时间。我认为它很快就会成为 Compose 开发标配。

06 Android 16 的 Edge-to-Edge：别以为加个 padding 就完事了

最后说一个有点让人头疼的事：Android 16 开始强制要求所有应用启用 Edge-to-Edge。

很多开发者的第一反应是：这不简单吗，加 WindowInsetsCompat 处理一下系统栏 insets 就行了。

但 ProAndroidDev 上这篇深度文章说得很直接：你的"简单修复"会在规模化场景下崩溃。

问题出在哪？

• 第三方库的系统栏处理可能和你的逻辑冲突。导航库、底部 Sheet 库、地图库——很多都有自己的 insets 处理逻辑，叠加起来就是灾难；

• 多 Activity 场景的 insets 状态不一致。有些 Activity 全屏，有些不全屏，切换时系统栏状态频繁变化，处理不好就是闪烁或者布局跳变；

• 软键盘弹出时的 insets 联动。Edge-to-Edge 下软键盘的行为变了，原来靠 adjustResize 的方案会失效；

• 自定义 View 里硬编码的状态栏高度。总有一些祖传代码写着 statusBarHeight = 72，这种时候就原形毕露。

更稳健的处理方式是在 Window 级别统一消费 insets，向子 View 分发时做明确的隔离：

// Activity.onCreate 里统一启用 Edge-to-Edge
enableEdgeToEdge()

// 在根布局的 View 上统一监听并分发 insets
ViewCompat.setOnApplyWindowInsetsListener(rootView) { view, insets ->
    val systemBars = insets.getInsets(WindowInsetsCompat.Type.systemBars())
    val ime = insets.getInsets(WindowInsetsCompat.Type.ime())

    // 顶部：只给状态栏区域的 View 消费 systemBars.top
    // 底部：需要同时考虑导航栏和 IME，取较大值
    val bottomPadding = maxOf(systemBars.bottom, ime.bottom)

    view.setPadding(
        systemBars.left,
        systemBars.top,
        systemBars.right,
        bottomPadding
    )
    // 消费掉 insets，防止子 View 重复处理
    WindowInsetsCompat.CONSUMED
}

Android 16 的正式发布还有几个月，现在开始排查项目里的 insets 处理逻辑，比上线前两天临时抱佛脚要好得多。

07 小结：2026 年 Android 开发的三条主线

梳理一下这周的信息量：

• 端侧 AI 正式生产力化。Gemma 4 + AICore 构成了 Android 本地 AI 的基础设施。对应用开发者来说，现在是布局端侧 AI 功能的好时机——先做方案设计和技术预研，等 AICore 正式版出来能快速跟上；

• 开发体验在加速改善。Compose Hot Reload 真机方案、Android Studio 本地 AI 补全——这些工具的进步是实实在在能感受到的效率提升；

• 系统强制适配在路上。Edge-to-Edge 强制化是 Android 16 确定要做的事，和之前 targetSdk 版本强制适配一样不可回避，越早做越省心。

端侧 AI 不是"酷炫的技术展示"，而是 Android 用户体验的下一个分水岭。网络不好的时候能用、不需要传数据出去、响应快——这三点加在一起，对很多场景来说是真实的产品差异。

下周继续关注 AICore 的正式版进展，以及 Android 16 Beta 的新动态。

原创技术内容，转载请注明出处。如有错漏，欢迎在评论区指出。