@徐yang哟
原创，禁止抄袭！
灵感来源
在查stm32的LL库部分函数的API时，有时会查到这种函数：
我不禁对__STATIC_INLINE产生了好奇。在查看源文件后，发现这个关键字的定义如下
很明显这个关键字是由 和 一起构成的。所以我们要分别知道这两个关键字的作用是什么。
关键字定义
static
在C语言中，函数默认情况下是global的。函数名前的static关键字使它们变成静态。不同于C语言其他的global的函数，访问static函数被限制到声明它们的文件。因此，当我们要限制对函数的访问时，我们让它们static。此外，在不同的文件中可以允许存在拥有相同函数名的static函数。
inline
inline是c99的特性。在c99中，inline是向编译器建议，将被inline修饰的函数以内联的方式嵌入到调用这个函数的地方。 而编译器会判断这样做是否合适，以此最终决定是否这么做。
static inline的优劣
根据上面的定义可以知道，如果static inline关键字生效（因为只有编译器有最终决定权，我们只有建议权，这点在后面会细讲），static inline会以一种类似于宏定义的方式，将调用被static inline修饰的函数的语句替换为那个函数体对应的指令，但实际上只是inline的作用，static作用其实是维护代码的健壮性，实验中会加以证明。 所以：
好处：
减少调用函数时的开销，如：
减少传参时可能引起的压栈出栈的开销。
减少PC跳转时对流水线的破坏。
坏处： * 代码所占体积会更大。
实验
目的：直观证明上述优点和缺点、探究static的作用
实验一 ：探究static inline对代码起到的影响
实验背景：
硬件平台：stm32f401re
IDE:stm32cubeMX、Keil(关掉指令优化)
库：LL库（仅仅初始化芯片）
编程语言：C语言、Arm指令
实验设计
尝试构造四个函数，这四个函数都是实现对四个参数相加，然后将结果返回，不同之处在于它们被不同的关键字修饰。
分别为：
注：在Armcc编译器的实现中，inline被实现为__inline
在这些函数中： Normal_Add是最简单的函数;
Static_Add是用static关键字修饰的函数;
Inline_Add是用inline关键字修饰的函数;
StaticInline_Add是用static inline关键字修饰的函数;
main.c
只罗列了关键部分
funcTest.h
funcTest.h文件其实涉及到一个问题，为什么Static_Add函数和Inline_Add函数还有StaticInline_Add函数要放在.h头文件里呢？
理由： 考虑下这三个函数的作用，我们希望它们被其他文件访问到吗？显然希望。那么，如果我们如果把static修饰的函数仅仅放在.c源文件中，其实其他的源文件就不能访问到那几个函数了。至于Inline_Add函数，其实对于armcc编译器，放不放在头文件都可以。但是Inline关键字其实不建议单独用，原因是不安全，最好配合static使用。这个在下一个实验可以看到
funcTest.h
实验结果
通过armcc生成的反汇编结果，我们来看一看这几个函数对应的汇编指令有什么不同。
main.s
functest.s
综合以上两个文件的代码，我们不难发现，非内联函数所用开销显然比内联函数的开销大。因为非内联函数不但用的指令多，还访问内存了，还用跳转指令破坏了流水线。所以肯定会慢很多。使用keil的debug功能，定量算它们所用时间差异。结果如下：
- Normal_Add函数与static_Add函数：
0.000037s = 37us - Inline_Add函数与StaticInline_Add函数：
0.000012s = 12us
虽然在这里，没有体现内联函数内存开销大的特点。但请想一想，如果一个内联函数被调用多次，那么这个函数就将被内联多次，代码就会被复制多次；但是一个非内联函数被调用多次，却并不会被复制多次。所以内联函数往往内存开销会大一点。
实验二 ：探究static inline和inline的区别
在讲这个之前，其实我们需要知道一点。就是static inline关键字和inline关键字无法决定被关键字所修饰的函数是否最后真正会被内联。我们其实只有建议权，只有armcc编译器才可以决定函数最后是否真正会被内联。
参见Armcc User Guide原文:
inline functions in C99
The C99 keyword inline hints to the compiler that invocations of a function qualified with inline are to be expanded inline. For example: The compiler inlines a function qualified with inline only if it is reasonable to do so. It is free to ignore the hint if inlining the function adversely affects performance. Note :The __inline keyword is available in C90.
Note: The semantics of inline in C99 are different to the semantics of inline in Standard C++.
Comiler decisions on function inlining
When function inlining is enabled, the compiler uses a complex decision tree to decide if a function is to be inlined.
The following simplified algorithm is used: 1. If the function is qualified with forceinline, the function is inlined if it is possible to do so.
2. If the function is qualified with inline and the option --forceinline is selected, the function is inlined if it is possible to do so. If the function is qualified with inline and the option --forceinline is not selected, the function is inlined if it is practical to do so. 3. If the optimization level is -O2 or higher, or --autoinline is specified, the compiler automatically inlines functions if it is practical to do so, even if you do not explicitly give a hint that function inlining is wanted.
When deciding if it is practical to inline a function, the compiler takes into account several other criteria, such as:
• The size of the function, and how many times it is called.
• The current optimization level.
• Whether it is optimizing for speed (-Otime) or size (-Ospace).
• Whether the function has external or static linkage.
• How many parameters the function has.
• Whether the return value of the function is used.
Ultimately, the compiler can decide not to inline a function, even if the function is qualified with forceinline. As a general rule:
• Smaller functions stand a better chance of being inlined.
• Compiling with -Otime increases the likelihood that a function is inlined.
• Large functions are not normally inlined because this can adversely affect code density and performance.
A recursive function is never inlined into itself, even if __forceinline is used.
浓缩成一句话：
开发者决定不了一个函数是否被内联，开发者只有建议权，只有编译器具有决定权。
这就造成了一个很disturbing的事情：除非你看到一个函数的反汇编代码，否则你很难确定他是不是内联函数。
下面，我们来看看一个被static inline修饰的非内联函数：
这个函数我们把他放在main.c中，并在main函数这样调用：。现在我们来看看他的反汇编代码:
惊不惊喜，意不意外？ 这个函数居然是被调用了的，而并没有被内联到调用它的地方。那么，为什么这个函数没变成内联函数呢？
我推断是因为我在这个函数中写入了太多指令，编译器判断如果它变成内联函数，会极大占用空间，所以不将它编译成内联函数。
但你还记得我们之前把Inline_Add函数放在哪里吗?放在了一个头文件。试想，如果这个Inline_Add在没有被编译成内联函数的情况下，被include到了多个源文件中，势必会产生函数重复定义的问题。 因此，我们要再加一个关键字static，才能避免这个问题。
结论
至此，我们直观地理解了static inline的特点，并知道了为什么static和inline要联合使用。
总结一下static inline什么时候用比较好：
当所修饰的函数语句较少时，尤其是只有一两条语句的函数。 当你所修饰的函数不是递归函数，而是正常的函数时。因为递归式不支持内联的。