性能度量指标：延迟、吞吐量、上下文切换开销、内存拷贝开销、加解密开销
各位同学，今天我们来聊聊TEE性能优化的核心——度量指标。说白了，就是怎么量化你的TEE到底快不快、好不好用。
我刚开始接触TEE时，也踩过不少坑。有一次，我优化了一个接口，自我感觉良好，结果一测延迟反而变高了。后来才发现，我根本没搞清楚该测什么指标。所以今天，我把这五个关键指标掰开揉碎了讲给你听。
延迟（Latency）
延迟，就是一次TEE调用从发起到返回的总时间。我习惯把它叫做“端到端的等待时间”。
举个例子，你调用一个安全存储接口，从普通世界（REE）发起请求，到安全世界（TEE）处理完返回数据，这中间的时间就是延迟。
延迟的组成：
- 上下文切换时间（REE ↔ TEE）
- 数据拷贝时间（共享内存搬运）
- 实际业务处理时间（加解密、签名等）
我在项目中遇到过一个问题：某款芯片的TEE延迟总是比预期高30%。排查了很久，发现是共享内存的分配策略有问题。每次调用都重新分配内存，而不是复用。嗯，这里要注意，内存分配本身也是延迟的一部分。
吞吐量（Throughput）
吞吐量，说白了就是单位时间内能处理多少TEE请求。通常用“每秒操作数”（OPS）来衡量。
你想想看，延迟低不代表吞吐量高。比如一个接口延迟只有1ms，但一次只能处理一个请求，那吞吐量也就1000 OPS。另一个接口延迟5ms，但可以并行处理10个请求，吞吐量反而能达到2000 OPS。
| 场景 | 延迟 | 并行度 | 吞吐量 |
|---|---|---|---|
| 串行处理 | 1 ms | 1 | 1000 OPS |
| 并行处理 | 5 ms | 10 | 2000 OPS |
我建议你在做性能优化时，先搞清楚业务是延迟敏感型还是吞吐量敏感型。比如支付场景，延迟更重要；而批量数据加密，吞吐量才是关键。
上下文切换开销
这是TEE性能优化的“大头”。每次从REE切换到TEE，CPU要保存当前状态、加载安全世界状态、切换页表、刷新TLB……这一套下来，开销可不小。
我曾经在一个项目中，发现上下文切换占了总延迟的60%以上。怎么优化的？减少切换次数。把多个小请求合并成一个大请求，一次切换搞定。
避坑指南：我曾经把上下文切换时间估算得太乐观，结果上线后性能不达标。后来我养成了一个习惯：在芯片上实测切换时间，而不是看数据手册。因为实际环境中的缓存命中率、总线竞争都会影响切换开销。
上下文切换开销通常包括：
- CPU模式切换（SMC指令执行时间）
- 页表切换（TLB刷新）
- 缓存污染（切换后缓存几乎全失效）
- 中断屏蔽与恢复
内存拷贝开销
TEE和REE之间不能直接访问对方的内存，数据必须通过共享内存来传递。这就涉及内存拷贝。
你想想看，一次拷贝就是一次memcpy。如果数据量大，比如几MB的图片，拷贝时间可能比实际处理时间还长。
我建议你这样做：
- 零拷贝技术：使用DMA或者IOMMU，让硬件直接搬运数据
- 内存复用：预分配共享内存池，避免每次调用都分配释放
- 批量传输：把多次小数据拷贝合并成一次大数据拷贝
注意：内存拷贝不仅仅是时间开销，还会消耗宝贵的带宽。在带宽受限的嵌入式设备上，这可能成为瓶颈。我曾经在一个IoT项目上，就因为频繁的内存拷贝导致WiFi吞吐量下降，最后不得不改用指针传递+同步机制。
加解密开销
TEE的核心功能之一就是加解密。但加解密操作很“吃”CPU资源。
我习惯把加解密开销分为两部分：
- 算法开销：对称加密（AES）比非对称加密（RSA、ECC）快得多
- 密钥管理开销：加载密钥、派生密钥、存储密钥
举个例子，AES-128加密1MB数据，在主流ARM Cortex-A上大概需要几毫秒。但如果是RSA-2048签名，一次就要几十毫秒。所以，能用对称加密就别用非对称，这是基本原则。
优化建议：
- 使用硬件加速器（如ARM CryptoCell）
- 预计算密钥派生，避免每次调用都派生
- 批量处理：把多条数据合并后一次性加密
- 选择合适的密钥长度：128位AES通常够用，没必要上256位
我记得有一次，客户抱怨TEE的签名操作太慢。排查后发现，每次签名前都要重新加载密钥。优化后，我们把密钥缓存在TEE的安全内存中，签名时间直接降了80%。
知识体系总览
下面这张图，是我自己总结的TEE性能度量指标关系图。你可以看到，五个指标之间是相互影响的。
从图中你可以看到，延迟和吞吐量是“表”，上下文切换、内存拷贝、加解密是“里”。优化“里”才能改善“表”。
实战中的权衡
在实际项目中，你不可能同时优化所有指标。我个人的经验是：
- 交互式应用（如人脸支付）：优先优化延迟
- 批量处理（如日志加密上传）：优先优化吞吐量
- 资源受限设备（如MCU）：优先减少上下文切换和内存拷贝
- 安全等级要求高：加解密开销是必须付出的代价，但可以优化密钥管理
一个小技巧：我习惯在代码里埋性能计数器。每次TEE调用都记录五个指标的实际值。上线后，通过分析这些数据，能快速定位瓶颈。比如，如果上下文切换时间占比突然升高，说明业务逻辑可能触发了过多的TEE调用。
好了，这五个指标就是TEE性能优化的“五把尺子”。下次你拿到一个TEE接口，先别急着优化，用这五个指标量一量，看看短板在哪里。记住，没有度量就没有优化。