AES256 CBC与GCM性能测试异常：iPhone模拟器结果不符，求排查原因

1. 模拟器架构的硬件加速差异 #

Apple的CryptoKit是专为自家*ARM架构（A系列芯片）*做了深度硬件加速优化的，但在x86架构的iPhone模拟器上，CryptoKit无法利用ARM的加密硬件模块，只能回退到纯软件实现。而CommonCrypto在x86平台上已有多年优化，甚至可能调用了x86的AES-NI硬件指令，因此在模拟器环境下性能反而超过CryptoKit。

2. 测试流程的额外开销 #

• 字符串转Data的处理：如果测试代码中，CryptoKit路径的字符串转Data逻辑存在额外编码/解码开销（比如重复转换、使用低效编码方式），会拉高整体耗时。
• 计时范围偏差：如果计时包含了密钥/IV初始化、对象创建等非加密核心逻辑，CryptoKit的对象初始化开销可能比CommonCrypto的C风格API更高，单次测试下这种差距会被放大。

3. GCM模式的额外计算（模拟器放大差异） #

GCM模式除加密外，还包含Galois域的认证计算。ARM硬件可并行处理加密与认证，但在模拟器的软件实现中，这部分额外计算的开销会被显著放大；而CBC仅做加密/解密块处理，无额外认证步骤，进一步拉大了两者的耗时差距。

4. API使用方式的问题 #

如果CryptoKit代码未采用高效写法，也会增加耗时：

• 重复创建AES.GCM.SealedBox或加密器实例，而非复用
• 分多次小数据块加密，未使用一次性批量处理
• 存在不必要的内存拷贝操作

验证建议 #

• 在真实iPhone 13 Pro Max设备上测试，这才是CryptoKit优化的目标环境，应该能看到GCM性能优于CBC的预期结果。
• 优化测试代码：确保计时仅覆盖加密/解密核心逻辑，排除字符串转Data、对象初始化等前置/后置步骤；统一两种测试的输入输出处理流程。
• 调整CryptoKit代码：复用加密器实例，采用批量数据处理方式，减少不必要的内存操作。

内容的提问来源于stack exchange，提问作者Kim Mỹ