性能优化：内存对齐、NEON指令集优化、缓存友好设计、多线程与OpenMP、性能分析工具
各位同学，今天我们来聊聊NDK开发中最硬核的部分——性能优化。说实话，我见过太多人写完C++代码就跑，结果在手机上卡成PPT。其实很多时候，不是算法不行，而是你根本没让CPU好好干活。这一章，我把这些年踩过的坑和总结的经验，一次性讲清楚。
核心观点：性能优化不是玄学，是工程。你只要搞懂内存怎么排、指令怎么选、缓存怎么用、线程怎么分，性能翻倍不是梦。
1. 内存对齐：让CPU少干点活
先问个问题：为什么结构体里字段顺序不同，大小会不一样？
我刚开始做NDK时也纳闷。后来发现，CPU读内存不是按字节来的，它一次读4字节或8字节。如果你的数据没对齐，CPU就得读两次，再拼起来。你说亏不亏？
// 不好的写法
struct BadStruct {
char a; // 1字节
int b; // 4字节
short c; // 2字节
}; // 实际占用：12字节（有填充）
// 好的写法
struct GoodStruct {
int b; // 4字节
short c; // 2字节
char a; // 1字节
}; // 实际占用：8字节（无填充）
我在项目中遇到过一件事：一个网络包解析结构体，因为没对齐，在ARM64上解析速度慢了3倍。后来我把字段按大小从大到小排，问题直接解决。
我的习惯：写结构体时，先放大的（int64、double），再放中的（int、float），最后放小的（char、short）。这样编译器填充最少，内存最紧凑。
2. NEON指令集优化：让CPU一次干更多活
ARM的NEON指令集，说白了就是SIMD（单指令多数据）。你想想看，普通加法一次加两个数，NEON一次加四个、八个甚至十六个。做图像处理、音频编解码时，这玩意儿就是神器。
我记得第一次用NEON优化一个YUV转RGB的函数，原来每帧要8ms，优化后直接降到1.2ms。当时我盯着屏幕看了半天，确认没写错。
#include <arm_neon.h>
// 普通加法
void add_arrays_normal(float* a, float* b, float* c, int n) {
for (int i = 0; i < n; i++) {
c[i] = a[i] + b[i];
}
}
// NEON优化加法
void add_arrays_neon(float* a, float* b, float* c, int n) {
int i = 0;
for (; i <= n - 4; i += 4) {
float32x4_t va = vld1q_f32(&a[i]);
float32x4_t vb = vld1q_f32(&b[i]);
float32x4_t vc = vaddq_f32(va, vb);
vst1q_f32(&c[i], vc);
}
// 处理剩余元素
for (; i < n; i++) {
c[i] = a[i] + b[i];
}
}
注意：NEON不是万能的。数据量太小（比如少于16个元素）时，函数调用和加载的开销反而更大。我一般只在处理几百个以上元素时才用NEON。
3. 缓存友好设计：别让CPU等你
CPU缓存有多快？L1缓存访问只要1ns，内存访问要100ns。差了100倍！所以你的代码如果总是缓存未命中，性能直接掉一个数量级。
我见过最典型的坑：遍历二维数组时，按行遍历和按列遍历，速度能差10倍。为什么？因为C++数组在内存中是按行存储的，按列遍历等于跳着读，缓存根本用不上。
// 缓存友好：按行遍历
for (int i = 0; i < 1024; i++) {
for (int j = 0; j < 1024; j++) {
matrix[i][j] *= 2; // 连续内存访问
}
}
// 缓存不友好：按列遍历
for (int j = 0; j < 1024; j++) {
for (int i = 0; i < 1024; i++) {
matrix[i][j] *= 2; // 跳着访问，缓存疯狂未命中
}
}
嗯，这里要注意：结构体数组（AoS）和数组结构体（SoA）的选择也很关键。如果你要频繁访问某个字段，用SoA更友好。比如粒子系统，把所有粒子的x坐标放一个数组，y坐标放另一个数组，这样遍历时缓存利用率极高。
4. 多线程与OpenMP：让所有核心干活
现在的手机至少8核，你只用一个核，那不是浪费吗？但多线程不是随便开几个线程就完事。线程创建、同步、数据竞争，每个都是坑。
我个人习惯用OpenMP，因为它简单。加一行#pragma，循环就自动并行化了。但要注意：不是所有循环都能并行，比如循环之间有依赖关系的就不行。
#include <omp.h>
void parallel_process(float* data, int n) {
#pragma omp parallel for
for (int i = 0; i < n; i++) {
data[i] = sqrt(data[i]); // 每个元素独立，完美并行
}
}
我曾经在一个音频处理项目里，用OpenMP把4个频段的滤波并行化，处理时间从15ms降到4ms。但后来发现，如果数据量太小（比如少于1000个采样点），线程调度的开销反而更大。所以，并行化也要看数据规模。
避坑指南：我曾经在OpenMP里直接操作共享变量没加锁，结果结果时对时错，查了两天才发现是数据竞争。记住：#pragma omp critical 或者用 reduction 子句来避免。
5. 性能分析工具：别猜，要测
我见过太多人凭感觉优化代码。结果优化了半天，发现瓶颈在别的地方。所以，先分析，再优化，这是铁律。
Android NDK开发中，我常用的工具有这几个：
| 工具 | 用途 | 我的使用频率 |
|---|---|---|
| simpleperf | CPU采样、热点函数定位 | ★★★★★ |
| perfetto | 系统级追踪、线程调度分析 | ★★★★☆ |
| Android Studio Profiler | 内存、CPU、网络实时监控 | ★★★★☆ |
| addr2line / objdump | 反汇编、定位崩溃行号 | ★★★☆☆ |
simpleperf是我最推荐的。它可以直接在手机上跑，采样精度高，还能生成火焰图。你一眼就能看出哪个函数最耗CPU。
# 使用simpleperf采样
adb shell simpleperf record -e cpu-cycles:u -f 1000 -o /data/local/tmp/perf.data -- ./your_app
# 生成报告
adb shell simpleperf report -i /data/local/tmp/perf.data --sort comm,dso,symbol
我记得有一次，一个图像处理函数怎么优化都慢。用simpleperf一看，发现80%的时间花在malloc上。原来我在循环里频繁分配内存。改成预分配后，性能直接提升5倍。你看，不分析根本想不到。
知识体系总览
下面这张图，我把本章的核心逻辑画出来了。你可以把它当作优化时的检查清单。
你看，这五个方面其实是环环相扣的。内存对齐影响缓存命中，缓存命中影响NEON加载效率，多线程又依赖数据布局。所以，优化是一个系统工程，不是改一行代码就完事。
最后说一句：性能优化没有银弹。每个项目、每个场景都不一样。但只要你掌握了这些底层原理，再配合工具分析，任何性能问题都能找到解法。