在嵌入式平台上，Wi-Fi 驱动的内存占用会直接影响几件很实际的事：
- 系统还剩多少可用内存
- 长时间运行是否稳定
- 峰值业务能不能撑住
- 这套方案是否适合资源受限平台
所以看驱动内存，通常不只是记一个数字，更重要的是回答两个问题：内存主要花在哪，以及 有没有收缩空间。
1. 先把静态占用和动态占用分开
驱动内存一般先分成两部分来看。
静态占用
模块加载后就固定存在的部分，例如：
.text.data.bss
这部分反映的是驱动本身的基础成本。
动态占用
运行时随着业务变化而增长和回收的部分，例如：
- 发送 / 接收缓冲
- 连接状态相关对象
- 队列、缓存、控制块
- 按 STA 数量增长的分配项
动态内存更值得重点看，因为它和业务负载是直接绑在一起的。
2. 静态内存主要看什么
静态内存分析通常先看代码和全局资源的基础成本。
重点一般是：
- 模块整体大小
.text是否过大.data/.bss里是否有不必要的常驻对象
对资源受限平台来说，静态占用过大，意味着可裁剪空间不多，模块的基础成本也会偏高，后续留给别的业务的余量就更紧。
3. 动态内存为什么更值得盯
动态内存和业务状态一起变化，轻载、重载、长压下看到的结果可能完全不是一回事。
更该看的，通常是这些信息：
- 基础运行态占用是多少
- 建立连接后新增了多少
- 每增加一个 STA 的边际占用是多少
- 发送 / 接收路径里有没有大量临时对象
- 高负载下是否明显上涨，而且业务结束后回不来
这些信息比单次快照更有用，因为它们能看出驱动是在正常波动，还是在一路累积。
4. 怎么判断有没有泄漏风险
判断泄漏，很多时候不能只看某一个时刻的快照，还是要看趋势。
通常先看下面几项：
- 分配量是不是持续增长
- 释放量能不能跟上
- 业务结束后占用能不能回落
- 长时间压测后有没有异常累积
如果总分配一直涨、总释放明显跟不上，而且业务结束后占用也不回落，那就要重点往两个方向排查：一类是真正的泄漏，另一类是回收路径不完整，或者某些对象被异常持有太久。
5. 常见优化方向
减少动态申请频率
高频路径里的 kmalloc/kfree 往往代价不小。更常见的做法是把频繁申请回收到前面去处理，比如：
- 预分配
- 内存池
- 环形队列复用
控制按连接增长的对象规模
如果每增加一个 STA 都会明显拉高内存成本，就要继续拆：哪些对象必须常驻，哪些可以延迟创建，哪些状态本身还有压缩空间。
收敛调试版本额外开销
调试缓存、统计结构、额外日志对象，在开发阶段可能合理，但到了发布版本，通常都该重新收一遍，不然很容易把额外成本也算进驱动本体。
6. 一份分析报告至少应该回答什么
一份有用的驱动内存分析，不应该只留下“占用了多少”这一句，而应该把下面这些问题讲清楚：
- 静态占用是多少
- 基础动态占用是多少
- 峰值业务下占用是多少
- 占用大头在哪
- 哪些是协议必需成本
- 哪些是实现上还能继续优化的成本
7. 总结
Wi-Fi 驱动内存分析的价值，不在于把表填满，而在于把判断链建立起来：
- 先区分静态和动态
- 再找到主要消耗点
- 再判断它是结构性成本，还是实现层面的浪费
只有这条链建立起来，分析结果才真的能指导后面的优化，而不是只留下一个测试数字。
