Expo SDK 52中expo-modules-core升级导致的Android运行时崩溃问题分析

问题背景

在Expo SDK 52环境中，当开发者将expo-modules-core从2.1.4版本升级到2.2.0版本时，Android应用在运行时会出现崩溃问题。这个问题特别出现在使用Azure DevOps构建管道和SauceLabs测试平台的特定场景中。

问题现象

应用在启动后立即崩溃，错误日志显示与Dex文件加载相关的断言失败。具体错误信息表明系统在加载classes2.dex文件时出现了问题，检查条件"is_primary_dex"失败。这种崩溃现象在多种Android设备和系统版本上都能复现。

根本原因分析

经过深入调查，发现问题源于以下几个技术层面的交互：

1. expo-modules-core 2.2.0的变化：该版本引入了Jetpack Compose支持，这增加了约56,000个方法，可能导致Dex文件结构发生变化。

2. 构建管道的特殊性：Azure DevOps中使用Gradle任务构建时，与直接使用命令行构建表现不同，这暗示构建过程中可能存在微妙的差异。

3. SauceLabs的重新签名：SauceLabs平台在上传AAB文件后会提取APK并重新签名，这一过程可能与某些Dex文件处理方式不兼容。

解决方案

最终确定问题的根本解决方案是：

1. 避免使用Azure DevOps的Gradle任务，改用Bash脚本直接执行gradlew命令构建应用包。

2. 构建脚本修改：将原来的Gradle任务替换为简单的Bash脚本执行，确保构建过程更加干净和直接。

技术启示

这个案例为我们提供了几个重要的技术启示：

1. 构建工具链的影响：不同的构建方式（Gradle任务 vs 命令行）可能产生不同的结果，特别是在处理复杂依赖和Dex文件时。

2. 依赖升级的全面测试：即使是看似简单的依赖升级，也可能因为与其他系统组件的交互而产生意想不到的问题。

3. CI/CD管道的验证：在设置自动化构建管道时，需要全面验证每个环节对最终产物的影响，特别是当涉及多平台协作时。

最佳实践建议

基于此案例，建议开发者在类似场景中采取以下措施：

1. 在升级关键依赖时，进行全面的构建和运行时测试，包括在不同平台和设备上的验证。

2. 对于复杂的构建管道，考虑简化构建步骤，减少中间环节可能引入的问题。

3. 当遇到难以解释的运行时崩溃时，可以从构建产物的差异入手调查，而不仅仅是检查源代码。

4. 保持构建环境的可复现性，便于问题排查和团队协作。

通过这个案例，我们可以看到现代移动开发生态系统中各组件间复杂的相互作用，以及全面测试和验证的重要性。