1. 课程导入与工程化认知
在研究与开发工作中，我们经常遇到这样的场景：一段在 MATLAB 中运行良好、曲线漂亮的算法，一旦要交付给软件团队、嵌入到 C/C++ 工程、部署到嵌入式设备或云端服务，就变得"水土不服"。问题往往不在于算法本身，而在于我们从未把"算法"当作一个需要工程化交付的产品来看待。本课程要解决的核心问题，就是打通从研究原型到工程部署之间的这条链路，并在此过程中建立性能优化的全局视角。
一、算法生命周期：原型与部署是两种不同的工作模式
一个算法从想法到落地，通常经历如下阶段：问题建模 → 原型验证 → 数据与接口固化 → 代码生成/移植 → 集成测试 → 性能调优 → 上线维护。在原型阶段，我们关心的是"算法对不对"，可以用向量化、临时变量、可视化调试、动态类型等一切便利手段；而在部署阶段，我们关心的是"跑得快不快、稳不稳、能不能嵌入目标平台"，此时内存、时延、确定性、可移植性成为硬约束。
这两者的差异可以用一个具体例子说明。假设我们要实现一个滑动平均滤波器，原型代码可能写成：
% 原型写法：清晰、向量化，但每次调用都重新分配内存
function y = movavg_proto(x, N)
y = filter(ones(1,N)/N, 1, x);
end这段代码在桌面 MATLAB 上运行毫无问题，但如果它要被部署到采样率 10 kHz 的嵌入式目标上，每调用一次就分配一次长度为 N 的系数向量，会带来不可接受的内存抖动和实时性风险。工程化写法需要预分配状态、固定系数、避免动态内存：
% 工程化写法：状态持久化，系数预计算，无动态分配
function y = movavg_deploy(x, state)
persistent buf idx
if isempty(buf)
buf = zeros(1, state.N);
idx = 1;
end
buf(idx) = x;
idx = mod(idx, state.N) + 1;
y = sum(buf) * state.invN; % invN = 1/N 预先算好
end可以看到，同一个算法，两种写法在"正确性"上等价，但在工程属性上完全不同。理解这种差异，是本课程所有后续内容的认知基础。
二、MATLAB 在工程化链路中的定位
MATLAB 不是一个"只能做研究"的工具，它在工程化链路中扮演着多重角色：
- 算法设计与验证平台：快速迭代、可视化、与理论对照，是原型阶段效率最高的环境。
- 参考实现（Golden Reference）：部署代码的正确性最终要与 MATLAB 结果比对，MATLAB 版本是"标准答案"。
- 代码生成源：通过 MATLAB Coder、Embedded Coder、GPU Coder，可直接生成 C/C++、CUDA 代码，减少手工移植错误。
- 测试与标定环境：用 MATLAB 生成测试向量、驱动硬件在环（HIL）测试、分析实测数据。
但 MATLAB 也有明确的局限：解释执行带来的运行时开销、动态类型导致的难以静态分析、工具箱依赖带来的部署许可问题、以及在某些实时场景下无法满足确定性时延。因此，工程化的关键不是"抛弃 MATLAB"，而是明确哪些环节用 MATLAB、哪些环节必须离开 MATLAB。
三、性能优化的全局视角
很多工程师一提到性能优化，第一反应是"改算法"或"换语言"。但在工程实践中，性能瓶颈往往分布在多个层次。下图给出了从算法原型到部署系统的完整链路，以及各环节的主要优化手段与典型瓶颈，帮助建立全局视角。
这张图想传达的核心信息是：性能优化不是单点技巧，而是分层决策。算法层的复杂度降低（例如把 O(N²) 的矩阵运算改为 O(N log N) 的 FFT）带来的收益，往往比在实现层反复微调循环大一个数量级。因此，在动手改代码之前，先问自己：瓶颈在哪一层？
四、本课程的学习路径与预期产出
基于上述认知，本课程将沿着工程化链路逐步展开：从 MATLAB 代码的性能剖析与向量化，到数据类型与内存管理，再到 MATLAB Coder 代码生成、MEX 加速、GPU 并行，最后到与 C/C++ 工程的集成、测试与部署。每一节都会围绕"实际对象—关键操作—可观察变化—结果判断"展开，而不是停留在概念介绍。