共计 1048 个字符，预计需要花费 3 分钟才能阅读完成。
1）和原生 IOS 开发的技术一样，编译出.a 动态库（下文称之为 libtclib.a，蕴含简略的 native_add 函数）。
2）确认 flutter 的 dart 插件产生的我的项目的 IOS 局部应用 obj- c 语言：
3）应用 xcode 关上 Runner.xcworkspace，在 linkBinaryWithLibraries 里把 libtclib.a 蕴含进来，还须要在 LibarySearchPaths 把 libtclib.a 的门路放进去。
4）main.dart 里的内容：
内容和上一篇《flutter 应用 C 代码库—Android 篇》一样。
编译运行，会发现，编译失常通过，但运行时，报错了，报告找不到相应的 native_add 这个 symbol。
我偶尔在 AppDelegate.m 文件中测试了对 native_add 的调用：
而后编译运行，意外发现整个 APP 运行失常了！
剖析起因：如果没有在 AppDelegate.m 里对 native_add 的调用，那么 xcode 的编译器（留神是编译 obj- c 的，不是 flutter 的编译器）会认为 native_add 没有用，从而不链接进可执行文件中（我还没有弄明确 xcode 的编译器是基于单个函数、还是分段、还是基于动态库文件来决定链接的。比方，同一个动态库有两个函数 A 和 B，如果 A 在 AppDelegate.m 被调用，B 没有，那么 xcode 链接时，是只链接 A 还是整个动态库都链接进去？），这是因为 xcode 的编译器是不晓得在 main.dart 调用了 native_add 的。等到 main.dart 去 lookup 这个 native_add 函数 symbol 的时候，天然就找不到了。
所以，为了保险起见，在 flutter 中须要间接用到的函数（间接用到的函数没关系，xcode 会主动剖析而后链接进来），在 AppDelegate.m 中先调用一遍。然而如果真的调用一遍，耗时耗电不说，还会产生副作用，为此，用一点技巧：
先写一个 touch 函数，这个 touch 函数能够放在动态库中，也能够放在 AppDelegate.m 中，而后在 AppDelegate.m 中，这么调用一下：
touch_api(0);
这样，等于坑骗了一把 xcode 编译器，让他误以为咱们的利用中调用了相干的函数，就把相干的函数链接进来了。
留神，如果这样是不行的：
xcode 编译器还是有点智商的，它会剖析出并没有真正调用 native_times 和 native_add 两个函数，所以不会去链接。但如果变成下面的调用形式，就能够骗过 xcode 编译器了。
