iOS移动端架构的那些事

叁歲伎倆 2022-07-12 18:07 197阅读 0赞

在开始谈app[架构][Link 1]之前，曾经我一度认为，一个好的app就是需要有好的架构，如果没有一个我所认为的“好架构”，那么这个app就是很low。  
直到去年参加北京ArchSummit时，听了无数的公司他们对于产品的架构之后，我陷入沉思，因为我总在自己的认知里选出一个自己认为最好的架构，然后觉得其他架构都是垃圾。  
静下心来想想，每个产品都有自己不同的定位，如果抛开它们的定位，抛开它们的业务需求去谈如果给它们设计一个良好的架构，这简直是扯淡。  
更何况很多优秀的app架构也是由一开始很弱而慢慢变得越来越强。  
**所以没有最好的架构，只有适合自己的业务的架构才是最好的架构，并且它是逐步地变强变大。**  
本文将举一个例子来演示这个过程。

--------------------

#### 那么，到底什么是架构？ ####

> 架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

以我的理解，它就像是人的**骨架**一般，一个人从小生长到大，围绕着整个骨架去发展，变高变胖。  
可以把app开发看成一个汽车工厂的流水线，造车身->喷漆->组装等等。即把整个开发流程切成一个个模块，每个模块相互独立，并发工作。**这就是所谓app架构。**

--------------------

#### 没有架构的“架构” ####

某天，一个叫Jim的开发者，他打算开发一个app，当然有一定计算机基础的他知道采用**MVC**的设计模式来构造app，于是一个星期后，终于能跑起来一个app，但是此时，看一下项目的目录结构：

![1240][]

v1.0

嗯，不错，我们不但能run，还能看出这个app用了**MVC**的设计模式耶。  
但是随着开发的页面越来越多，一个月后，app有了**10个页面**，此时，打开Controller、View、Model这三个文件夹之后，发现每个文件夹里面竟然有**几十个文件**，它们杂乱无章的洒落在一起。此时不断有用户向Jim反映，xxx地方怎么按钮位置不对，xxx位置网络请求不成功。  
头痛的Jim才知道，当初应该把**粒度分的更细**，于是又了接下来的架构。

--------------------

#### 分模块的架构 ####

Jim把不同的功能模块放在一块儿，于是得到了如下的架构：

![1240 1][]

v2.0

但是不对，一些**工具类，公用类**该放哪呢？Jim仔细思索了一番，于是又将上述架构进行改进，得到以下的架构：

![1240 2][]

v2.1

嗯，这看起来才像样嘛。

--------------------

#### Cocoapods ####

慢慢地，Jim发现网上有很多可以现成拿来用的第三方框架，而他同时也学习了**Cocoapods**这个神器。  
什么是Cocoapods：

> CocoaPods is a dependency manager for [Swift][] and [Objective-C][] Cocoa projects. It has over eighteen thousand libraries and can help you scale your projects elegantly.

**它是一个能让你方便地管理第三方库的一个工具**。  
于是，项目变成了这样：

![1240 3][]

v2.2

此时的架构已经满足了个人开发者，或者说是小型开发团队的需求了。

--------------------

#### 多人开发的架构 ####

但是在一个初具规模的公司，上述的架构模式是远远不行的，试想一下，如果有20个人同时开发一个app，而此时大家就算各自负责自己的模块，如果同时有不同模块的同学添加或者删除文件，对于`.xcodeproj`文件来说，会有严重的冲突。  
**那么，怎么办呢？**  
想一下**cocoapods**的作用吧，其实利用它能做很多很多事，我们完全可以把`Home、Detail、Login`等模块抽出来，也把它视为“第三方库”（实际上可以算是二方库）。初期阶段可以这么做：

![1240 4][]

v3.0

可以看到我们把`Home`这个模块抽出来了。  
**这么做有什么好处？**  
如果我们把各个业务模块都抽出来，首先来说，可以解决**冲突**的问题，并且业务团队之间的工作不受影响，并且可以**并行开发**，也无需再等待其他兄弟业务团队的进度了。  
当其他业务团队的任务完成时，我们只需`pod update`，将代码升级到最新就可以了。  
并且当一个公司有多个app时，如果有**公用的模块**，用这种方式会更优雅。  
当然，如果你觉得直接指定[Git][]地址太low，你完全可以搞一个**私有Spec**，专门存放业务模块代码。

--------------------

#### 子project模式的架构 ####

很多人会说上述方式很复杂，还不如采用在**主工程下中放子工程（业务模块）**来实现抽象：

![1240 5][]

不合理的架构

*但是我觉得这个方式管理起项目很麻烦，更新模块代码、不同app间复用模块代码都会没上述的方式优雅，所以我觉得这种方式没有上述的好。*

--------------------

#### 对各个模块进行解耦 ####

现在虽然我们对各个模块进行了抽象，但是业务模块间还是互相引用，对于开发来说，**虽然解决了代码的耦合问题，对于代码的引用关系却没有改变：**

![1240 6][]

v3.0

上图才只有4个模块，如果有上百个模块的话，这个关系可以复杂成一个庞大的蜘蛛网，**这对于后期维护来说，成本是巨大的。**

所以我们想，有木有好的方式来解耦呢，当然是有的，我觉得以下两个方式是很好的：

*  middleman
 *  urlRoute

先来介绍**middleman（中间人模式）**

![1240 7][]

middleman

如图所示，我们只需将所有的模块依赖这个**middleman**，让**middleman**来处理各个模块的关系，模块A如果需要依赖模块B，完全可以考**middleman**来处理，并且返回模块A所需要的模块B的内容，这样就解决了**解耦**。

再来说说**urlRoute**，其实这个方式类似于Facebook很早前的**320**结构了。  
思路就是将每个页面看成是一个url，设置一套路由规则，在页面打开时将url进行路由查找，然后这样一来，只要模块A按照既定的规则写好url，那么模块B依赖模块A时，只需根据url打开就行了。

![1240 8][]

urlRoute

--------------------

#### middleman VS urlRoute ####

两种方式各自有自己的优点和缺点，他们主要的区别在于：

*  传参的方式
 *  所需维护的具体内容不同

我更倾向于**urlRoute**，为什么这么说呢？  
由于本文讲的是app架构，这里就简单介绍下：  
如果一个页面出现了问题，我们可以用各种patch的方式来打补丁。但是，如果一个页面出现了致命的错误，打patch的成本过于高的话，此时如果用urlRoute，则有个妙招。  
我们可以更改appConfig（app的配置，可以从服务端动态更新），更改页面所对应的url，并且改成在路由规则里跳到webview的规则。  
这样之后，当跳到此模块时，则**会打开对应的H5页面**，而不是原来的有问题的页面。  
当然middleman也可以处理成这样，但是从实现的角度来说，显然是urlRoute更为优秀。

--------------------

#### 总结 ####

当然，架构远远不是一篇文章能讲清楚的，也不仅仅只是结构层次方面的内容，还有例如push、hotpatch、动态化、appConf、Service中间件模块的具体实现，MVC\\MVVM\\MVCS设计模式等等。  
本文只是从最基础的地方展现具体业务模块的解耦方式，希望能起到抛砖引玉的作用。

[Link 1]: http://lib.csdn.net/base/architecture
[1240]: /images/20220709/96b5035994fd45ed82d8714a877402dd.png
[1240 1]: /images/20220709/16deb421e68f403696d9f7957d917989.png
[1240 2]: /images/20220709/f4507946c9134fe8bc432ef55ddd613a.png
[Swift]: http://lib.csdn.net/base/1
[Objective-C]: http://lib.csdn.net/base/objective-c
[1240 3]: /images/20220709/cedc6ee8702042b1b4e0dd5a296da8a1.png
[1240 4]: /images/20220709/d1d77b69ee44434991cbbde6716423be.png
[Git]: http://lib.csdn.net/base/git
[1240 5]: /images/20220709/f643562c04a84548849aec9227c3befa.png
[1240 6]: /images/20220709/b890b51a0f574b21b644f182ff24884a.png
[1240 7]: /images/20220709/f5c6583e5b5840968b2d3149ac8e9de7.png
[1240 8]: /images/20220709/4aae882c73e2488498703d8ef86fcd4f.png