随着业务的发展或者项目的增长，为了更好的维护代码，在项目的开发后期都会对项目的一些公有组件和基础业务进行封装。最近由于一个人需要负责多个SDK的开发，后续公司可能还会继续开发新的SDK，对于每一个新的SDK的开发，如果我都从底层的基础库（网络，解析，工具类等）再到业务逻辑层都重新开发的话，会需要很多的时间，并且在开发过程中会发现不同的SDK除了具体的业务逻辑不一样的话，其他基本一致。所以对于需要快速的去试错开发一个SDK的话，抽离封装基组件库和公共业务势在必行，不然代码拷来拷去很容易出错，吃力不讨好。
多SDK架构
整体的架构思想就是，抽离公共组件库和公共业务代码库，做成一个通用的libCommon.a供其他SDK使用，这样做的好处很多：
- 通用库一次开发，享用一生；
- 新的SDK开发，只需要专注具体SDK业务逻辑的开发；节约开发时间；
libCommon.a分解
在通用基础库中主要包括两部分，一部分是公共组件库，一部分是公共业务模块。
- 公共业务模块：我们一般只需要SDK部分帮我们启动业务就好，或者再增加一些回调处理。他的头文件一般也只会有一个。
- 公共组件模块：有很多子模块，例如数据解析，字符串处理，存储、网络基础库等等，这样的话我们就需要公开很多的头文件，因此我想到了先使用Framework来封装公共组件，然后再让libCommon.a来引用Framework，最后我在SDK中通过libCommon.a使用这个Framework。整体架构就会变成下面这样：
拆分架构
错误的原因
首先说下为什么我要把多个公共组件制作成一个Framework，因为这样的话SDK在调用的时候不需要添加很多的.h头文件。想法是很完美，但是现实却很残酷，我在实现的过程中libCommon.a引用了Framework，但是我继续在我的libSDK1.a里面继续用的时候，发现会报错(Undefined symbols for architecture x86_64)，在Framework里面定义的方法都找不到了，出现这个的原因就是没有在运行的时候没有找到实现文件，所以动态去链接找方法的时候出了问题。这里我们需要明白Static Library和Framework的编译原理。
- Static Library编译的时候会把所有的代码编译进去；
- Framework编译的时候只是进行链接，函数在调用的时候才会去寻找实现，所以在编译过程Framework里面的组件代码没有被编译到libCommon.a里面，所以我们在上层调用的时候还是需要引用Framework的，所以这里就不适合我的开发场景了，因为我封装的Framework是不想对外公开的，只能我内部知道和使用。
最后我还是回到原点，将公共组件编译成静态库然后公开多个头文件来处理。
网友评论