4、资源受限设备特性：计算能力、存储空间、能量约束对算法选择的影响
说实话，做IoT这么多年，我踩过最大的坑就是——拿PC上的思维去写嵌入式代码。
你想想看，服务器上跑个加密算法，毫秒级响应，内存随便几百兆。但换到一颗Cortex-M0芯片上，主频几十MHz，RAM可能就16KB。这差距，不是「优化一下」就能抹平的。
这一节，我就把三类核心约束掰开揉碎了讲。每个约束背后，都是真金白银的教训。
4.1 计算能力：不是所有算法都跑得动
先看一个我早年犯过的错。
当时做智能门锁，选了RSA-2048做身份认证。在开发板上跑得好好的，一上量产芯片——握手延迟超过3秒。用户指纹按上去，门要等半天才开。产品经理差点没把我吃了。
为什么会这样？因为开发板主频200MHz，量产芯片只有48MHz。RSA的大数模幂运算，在低主频下就是灾难。
核心结论：算法的时间复杂度必须与CPU主频、指令集架构匹配。
我习惯把IoT设备的计算能力分成三个档次：
| 等级 | 典型芯片 | 主频范围 | 适合算法类型 |
|---|---|---|---|
| 超低端 | Cortex-M0, 8051 | 8~48 MHz | 对称加密（AES-128）、轻量哈希（SHA-256截断）、XOR混淆 |
| 中端 | Cortex-M4, ESP32 | 80~240 MHz | 椭圆曲线（ECC-256）、轻量TLS、LZ4压缩 |
| 高端 | Cortex-A系列, RISC-V 64位 | 400 MHz~1.5 GHz | RSA-2048、完整TLS 1.3、全同态加密（部分） |
你看，选算法不是「哪个安全选哪个」，而是「哪个跑得动选哪个」。我曾经在M0上硬跑SHA-512，结果一个哈希计算吃掉200ms——这在传感器数据流里根本不可接受。
我的经验：在选型阶段，先拿目标芯片的datasheet，算一下每条指令的时钟周期。然后把你候选算法的核心循环，用最笨的方式估算一下执行时间。如果超过50ms，就要警惕了。
4.2 存储空间：ROM和RAM都是硬约束
存储约束分两块：ROM（Flash）放代码和常量，RAM放运行时数据。
我见过最极端的案子——一颗Zigbee节点，Flash 64KB，RAM 4KB。你猜怎么着？连一个完整的IP栈都塞不进去。
算法对存储的影响，我列几个关键点：
- 代码体积：一个完整的TLS握手库，ROM占用可能超过50KB。而轻量化的DTLS 1.2，可以压到15KB以内。
- 运行时内存：RSA-2048的私钥操作，需要临时缓冲区存放中间大数，动辄几KB。而ECC-256的临时内存需求，通常只有几百字节。
- 常量表：有些算法（如查表法CRC、S-Box）需要预计算常量。如果Flash吃紧，就得改成运行时计算——但会牺牲速度。
避坑指南：我曾经在OTA升级场景里，选了差分压缩算法bsdiff。压缩率确实好，但解压时需要把新旧版本同时加载到RAM里。结果设备RAM只有32KB，根本装不下。最后只能换用xdelta，虽然压缩率差一点，但流式解压只需要几KB缓冲区。
我建议你在做存储预算时，留出20%的余量。因为后期加功能、修bug，代码体积只会涨不会跌。
4.3 能量约束：算法是耗电大户
能量约束，说白了就是电池能撑多久。
很多人以为耗电大头是无线发射。其实不然。我实测过一个温湿度传感器：
- 发送一帧数据（20字节）：耗电约 0.5 mJ
- 执行一次AES-128加密：耗电约 0.05 mJ
- 执行一次RSA-2048签名：耗电约 15 mJ
看到了吗？一次RSA签名的耗电，是发送30帧数据的量。如果你的设备每天做100次签名，电池寿命直接砍半。
能量约束对算法选择的影响，我总结成三条原则：
- 非对称加密能不用就不用。优先用对称密钥+密钥派生。实在需要非对称，选ECC而不是RSA。
- 减少计算频率。比如传感器数据聚合，先缓存10个值，算一次哈希，而不是每来一个值算一次。
- 利用硬件加速。很多MCU内置AES、SHA硬件模块。用硬件算一次AES，比软件快10倍，省电5倍以上。
我的习惯：在项目初期，我会用电流探头实测每个算法阶段的功耗。然后画一张「能量预算表」，把每小时的耗电算清楚。如果超过电池容量的1/1000，就要重新选算法。
4.4 三类约束的权衡：一张图说清楚
这三类约束不是孤立的。它们互相牵扯，你压了计算量，可能内存就涨了；你省了内存，可能功耗就上去了。
下面这张图，是我做项目时常用的决策框架：
你看，三个约束像三根绳子，拉着算法选择往不同方向走。你不可能同时做到「计算最快、内存最小、功耗最低」。能做的，是找到那个「最不坏」的平衡点。
4.5 实战：一个温湿度节点的算法选型
最后，我拿一个真实项目收尾。
设备：电池供电的温湿度节点，Cortex-M0+，32KB Flash，4KB RAM，AA电池供电，要求续航2年。
需求：每5分钟上报一次数据，数据需要加密和完整性校验。
我的选型过程：
- 加密：选AES-128-CCM。硬件加速，RAM占用仅需几百字节。不选RSA，因为一次加密耗电顶得上半天上报。
- 完整性：用AES-CCM自带的MAC，不额外加SHA。省代码体积，省计算。
- 密钥管理：预置对称密钥，不上PKI。因为设备没有网络连接能力，密钥在出厂时烧录。
- 数据聚合：每5分钟采集一次，但加密和发送改为每30分钟一次。中间5次数据在本地做简单均值，减少加密次数。
结果：实测续航2.3年。算法部分（加密+校验）占整体功耗的12%，无线发射占65%，其余为休眠和MCU开销。如果当初选了RSA，功耗占比会飙升到40%以上，续航直接掉到1年以内。
嗯，这就是资源受限设备的现实。算法选型不是纸上谈兵，是每一毫安时、每一字节、每一毫秒都要算清楚的硬功夫。