Jetpack Compose 生成代码直接 VMP 的可行性分析与分域保护策略

Compose 编译器生成代码的起源与内部结构

Compose 编译器插件在编译阶段会将每个用 Composable 注解的函数转化为一组内部合成方法。这些方法包括用于驱动重组的分发器、记录参数变化的标记和状态读取的 getter。这些生成代码并非由开发者直接编写，而是 Kotlin 编译器插件的产物，与 Kotlin 版本、Compose 编译器版本以及使用的 Compose UI 库严格耦合。

生成函数通过 Composer 传递快照与槽位信息，必须与 Compose runtime 的调用约定配合。变换后若开始组与结束组不再成对，常见现象是状态更新后界面不重组、remember 值意外重置，或日志出现组栈不一致；这些都比“页面能打开”更适合作为回归断言。

这类函数是 Compose 编译器实现声明式 UI 的调度代码，不是独立的业务逻辑。把生成胶水送进 VMP 会增加状态同步与排错复杂度，却没有直接保护计费、授权或算法判断。应把可测试的业务逻辑提取为普通 Kotlin 函数，让 composable 只负责读取状态和调用它。

编译器生成的代码通常包含特定的命名模式，如美元符号加 composable 后缀，这些是识别生成代码的关键特征。如果在保护清单中未明确排除这些特征，自动化工具可能会误将整个 UI 渲染路径纳入保护，导致应用在启动阶段因无法正确初始化 Composition 而崩溃。

稳定性诊断报告揭示的可保护边界

启用 Compose 编译器的 reports 功能后，构建输出中会包含每个可组合函数的稳定性判定。可重启与可跳过标签直接反映了函数在重组中的行为预期，以及函数参数是否被 Compose 视为稳定。这些标签虽然是编译器内部优化决策的依据，但同样可以作为判断生成代码复杂度与外部依赖深度的直接信号。

例如，一个被标记为可重启但参数均为稳定类型的 composable 通常内部生成代码较少，以简单的重组作用域包装为主；而一个不可跳过的函数往往伴随较重的副作用或非稳定参数读取，编译器会生成更复杂的差异比较和状态捕获逻辑。对这些生成复杂度的准确感知，能够帮助团队筛选出那些若进行虚拟化将大幅增加崩溃风险的候选函数。

稳定性报告不能直接给出适合 VMP 或不适合 VMP 的结论，因为报告的设计目标是诊断 UI 性能，而非评估代码脱离原运行时的适应能力。但报告可以作为一种静态筛子，初步排除所有参数不稳定且与 CompositionLocal 强相关的生成方法，形成 VMP 保护清单的第一道负向过滤。

在实际工程中，团队应当定期审查这些报告，特别是在升级 Compose 版本后。新版本的编译器可能会改变生成代码的策略，导致原本安全的函数变得复杂。通过持续监控稳定性标记的变化，可以及时发现潜在的保护风险点，避免在生产环境中出现意外的崩溃。

• 已开启 composeCompiler reports 并确认输出路径
• 逐项审查 restartable 和 skippable 标记，记录参数稳定类别
• 将存在 CompositionLocal 或非稳定 state 参数的函数加入 VMP 排除列表
• 对比不同版本构建的报告，识别生成代码复杂度的变化趋势

R8 优化如何重写生成函数的保护基础

R8 在发布构建中执行的代码缩减、优化和混淆操作会彻底改变 Compose 生成函数的最终符号与调用图。原本由编译器写入的桥接方法可能被内联，而部分不会触发的重组分支则被整体移除。这意味着在开发环境中看到的生成结构不能直接作为 VMP 保护点的选取依据，必须基于 release 构建产物的 mapping 文件和最终 DEX 内容进行决策。

R8 规则若用通配符保留整个 Compose runtime 与生成胶水，优化器就不能移除无用的重组路径，VMP 清单也会混入大量只负责 UI 调度的代码。应从真实反射、序列化或 JNI 入口出发编写最小规则，再用 mapping 和最终 DEX 检查哪些生成方法仍然存在。

正确的流程是将 R8 规则严格限定在业务入口和反射、JNI 等必要点上，让优化器先去剔除无用的生成代码，然后再从 mapping 中恢复真实符号，并与 compiler report 的 stability 信息做对照。只有经过这一步清理后的函数集合，才具备进入 VMP 范围评估的资格。

混淆后的类名和方法名会失去语义信息，这使得人工识别生成代码变得困难。因此，必须在 R8 处理之前保留原始的符号信息，或者利用 mapping 文件进行反向解析。只有在明确了最终二进制文件中哪些字节码对应于业务逻辑，哪些对应于框架胶水后，才能制定精确的保护策略。

VMP 技术定位及其与 Compose 生成代码的根本矛盾

应用加固中的 VMP 方案通常将目标函数编译为自定制的非标准字节码，并在一个与平台隔离的虚拟机中解释执行。该模型要求被保护的函数具有相对封闭的输入输出契约，不依赖外部环境中的可变状态和复杂调度协议。Compose 编译器生成的函数却恰恰相反，它们的核心职责便是操作 Compose 运行时内的可变快照系统并触发重组的级联传播。

当某个 composable 的业务状态变换函数被 VMP 保护后，其内部对 MutableState 或 State 对象的读写可能绕过 Compose 的状态通知机制。无论 VMP 实现对对象字段的访问如何仿真，都无法完整模拟 Snapshot 的读写跟踪逻辑，除非将整个 Snapshot 系统也移入保护域，这在工程上不可行。

即便仅保护不直接操作状态的计算逻辑，也需要考虑编译器会为该 composable 生成自动的 remember 位置和 init 守卫。这些生成方法在保护后若无法正确参与 Composition，就会导致 remember 缓存失效，进而引起 UI 重组的崩溃或无响应。从工程实践看，目前不具备将局部业务函数从这些生成胶水中完全干净剥离的通用静态分析能力。

这种根本性的架构冲突意味着，试图对整个 composable 函数进行黑盒虚拟化几乎注定失败。唯一的可行路径是深入函数内部，识别出纯粹的計算逻辑部分，并将其从框架生成的上下文中剥离出来单独保护。这需要极高的手工干预成本，且随着 Compose 版本的迭代，剥离的难度会不断增加。

通过编译器报告脚本识别生成方法的实际范围

区分业务函数与生成代码时，可以读取 Compose compiler 的报告与元数据。报告中的 restartable、skippable 记录用于描述 composable 的编译结果，可与 release DEX 和 mapping 对照，生成候选清单。它反映编译器输出，不等同于运行时性能结论，也不能单独决定 VMP 范围。

以下诊断脚本读取 Compose 编译器报告目录，遍历所有文本行，提取标记为 restartable 或 skippable 的条目，并根据函数签名是否包含编译器生成的特定后缀或参数中存在 Composer 类型，将条目分为生成胶水和可能包含业务的组合根。未被两类覆盖的条目则标记为需要人工审查。

脚本在无法找到任何报告文件或解析过程中出现格式异常时会以非零状态码退出，提醒构建流水线阻断发布。通过此类自动化解析，可以在 CI 阶段就将大量不适合保护的生成函数筛除，减少后续人工审核成本，并将注意力集中在人工审查后的业务状态变换函数上。

自动化脚本的优势在于其一致性和可重复性。人工审查容易受到疲劳和主观判断的影响，而脚本可以严格按照预定义的规则执行筛选。然而，脚本也无法解决所有问题，特别是对于那些边界模糊的函数，仍然需要经验丰富的工程师进行最终确认。

import sys
import os
import re

def parse_report(record_line):
    # 匹配 Compose 编译器报告的标准格式行
    pattern = r'^(restartable|inline)\s+(skippable|unskippable)?\s*scheme\("([^"]+)"\)'
    m = re.match(pattern, record_line)
    if not m:
        return None
    flags = [m.group(1), m.group(2)]
    scheme = m.group(3)
    return flags, scheme

def is_generated_glue(scheme):
    # 定义编译器生成代码的特征后缀
    glue_suffixes = ['$composable', '$invoke', '$changed', '$skippable']
    # 检查是否包含生成后缀或构造函数标记
    return any(suffix in scheme for suffix in glue_suffixes) or '<init>' in scheme

def main():
    # 从环境变量或默认路径获取报告目录
    report_dir = os.environ.get('COMPOSE_REPORT_DIR', 'build/compose/reports')
    if not os.path.isdir(report_dir):
        print(f'Error: Report directory not found at {report_dir}')
        sys.exit(1)
    
    files = [f for f in os.listdir(report_dir) if f.endswith('.txt')]
    if not files:
        print('Error: No report files found in directory')
        sys.exit(2)
    
    exclude_count = 0
    review_count = 0
    
    for fname in files:
        file_path = os.path.join(report_dir, fname)
        try:
            with open(file_path, 'r', encoding='utf-8') as f:
                for line_num, line in enumerate(f, 1):
                    parsed = parse_report(line.strip())
                    if not parsed:
                        continue
                    flags, scheme = parsed
                    if is_generated_glue(scheme):
                        print(f'EXCLUDE (glue): {scheme}')
                        exclude_count += 1
                    else:
                        print(f'REVIEW: {scheme}')
                        review_count += 1
        except Exception as e:
            print(f'Error reading file {fname}: {e}')
            sys.exit(3)
    
    print(f'Summary: {exclude_count} excluded, {review_count} for review')
    if exclude_count == 0 and review_count == 0:
        print('Warning: No valid entries parsed, check report format')
        sys.exit(4)
    return 0

if __name__ == '__main__':
    sys.exit(main())

反射与 JNI 入口必须彻底排除在 VMP 保护域外

任何通过 JNI 注册或 Java 反射调用的方法都有固定的符号名称和签名要求，这些方法必须在运行时保持原始可解析状态。Compose 生成代码虽然没有广泛应用反射，但在某些架构中开发者可能通过反射调用工具类或动态代理间接触发生成后的 Compose 入口。

按照 R8 keep 规则的最佳实践，反射入口应使用精确规则保留运行时需要的名称。至于这些方法能否进入 VMP，取决于具体工具是否保持反射可见性与调用约定，不能从 R8 文档直接推断。应在 release 产物中列出反射入口，默认排除，再通过目标工具和设备测试逐项评估。

JNI 方面，虽然生成代码极少通过 native 调用，但若项目在 JNI 层存在向 Java 层回调 Compose 触发点的路径，那么该回调路径上的每个 Compose 相关函数都必须排除 VMP。保持 JNI 可达链及对应的 Compose 入口函数的原生字节码，是防止 native 侧出现崩溃的唯一安全策略。

忽视这一边界条件是导致加固后应用闪退的常见原因之一。开发团队在进行 VMP 配置时，往往只关注业务逻辑的完整性，而忽略了底层框架对符号可见性的严格要求。建立自动化的反射入口扫描机制，可以有效避免此类人为疏忽。

利用 instrumented test 验证生成函数在保护后的行为一致性

Android instrumented test 提供真实设备上的 Compose 运行时环境，能够准确捕捉重组顺序、状态变更和副作用触发。通过分别在未加固和加固后 APK 上运行同一套 UI 交互测试，可以记录 composable 的渲染计数和重组次数，判断生成函数是否仍按照预期执行。

测试设计应覆盖目标业务 composable 在被 VMP 保护前后的多个交互路径，包括初始组合、状态更新和参数变化触发的重组。如果加固后的重组次数与顺序出现偏差，或者某个 remember 节点丢失导致状态重置，都表明部分生成代码的状态机已被破坏。在这种情况下，需要将该 composable 及相关的生成胶水从 VMP 范围中回退，并重新运行测试直到结果对齐。

需要注意的是，一次 instrumented test 通过并不代表保护方案在所有 API level 和厂商定制系统上都安全。Compose 运行时的内部实现会随补丁版本变化，因此测试矩阵需要覆盖主要 API 版本以及至少一台主流厂商系统版本的设备，并定期随 Compose 版本更新重新验证。

测试失败时的回滚机制至关重要。团队应当建立自动化的回滚流程，一旦检测到行为不一致，立即将受影响的函数从保护清单中移除，并触发重新构建。这种快速反馈循环能够最大限度地减少加固对应用稳定性的负面影响。

• 编写覆盖目标 composable 重组路径的 UI 交互测试
• 在原始 APK 上录制重组计数基线
• 对加固后 APK 运行相同测试并比对重组顺序
• 出现偏差时定位对应 composable，将其及生成方法移出 VMP 域并重新构建
• 将测试用例纳入 CI，每次 Compose 版本升级执行对比

构建部署决策链与最终保护范围确立

将 Compose 生成代码与 VMP 结合的正确实践不是直接找出可以保护的列表，而是建立起多层过滤的构建流水线：从稳定性报告获取生成复杂度信号，从 R8 mapping 恢复最终符号，通过脚本筛除编译器胶水，再经人工确认仅保留业务状态变换核心函数。

最终保护清单上的每个函数都应当满足三个条件：函数不直接读取 CompositionLocal 或持有 Snapshot 可变状态的写入权；参数全部为基本类型或已标记稳定的数据类；经过 instrumented test 验证保护后重组行为不变。任何条件不成立的函数都应退回至常规混淆和完整性校验保护。

达成上述条件后，还需将保护清单与 R8 配置一起冻结，并在版本发版流程中加入自动对比步骤，确保后续 Compose 编译器升级或代码变更不会意外引入新的生成胶水至保护域内。只有持续保持生成代码与业务函数的边界清晰，才能让 VMP 真正聚焦在防篡改和逆向分析的核心目标上。

开发人员负责标出可脱离 Compose runtime 独立测试的业务函数，保护配置维护者据此生成排除与候选清单，测试人员对照未保护产物执行重组、状态恢复和交互用例。三份记录必须绑定同一构建摘要；任一角色发现清单与产物不符，都先停止该范围的保护并重新生成基线。