基于Cocoapods单工程多应用架构总结

我们产品目前需要进行多个产品分支的开发工作，包括一些有细微差异的分支应用以及Pad版本的开发，所以客户端这边需要进行重构来适应这种需求的出现，之前的那种Copy-paste的方式过于粗暴，已经无法适应于我们目前的发展。幸好，在重构之前听了一次阿里的技术分享，受益匪浅，收获很大，现场也跟阿里的架构师同学交流了很久，非常钦佩他们的开发理解和架构设计。正好这种经验也非常适用于我们目前的产品需求，就决定在这种需求起步阶段进行重构，以避免后续工作量的浪费。

在参考淘宝的方案，以及考虑到我们目前团队的状况之后，我们决定不像淘宝那样严格去做，毕竟淘宝团队的规模达到了百人级别，而我们目前所有的客户端人员加起来也只有3个人。。。不是一个量级，同时也不需要把代码编译为静态文件再合并。我们最后决定使用target + 基础模块拆分的情况来适应当前的开发，而不是把项目完全拆分为bundle，这样的成本过高，我们根本无法符合这样的工作量。

=================================================

应用架构

应用架构使用的工具是cocoapods和Xcode中的target，这个后面说到。这部分大致的思路主要参考淘宝大牛的演讲，以及下面引用中的2，8，9。

我发现对于APP架构的发展方向，其实大家的思路是一致的。首先是建立大量的基础库，这部分是独立于app和module之外的。然后在此基础上，使用独立的module来开发具体的功能模块，module是相对独立的，可以拥有自己独立的资源文件，自己独立的源码目录划分，甚至需要的时候可以单独打包为一个应用，比如facebook中相册功能，既是facebook app的一部分，又可以单独打包为facebook 相册应用。

对于各个moudule之间的解耦合，大家的思路其实也是相似的，就是使用自定义url来实现，统一由一个总线进行路由工作，同时这个可以扩展到跨平台。每个moudle都需要实现一个protocol，这个protocol中有对url的处理方法，以及其他一些处理方法。在做类似跳转的时候，所有的跳转都是通过自定义url来进行的。比如我现在要跳转到个人主页，那么要做的不是去初始化一个Controller，而是向路由总线中传入一个自定义url，比如showself://usercard/111，usercard会映射到controller，而111则会映射为一个参数。我们内部使用的是开源项目是JLRoutes，但是这个开源项目使用起来其实对于这种架构不是特别适用，需要进行重新架构才行。对于一些不支持的自定义url类型，比如低版本中，这时候淘宝做的是一个降级，即把这个自定义url跳转到一个webview页面来显示。

=================================================

CocoaPods

关于CocoaPods，我们使用的方式是，我们把基础类库包括Utility，UILib，BaseHTTP，LoginService作为单独的项目独立出来，然后在项目中使用Pod进行引用，这样的方式是为了后续iPad版本的开发，可以很容易复用基础类库，这样只需要简单进行UI层面的开发即可，同时如果项目有改进或者修改Bug，也能即使进行同步。其中使用的CocoaPods技术，在下面的参考文章中有详细讲述，尤其是唐巧的那篇文章，各方面的讲解很实用。当然，我最推荐的还是阅读官方的guide，非常简洁以及易懂，也不长，这个可能是pod技术自身很简单的缘故，比gradle要简单的太多了，但是又非常实用。

关于Pod的使用方式以及私有仓库，podspec文件的编写等内容，可以参考官方的文档，不再啰嗦，主要总结一下在进行架构的过程遇到的问题：

1. 关于静态库文件发布的问题

其实这个问题是比较简单的，可以直接参考官方文档podspec文件的编写