iOS应用架构现状分析

iOS从2007年诞生至今已有近10年的历史，10年的时间对iOS技术圈来讲足够产生至关可观的沉淀，尤为这几年的技术分享氛围不管国内国外都显得异常活跃。本文就iOS架构这一主题，结合开发圈里讨论较多的几种主流方式，再配以博主本身的理解，作下现状分析。给本身作下知识梳理的同时，也指望能引入新的思考。

架构的定义

过去6年多几乎绝大部分时间都浸淫在iOS平台，翻阅过很多关于架构的文章，发现众人对架构的理解很有些差别，整体来讲可分为四类：

第一类：精简型应用架构

这类架构的文章分析主要仍是围绕MVC展开，以苹果自带UIViewController优劣为出发点，再结合主流的MVP，MVVM，MVCS等变种进行分析演变。这类的探讨重点在于M，V，C三类角色的定义以及之间的数据事件流向的规范。不少小型应用所面临的问题及其架构层面的解决方案都集中在这一类。

第二类：综合型应用架构

对于用户量级在千万级或以上的应用来讲，MVC这一层面的思考已没法应对业务疯狂增加所带来的负担。这类应用每每须要专业资深的架构师出面进行深层次的思考设计，业内很多大厂如淘宝，天猫，携程等都作过一些分享。不过到了这一层级的战斗，不光考验架构师的技术积累，更重要的是架构师对于业务的总体理解。我姑且把这类架构名之为：综合型应用架构。综合型应用架构通常不会提到MVC，更可能是在探讨“层”与“模块”的划分和耦合。后面我会就几个经典样本作下详尽深刻的分析。

第三类：深度优化的综合型应用架构

综合型应用架构是应对大规模业务增加的必经之路，一旦架构成型，后期业务膨胀会不停的打磨架构自己，产品自己对体验质量的追求会要求架构师和技术团队不停的优化架构细节。这种优化能够分为两块，第一是组件或模块划分的粒度愈来愈细，第二是组件模块的深度优化，好比网络层的深度优化，sqlite优化（多线程，FTS，安全等），数据加密，HotFix，Hybrid等，一些开源的第三方库已不能知足要求，须要团队本身重造轮子。这一层面的架构设计涉及面广，对架构师，团队技术人员的技术深度和业务理解能力有较高要求，短短一篇技术文章每每只能蜻蜓点水的介绍个大概，每一次优化几乎均可以做为一个专题来说解。

第四类：组织型应用架构

这类架构在第三类的基础之上更进了一步，除了关注系统层面的架构设计以外，更对团队或部门之间协做方式，各系统模块的演进方式，产品发布流程等都作了规范。除去业务膨胀带来的压力，人员增加，各团队协做依赖加强等都会对app的质量，迭代速度产生影响，这些问题也须要从架构层面去解决。这类结合技术架构和组织架构的分享还比较少。

以上四种类型的架构又能够看作通常App从简至繁，公司规模随之增加的演进过程，技术圈绝大部分的架构类分享文章均可以归为上述四类。

对于什么是架构的学术定义，彷佛你们并不太在乎，更关心的是如何解决自身项目当下的问题。虽然在我看来第一类架构更像是在讨论设计模式，但这里面确实又有很是多的知识能够深刻挖掘，这里就把全部“解决应用总体设计问题”的讨论都归类于架构这一话题。

值得一提的是，架构师的视野和积累通常都受限于本身所经历项目及业务的规模。若是有机会，工程师仍是应该尽量去BAT这类巨头级公司历练一下，知识深度和广度的构建绝非纸上可得。

样本分析

这里我以圈子里几个经典的架构分享为样本，作下解剖分析。样本的选取主要以搜索引擎及评论热度为标准，排名不分前后。

第一类样本：

若是一篇架构的文章是以探讨MVC为起点，颇有可能做者所说的架构就能够被归为第一类样本。

Xcode自带的UIViewController模板常常被戏称为“Massive View Controller”，主要是由于UIViewController除了负责Controller生命周期回调以外，还承担了View和Controller的工做。很多架构的探讨以此为基础，将Controller的M，V，C三个角色从新进行划分，又或者衍生出MVP，MVVM，MVCS，VIPER等其余组织方式。从新定义MVC以后，网络访问，持久化，安全等通用功能模块每每就由Controller或者Presenter负责了，这些负责业务逻辑的功能类直接依赖于成熟稳定的第三方基础库，好比AFNetworking，FMDB等。

可是，应付过复杂庞大业务模块的工程师会会有经验，不管以何种方式组织Controller，数据流向和事件传递再清晰合理，单纯代码量的膨胀就足以让Controller变得难以维护。MVC，MVP，MVVM均可以变得Massive。想象一下将10本书放在床头，你能够按翻阅频次，阅读习惯将书合理摆放，但当你面对100本书的时候，已不是如何摆放的问题，而是须要一个新的书柜。说到这里我挺服VIPER的，五个角色划分，尝试能够在床头放下100本书的Pattern。咱们先来看看“10本书”的样本。

样本名：iOS 架构模式–解密 MVC，MVP，MVVM以及VIPER架构

英文原版，中文翻译版

做者：Bohdan Orlov

这篇文章是第一类样本的典型，综合对比了MV（X）系列架构。咱们来看下主要论点。

论点摘要：

文章认为优秀的架构具有如下三个特质：

Balanced distribution of responsibilities among entities with strict roles.

能把代码职责均衡的划分到不一样的功能类里。

这是咱们关注架构的原动力，有个粗浅的评判标准，同一个业务单位（Controller）里面，不能一个类1000多行代码，另外一个类却只有10来行。当咱们考虑网络请求的代码是该放在controller当中仍是model当中的时候，在“代码量”上要作到“雨露均沾”，不能少数类“养分不良”。因此不论你的MVC，MVP或者VIPER是如何划分职责的，各个角色所承担的职责应当看起来是均匀分配的。

Testability usually comes from the first feature.

方便测试

测试是个有趣的话题，不一样公司实践差别很大。我知道有些团队的产品质量严重依赖于QA团队，有些却干脆没有测试团队，彻底依赖于开发人员本身保证质量，这两种风格通常取决于CTO的技术决策，和公司大小倒没多少关系。对于开发人员自测的状况，若是代码架构清晰，各角色职责分配合理，易测性是随之而来的副产品。

Ease of use and a low maintenance cost

易用且方便维护

易用是针对团队里的开发人员而言的。其实究竟是用MVP仍是MVVM，或者MVVM里数据如何流动，这些具体的规范到底采用何种形态不是最重要的问题，关键是在团队全部成员能有一致的认识，不管是写代码仍是Debug都能快速切入。

围绕上面三个特质，做者一一分析对比了传统MVC，Apple MVC，MVP，MVVM，VIPER在这三方面的表现，结论是到底选用哪一个纯粹是我的口味问题。相较于结论，做者对各个Pattern的角色定义及分析才是真正有价值的部分，咱们在阅读评断其余相似架构文章的时候，也应该重在了解做者对于角色的理解。你们能够基于这一点，阅读下其余一些相似的文章。VIPER理论上并不能归类于MV（X）系列，而是突破了MVC的思考方式，好比定义了Router处理页面流程，这对架构师是个很好的思路，在对MV（X）从新设计的时候也应该能有新的思考，所谓“君子不器”。

MV（X）都是以MVC为原型进行变化，MV（X）到底如何使用没有教科书式的标准答案，关键在于架构师和团队各成员能达成一致的认识，在遇到问题时能不断的作调整重构，遇到难以跨越的瓶颈时，能跳出MV（X）寻找解决方案。

第二类样本：

在开始分析第二类样本以前，有几个概念比较重要，是咱们深刻讨论各个综合型样本的前提。组件，模块，层的定义。

在我看来，组件是比模块更小的功能单位，不具有业务属性，只处理基础通用的问题，相似于工具箱。好比咱们给NSString写的Category提供base64，给NSDate写的Category作日期格式化等等。

模块较之组件粒度更大一些，另外最重要的区别是带有业务属性，和业务场景相关联。好比购物车模块，注册登陆模块，支付模块等等，模块每每会对一些通用的组件产生依赖。

层是另外一个维度的概念了，我日常阅读技术文章的时候，发现不少人会把模块和层的概念混淆，能够用一张图来区分模块与层的概念：

对于层不容许跨层访问，也就是说A不能直接访问C，下层不容许访问上层，B没法知道A的实现细节。层的概念可类比TCP/IP协议栈。模块就灵活多了，A，B，C三者之间能够任意访问依赖。因此通常来讲层对架构的约束更高，但使得依赖更规范好维护，模块在复杂的场景下很容易结成一个网状的依赖形态，难以维护。第二类项目架构都是围绕层与模块的划分所展开，有的有严格的层次结构，有的不分层次，经过接口严格规范各模块交互，有的两者结合，在某一层内再作模块划分，下面咱们分析的样本都属于上面三种情形。

在开始分析以前，建议你们全篇了解下iOS开发圈关于组件化的讨论，我以前作过一个总结，里面有各篇文章连接：http://mrpeak.cn/blog/module/ 。

样本名：饿了么移动APP的架构演进

原文地址

做者：圣迪

这篇架构演进的讲解是典型的从第一类到第二类的过渡，可简化为如下几步：

1.使用传统MVC快速迭代App。

2.业务发展，有多个App须要开发，开始组件化，使用CocoaPods进行组件管理，目标是并行开发和代码重用。架构图以下：

若是读过上面关于组件化的文章，这张架构图就很好理解了，在作好模块划分和管理以后，经过Router的方式将让各模块产生耦合。这种架构方式已初步具有一个应付大规模业务增加的架构模型。

3.Hybrid，几乎全部运营类主导的App都会最终投入Hybrid的怀抱，运营团队对快速上线的要求只能在H5或者Hybrid上得以实现，不过这和架构自己关系不太大，是另外一个大的话题。

4.React-Native & Hot Patch，这和第三步相似都是由运营驱动，几乎是全部内容运营型app的必经之路。

这四步的演化文章介绍的还比较粗略，更多的细节（好比Router内部实现，业务组件和非业务组件的分工，组件间耦合的方式等）没有介绍，或者饿了么App端也还在探索当中。

第三类样本：

样本名：携程移动APP架构优化之旅

原文地址

做者：陈浩然

携程App端的架构演化在饿了么架构基础之上，多了不少优化的细节。

提到了对于基础SDK组件和业务组件的具体划分：

核心功能SDK化

? 通信、定位、Hybrid、数据库、登陆、分享、基础库等

? 直接提供给其余BU独立App使用

公用业务功能组件化

? 地图、日历、城市、图片、通信录等13个公共组件

? 减小各BU重复开发工做量

性能数据指标采集：

? 网络性能:网络服务成功率、平均耗时、耗时分布

? 定位:获取经纬度成功率、城市定位成功率

? 启动时间、内存、流量等指标

? 多种纬度:系统、App版本、网络情况、位置等

网络优化

? 使用TCP长链接实现网络服务

? 根据网络情况2G/3G/4G/WIFI进行调优参数

? 根据链接/读/写不一样阶段使用重试机制

? 使用IP列表避免DNS解析失败或者劫持

? 根据网络延迟选择服务端IP(使用Ping)

? 使用ProtocolBuffer+Gzip减小Payload

还有Hybrid，HotFix，React Native等就不一一列举了，这些细节性强的分享有很高的学习价值，能对刚涉足某一块优化的架构师起到方向指引的做用。

这些看似简单的划分每每很考验架构师的大局观和经验，涵盖面和合理的粒度掌控才能让技术团队的开发工做高效并行。

第四类样本：

样本名：Facebook iOS Architecture

视频地址1 视频地址2

做者：Facebook

除了和上面样本相似的模块化，组件优化的介绍以外，还有两方面新的信息：

在关于Infrastructure的介绍当中有张示意图介绍团队分工：

视频当中不光介绍了基础组件，业务模块的划分，和说明了这些划分对应的团队是如何进行协做。

• 最底层的是基础设施团队，负责基础SDK的开发，能够对应以前谈到的非业务组件。

• 中间层是业务团队，按业务模块进行划分，一个业务对应一个团队，团队负责全平台的开发，业务团在开发过程中可反过来回馈基础SDK。

• 最上面是产品的发布团队，产品发布团队配合业务团队对产品的发布周期和质量作保障。

在Facebook iOS客户端架构设计当中有关于model层介绍：

以前看过很多架构分享文章，少有对model层深刻探讨的，通常提到都是一笔带过。model层涉及app数据持久化，以及runtime的状态维护，对app的稳定性和迭代效率起到相当重要的影响。

Facebook的model layer采用的是immutable策略，model虽然能被各层访问，但model的修改统一由model layer提供接口。上层业务团队一旦想修改某个model property，须要向model layer维护团队提出申请，这一设计对状态的维护至关谨慎。

个人思考

将架构的类型归为上述四类也是方便本身搭建关于架构的知识体系，看架构类文章的时候先作好分类再按类别查漏补缺汲取养分。我我的在第一类，第二类架构方面作过一些尝试和积累，第三类优化上作过一些知识总结。

第一类好比以前的技术分享：

iOS的应用层CDD架构 http://mrpeak.cn/blog/cdd/

这种优化应用层的架构方式是在MV（X）系列基础之上新的尝试，已在公司项目当中有过实践，成效尚可。

第二类好比:

用Swift搭建数据驱动型iOS架构 http://mrpeak.cn/blog/swift-dda/

搭建数据驱动型Android架构 http://mrpeak.cn/blog/dda-android/

用了Swift和Java实现相同的架构思路，这种架构方式也是从已有成熟的项目当中总结提炼而来。

第三类主要是优化和总结的文章：

App安全之网络传输安全

HTTP 2.0的那些事

iOS组件化方案

iOS网络请求优化之DNS映射

关于架构的总结就到这里，以上全是一家之言，一则梳理，二则分享，任何想法建议，欢迎交流。

文章转自  愚公编程的简书