故事背景
没有无缘无故的重构，也没有无缘无故的优化。故事的开始要追溯到我们的项目加了某个新功能。
在此之前，项目的编译链接速度算是比较快，加上IDE编译缓存的作用，不完全编译的话，一般在10秒内就可以看到你修改的代码的效果。但为了这项新功能，我们使用了某个第三方SDK，这个SDK是以framework的形式提供的。从此之后link阶段的时间大大加长，大概需要五分钟。就算改一行代码，也需要等三分钟，喝上一杯茶之后才能看到代码改动的效果，大大影响了开发效率。产品的功能模块较多，很多其他模块的开发者也深受荼毒。
来看一下系统本身的一些framework的大小，系统相册Photos.framework是115KB，通讯录动态库AddressBook.framework是111KB，底层网络处理库CFNetwork.framework是295KB，等等。而我们使用的这个SDK，足足有400多MB！！所以链接速度巨慢也就不足为奇了。下文将用slow.framework表示此SDK。
因为这项新功能是重点核心功能，而这个SDK也是我们调研比较之后最能满足我们需求的服务提供方，因此去除或者更换SDK都不太现实。
兼顾产品需求和开发效率，只能想办法缩短编译链接时间。最直观的想法是，只有真正开发该新功能模块的才去link slow.framework，而其他模块的开发则不link它，这样大部分情况下的修改可以不受其影响。
因此我们的核心问题就是，如何选择性地链接动态库。
实践
选择性编译
假设我们不链接slow.framework了，那么使用到SDK中的接口的代码，肯定是编译不过的。因此在考虑怎样选择性链接framework之前，需要先修改代码，使得用到slow.framework的接口的地方都能有选择地被编译。
添加一个Build Configuration，叫Debug_Fast
Paste_Image.png
这个Debug_Fast选项表示不使用slow.framework，为其添加一个预定义宏，叫DEBUG_FAST
Paste_Image.png
原来使用SDK的代码都修改成这样：
#ifndef DEBUG_FAST
// use slow.framework
#else
// balabala
#endif
这样只有在定义了DEBUG_FAST之后，我们就不再使用slow.framework中的代码。
选择性链接
在这个问题上，我们尝试过两种做法。
多scheme多target
具体步骤如下：
- 当前的项目只有一个target，可以duplicate出另一个target，我们暂且称之为target_fast
- 修改target_fast中的Linked Frameworks and Libraries，将该slow.framework移除。
- 创建一个scheme，这个scheme对应到的Executable是target_fast，并且对应的Build Configuration是我们之前添加好的Debug_Fast，我们称之为scheme_fast。
Paste_Image.png
这样我们调试的时候，选择这个scheme_fast，就可以不链接slow.framework。
多scheme单target
上述的方法已经可以解决我们的问题，但是仍有一些副作用：
- 使用了多个target之后，以后我们每添加一个新文件，都需要将其加到两个target中，虽然Xcode会记住你的选择，但还是很丑陋。
- 多个target对于以后的维护并不友好，要改一项配置也需要同步到两个target中
因此我们最后采用了另外一种做法：多scheme单target，具体步骤如下：
- 先将slow.framework从Linked framework中移除
-
修改Other Linker Flags，配置Debug和Release -link slow.framework，而Debug_Fast则不链接
Paste_Image.png
- 同上创建多个scheme，其中scheme_fast对应到Debug_Fast这个Build Configuration。
这种解决方案更加简单轻量，对原有项目的入侵也更少，更好维护。
<b>遇到难题不要抱怨，方法总比困难多；解决了问题也不要轻易满足，可能存在更优雅的解决方案。</b>
网友评论