最近有时间可以将最近工作上的一些东西稍微整理一下。
一、首先说说问题
- 在日常工作中，我们可能会遇到如下一些问题：
- 多个客户端都会使用通用的基础模块，比如一些网络工具库、第三方库、数据解析等等功能。像这些功能基本是每个应用中都会用到的，但是如果公司每个产品创建工程时重新进行搭建，那么就会导致很多重复的工作，而且还有许多坑需要来回填。
- 如果是多人维护的多个客户端，会造成由于代码风格不同，导致的后期维护的问题，比如有些逻辑一个开发人员是这么写的，另一位开发人员是这么写的，诸如此类。。。
- 每当赶进度的时候可能莫名就会将一些业务逻辑和另外一些业务逻辑的代码进行了深度的耦合性。当你默然回首想要修改的时候，下一版的需求已经在路上。。。
- 经历过之后，我们团队觉得很有必要搞出一套通用性高，拓展性强并且适合我们公司所有客户端的框架结构，来适配公司多个客户端，可能的话还可以对外输出 SDK。故事就这样开始。
二、思路
- 通用性 就是要保证多个客户端都可以无缝接入。
- 拓展性 就是要保证每个客户端都可以在这个框架的基础上进行二次迭代开发。
- 耦合性 除此之外，还要保证多个功能之间的低耦高聚，这样后期维护起来也比较方便。
三、解决方案
-
先上一张拙图：
图 - 讨论再三，这里我们分为三层的设计，因为觉得结构简单清晰，这里仅展示是框架的简单设计结构：
- 基础层：
基础层是存放一些应用的基础功能的模块，像数据解析，网络服务，还有更多通用的第三方工具模块。 - 基础功能输出层：
在这个层次中是基于我们各个客户端会用到的功能模块，因为我们在设计的时候，希望能够达到客户端选配的目的，客户端可以自定义选择模块。比如 A 客户端不需要热修复功能模块，那么通过本地的配置文件来达到这样的效果。 - 业务逻辑输出层：
在这层我们会处理我们的通用基础核心业务逻辑，我们想达到的效果是，提供给各个客户端基础核心业务逻辑所需要的接口和回调，让客户端更多的精力来专注处理他们本身的业务开发与 UI 视图。
- 基础层：
四、工具
- Cocoapod
使用私有 Pod 库之间的依赖，可以解决发版升级等很多问题。 - Git
公司私有的 Git 服务器
五、一些问题和不足
- 对于基础功能输出层，其实还可以继续进行拆分，之所以没有继续拆，好听点说觉得现在这套框架还可以满足公司客户端的需求，不好听点说---懒。产品总是追着我跑。
- 在设计模块的时候难免会出现一些基础业务模块与模块间的耦合，图中的初始化模块就是为了解决一些耦合而作为中间层才设计的。这些问题会在后面版本慢慢去解决。
- 多个客户端使用的时候，难免会遇到想要修改一些核心逻辑的问题，有些时候可以通过提供代码回调的方式来设置一些操作，但是后来有些核心的逻辑确实会有很大的差别，由于精力有限，现在的做法是每个客户端去打branch，在 branch 自己先去针对本端的逻辑去修改，然后 Pod 中会指向我们的 branch 地址。
- 希望以后有机会也会继续按照我们的思路来修改这套框架。
