在上篇博客中提到可以把通用代码打成静态库,然后多个项目可使用多个 Framework 包裹这些静态库的方式共享通用代码,详见最后的思维导图!这个方案的确是可行的,但是只用了两天就被干掉了!原因是太不方便了!程序刚好崩溃到打到静态库中的方法了,没法搞断点去一步步 debug ,降低了开发的效率!这种方案也不是完全没有用武之地,比如现在有几和后台商议好的加密算法,一般不需要人人都知道,省得泄漏出去,这时就可以把加密算法打成库,然后需要用的时候把库加到自己的 Framework 里就行了!

因此需要继续摸索共享代码的方式,既要满足需求,又要方便调试!方便调试的话没办法,只能开放源码了,所以我想到了 Workspace ,其实我早该想到的,不知道为何我先想到的是使用 Framework 包裹 静态库的方式,按道理我应该先想到使用 Workspace 共享才对,因为从一开始我就是使用 Workspace 管理的工程!

简单说下 Workspace 和 Project 的关系,一般情况下一个项目对应一个工程(Project),有时候为了方便管理就把几个工程都放在一起,这时就要使用 Workspace 了,因为这是 Project 是平级的关系,不是包含的关系,当然 Project 也可以包含,今天不说包含的事哈,既然是平级的,那总得来个管事的吧,这就是今天的主角— Workspace !说得直白些就是她管理了 N 个 Project ,实质上就是记录了 Project 的索引而已,最常见的是使用 Pods 的工程,会自动生成一个 Workspace,包含了原来的 Project 和 名为 Pods 的 Project !

思考是有局限性的,或者说之前的考虑是陷入了一个胡同里了,觉得搞成静态库后者框架才能共享,其实不用,比如现在的工程目录结构是这样的:

  • workspace
    • projectA
      • libCC
    • projectB

其实 B 工程是可以直接添加 A 工程里的代码的,对于 B 而言就把 projectA 当做一个文件夹就好了,不要考虑太多,加入的时候不要选择 copy 就行了,这样其实就是共享了!为了凸显 libCC 是通用的,因此我们整理下工程目录:

  • workspace
    • libCC
    • projectA
    • projectB

这样从结构上就能一目了然了,接下来 A 、B 都添加下 libCC 到工程,都不要 copy !!! 即只添加引用,文件仍旧在 libCC 目录;由于实体文件仍在 libCC 里面,所以无论 A 、B 谁修改了源码,对方都可以立马更新,如果添加新的文件,则需要再次添加下哦!

libCC 可以到 Workspace 里和 A、B 同级,也可以不添加,我就没添加,感觉是多余的,因为没其他的用途,不会因为没有在 Workspace 里添加索引就导致 A、B找不到 libCC 了。

其实,共享 libCC 跟 Workspace 没多大关系,只不过 A、B 是 由 Workspace 管理的,如果你不用 Workspace 的话,直接创建个 libCC 的文件夹也能共享,只要不 copy 就行了!这才是重点!!

比起包裹静态库而言,这种方式才是我想要的呢!