在上篇博客中提到可以把通用代码打成静态库，然后多个项目可使用多个 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
- projectA
其实 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 就行了！这才是重点！！
比起包裹静态库而言，这种方式才是我想要的呢！
