IOS开发入门之ios 架构之谈
凌雪 2018-07-27 来源 :网络 阅读 935 评论 0

摘要:本文将带你了解IOS开发入门之ios 架构之谈,希望本文对大家学ios有所帮助

本文将带你了解IOS开发入门之ios 架构之谈,希望本文对大家学ios有所帮助


在开始谈app架构之前,曾经我一度认为,一个好的app就是需要有好的架构,如果没有一个我所认为的“好架构”,那么这个app就是很low。
      直到去年参加北京ArchSummit时,听了无数的公司他们对于产品的架构之后,我陷入沉思,因为我总在自己的认知里选出一个自己认为最好的架构,然后觉得其他架构都是垃圾。
    静下心来想想,每个产品都有自己不同的定位,如果抛开它们的定位,抛开它们的业务需求去谈如果给它们设计一个良好的架构,这简直是扯淡。
    更何况很多优秀的app架构也是由一开始很弱而慢慢变得越来越强。所以没有最好的架构,只有适合自己的业务的架构才是最好的架构,并且它是逐步地变强变大。
    本文将举一个例子来演示这个过程。
    那么,到底什么是架构?
   
    架构,又名软件架构,是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。
   
    以我的理解,它就像是人的骨架一般,一个人从小生长到大,围绕着整个骨架去发展,变高变胖。
    可以把app开发看成一个汽车工厂的流水线,造车身->喷漆->组装等等。即把整个开发流程切成一个个模块,每个模块相互独立,并发工作。这就是所谓app架构。
    没有架构的“架构”
      某天,一个叫Jim的开发者,他打算开发一个app,当然有一定计算机基础的他知道采用MVC的设计模式来构造app,于是一个星期后,终于能跑起来一个app,但是此时,看一下项目的目录结构:
    v1.0
   
   
    嗯,不错,我们不但能run,还能看出这个app用了MVC的设计模式耶。
    但是随着开发的页面越来越多,一个月后,app有了10个页面,此时,打开Controller、View、Model这三个文件夹之后,发现每个文件夹里面竟然有几十个文件,它们杂乱无章的洒落在一起。此时不断有用户向Jim反映,xxx地方怎么按钮位置不对,xxx位置网络请求不成功。
    头痛的Jim才知道,当初应该把粒度分的更细,于是又了接下来的架构。
    分模块的架构
    Jim把不同的功能模块放在一块儿,于是得到了如下的架构:
    v2.0
   
   
    但是不对,一些工具类,公用类该放哪呢?Jim仔细思索了一番,于是又将上述架构进行改进,得到以下的架构:
    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.
   
    它是一个能让你方便地管理第三方库的一个工具。
    于是,项目变成了这样:
    v2.2
   
   
    此时的架构已经满足了个人开发者,或者说是小型开发团队的需求了。
    多人开发的架构
      但是在一个初具规模的公司,上述的架构模式是远远不行的,试想一下,如果有20个人同时开发一个app,而此时大家就算各自负责自己的模块,如果同时有不同模块的同学添加或者删除文件,对于.xcodeproj文件来说,会有严重的冲突。那么,怎么办呢?
      想一下cocoapods的作用吧,其实利用它能做很多很多事,我们完全可以把Home、Detail、Login等模块抽出来,也把它视为“第三方库”(实际上可以算是二方库)。初期阶段可以这么做:
    v3.0
   
   
    可以看到我们把Home这个模块抽出来了。这么做有什么好处?
      如果我们把各个业务模块都抽出来,首先来说,可以解决冲突的问题,并且业务团队之间的工作不受影响,并且可以并行开发,也无需再等待其他兄弟业务团队的进度了。
    当其他业务团队的任务完成时,我们只需pod update,将代码升级到最新就可以了。
    并且当一个公司有多个app时,如果有公用的模块,用这种方式会更优雅。
    当然,如果你觉得直接指定git地址太low,你完全可以搞一个私有Spec,专门存放业务模块代码。
    子project模式的架构
    很多人会说上述方式很复杂,还不如采用在主工程下中放子工程(业务模块)来实现抽象:
    不合理的架构
   
    但是我觉得这个方式管理起项目很麻烦,更新模块代码、不同app间复用模块代码都会没上述的方式优雅,所以我觉得这种方式没有上述的好。
    对各个模块进行解耦
    现在虽然我们对各个模块进行了抽象,但是业务模块间还是互相引用,对于开发来说,虽然解决了代码的耦合问题,对于代码的引用关系却没有改变:
    v3.0
   
   
    上图才只有4个模块,如果有上百个模块的话,这个关系可以复杂成一个庞大的蜘蛛网,这对于后期维护来说,成本是巨大的。
    所以我们想,有木有好的方式来解耦呢,当然是有的,我觉得以下两个方式是很好的:
    middlemanurlRoute先来介绍middleman(中间人模式)
    middleman
   
   
      如图所示,我们只需将所有的模块依赖这个middleman,让middleman来处理各个模块的关系,模块A如果需要依赖模块B,完全可以考middleman来处理,并且返回模块A所需要的模块B的内容,这样就解决了解耦。
    再来说说urlRoute,其实这个方式类似于Facebook很早前的320结构了。
    思路就是将每个页面看成是一个url,设置一套路由规则,在页面打开时将url进行路由查找,然后这样一来,只要模块A按照既定的规则写好url,那么模块B依赖模块A时,只需根据url打开就行了。
    urlRoute
   
    middleman VS urlRoute
    两种方式各自有自己的优点和缺点,他们主要的区别在于:
    传参的方式所需维护的具体内容不同我更倾向于urlRoute,为什么这么说呢?
    由于本文讲的是app架构,这里就简单介绍下:
    如果一个页面出现了问题,我们可以用各种patch的方式来打补丁。但是,如果一个页面出现了致命的错误,打patch的成本过于高的话,此时如果用urlRoute,则有个妙招。
      我们可以更改appConfig(app的配置,可以从服务端动态更新),更改页面所对应的url,并且改成在路由规则里跳到webview的规则。
    这样之后,当跳到此模块时,则会打开对应的H5页面,而不是原来的有问题的页面。
    当然middleman也可以处理成这样,但是从实现的角度来说,显然是urlRoute更为优秀。
    总结
    当然,架构远远不是一篇文章能讲清楚的,也不仅仅只是结构层次方面的内容,还有例如push、hotpatch、动态化、appConf、Service中间件模块的具体实现,MVC\MVVM\MVCS设计模式等等。
    本文只是从最基础的地方展现具体业务模块的解耦方式,希望能起到抛砖引玉的作用。
      

本文由职坐标整理并发布,希望对同学们有所帮助。了解更多详情请关注职坐标移动开发之IOS频道!

本文由 @凌雪 发布于职坐标。未经许可,禁止转载。
喜欢 | 0 不喜欢 | 0
看完这篇文章有何感觉?已经有0人表态,0%的人喜欢 快给朋友分享吧~
评论(0)
后参与评论

您输入的评论内容中包含违禁敏感词

我知道了

助您圆梦职场 匹配合适岗位
验证码手机号,获得海同独家IT培训资料
选择就业方向:
人工智能物联网
大数据开发/分析
人工智能Python
Java全栈开发
WEB前端+H5

请输入正确的手机号码

请输入正确的验证码

获取验证码

您今天的短信下发次数太多了,明天再试试吧!

提交

我们会在第一时间安排职业规划师联系您!

您也可以联系我们的职业规划师咨询:

小职老师的微信号:z_zhizuobiao
小职老师的微信号:z_zhizuobiao

版权所有 职坐标-一站式IT培训就业服务领导者 沪ICP备13042190号-4
上海海同信息科技有限公司 Copyright ©2015 www.zhizuobiao.com,All Rights Reserved.
 沪公网安备 31011502005948号    

©2015 www.zhizuobiao.com All Rights Reserved

208小时内训课程