首页 >iOS开发

iOS 从0到1搭建高可用App框架(二)

2017-07-06 16:40 编辑: 枣泥布丁 分类:iOS开发 来源:臭码农

前言:

本文是继《iOS 从0到1搭建高可用App框架》之后,通过项目实践以及同行交流思考总结出来的一些新的架构思想,但初心仍不变,目的为搭建高可用App框架,保持框架底层健壮的同时让代码更清晰,为满足后期顶层业务开发时的需求,避免出现风格迥异的代码。

架构图:

743749-077e818f4b5f9f6e (1).png

架构图

QQ截图20170706162447.png

效果图

思考:

  • 一、面对一个版本迭代频繁,改版频率高的项目,如何设计才能避免代码越改越乱?

  • 二、当业务极其复杂时,如果减轻VC的压力,让代码更清晰?

  • 三、如何正确选择第三方框架?都需要考虑哪些因素?

正文:

直面问题,解决问题:

一、许多创业项目为了赶时间上线,前期没有框架设计,没有代码规范,每个人随意发挥,不出几个月就会出现 产品体验差、崩溃率飙升、开发进度缓慢等问题,不得不进行重构。在战略角度上也许是对的,先占坑再完善,但在架构角度这是不可取的,还是要严格遵循“高内聚,低耦合”的理念,确保框架由底层服务到顶层业务,各模块分工明确,各司其职,相对独立,模块间通过接口调用,严禁在A里直接使用B,B里直接使用C,这样会使得各模块藕断丝连难舍难分,后期只会越来越乱。

很多时候,现在的问题都是当初偷懒埋下的祸根,合格的程序员基本都是懒人,但摔的多了总要长点记性。适当克服一下惰性,前期将框子搭起来,真正的去面向对象编程。

二、我曾接手过一款直播App,光直播间ViewController代码就5500行,里面掺和着接口请求、数据转换、视图管理、业务逻辑等等,读起来十分费劲,Bug定位比较困难,想重构却无从下手,这种情况的发生首先是没有严格遵循模块化的设计理念,各模块没有各司其职,其次是过于严格的遵循了MVC设计模式,只创建了Model View Controller三个文件夹,VC的压力自然非常大。

在我理解来看,MVC只是表达了一种模块化思想,并不需要严格遵循MVC的目录格式。

如上图,我将每个模块在MVC的基础上又抽出了两层,分别是Logic层和Service层。Logic文件夹内,存放在每个VC的逻辑处理类。

咱们的目的是解放VC,ViewController顾名思义是视图控制器,不应做太多与其不相关的工作,将逻辑处理交给对应这个VC的Logic类,Logic承担着逻辑处理和Service的调用拿到数据并解析,通过delegate回调给VC,VC拿到已经处理完毕的数据,去渲染视图。

这样做的话,VC内只剩下与Logic的交互,还有管理View的代码,必然清晰很多。

743749-37fb8853ea5632d2.png

模块结构

三、大部分应用为了快速开发,都会使用一些第三方框架,但第三方框架如此之多,我们该如何选择才能够发挥它们最大优势?

首先要分析自己的应用,都用得着哪些框架,在同一类型的框架里选择的宗旨是——符合自身且维护及时,超过一年没更新的就要慎重了,下面是我选择时的一些思考:

1.网络框架

网络请求是一款APP必须的,大家通常都会选择AFNetworking作为基础网络框架,但这只是个基础框架,虽说可以直接调用请求数据,但如果有一些其他需求,例如加密或者加公共参数等,想要满足就比较费劲了,所以大多数开发者会对其进行二次封装,目的为了自定义一些需求,可以自己掌控并处理请求和返回数据,也为将来如果更换网络框架,减少代码改动量。很多人自己封装一些简单的Post Get请求方法,中小型应用使用起来也足够。

当前框架中我最开始选择的是PPNetworkHelper,原因是比较简单易用,其中还包含了缓存机制。后来看了猿题库的网络库YTKNetwork,引入使用了一下,发现使用方法跟PPNetworkHelper完全不同,YTKNetwork的思想是抽象每个接口为一个对象,实例化接口对象去发起网络请求,从而可以针对每个请求定制化,还有一些其他的功能,灵活性比较强,适合稍微复杂一些的项目,框架中两种我都保留了,大家可根据项目实际情况进行选择,但建议都了解一下,特别是后者。

743749-0501ae2fd9e638c1.png

YTKNetwork 实现数据请求

2. 基础组件库

之前就提到过的,功能强大,性能优秀的——YYKit  

它包含了解析数据,缓存,图像处理,文本处理,异步绘制等组件,当然也有些瑕疵下面说

选择这个框架的原因是功能和性能都比较强大,用一个框架就可以做很多事,而且YYKit的设计思想是category,几乎没有入侵性,使用起来也非常方便。

但是同事发现YYWebImage— 这个高性能异步图像加载框架可能有点过时,因为其使用的是NSURLConnection请求,而SDWebImage已替换成了URLSession。所以图像异步加载上,我还是选择更加专业的SDWebImage。

743749-bc6f67a3f098fe26.png

YYKit

3. 布局框架

这里想必最大的分歧不是框架,而是布局方式,我了解的开发者通常有三种布局方式,分别是:代码计算frame、Masonry代码约束,SB/xib直拖约束。

我认为三种方式各有优缺点,不做评价,免得被骂,我个人是灵活运用,没有瞧不起任何一个,在不同的场景下,使用最合适的方式,才能达到最佳效果,举个栗子:“关于我们”,一个简单展示的页面,这时候通过xib拖出来这个页面,应该不超过5分钟,手写代码计算frame也许得10分钟,而且!代码写的东西不够直观,其他同事不能直接的看到你这个页面是什么样子。所以无论哪种方式都不是绝对的不好,也没有绝对的好,看场景,选姿势。

4.上下拉刷新框架

大部分应用都会有TableView或CollectionView,上下拉刷新是比较常用的,MJRefresh提供的功能比较强大,支持自定义,提供样式齐全,更新及时,所以,我选它!

743749-331847407e6a6eb8.png

MJRefresh

5. Toast提示

比较主流的两款Toast提示框架可供选择,分别是 MBProgressHUD SVProgressHUD,二者更新都比较及时,功能也都类似,根据个人习惯了,选择哪个不重要,重要的是要对其二次封装,让它变得更好用,框架中我封装了一个MBProgressHUD+XY的category,类方法的形式调用。

743749-570dc3ba24e53344.png

MBProgressHUD

关于其他框架的选择,其实道理一样,首先要了解他们的优缺点,本着符合自身且维护及时的宗旨去选择就没有错。

以上内容的源码都整理在GitHub - UniversalProject框架内,大家可以下载参阅,顺便动动小手指点颗?

原文地址:http://www.jianshu.com/p/f09a4f21e0f9

下面对你也许有帮助:

以上属于臭码农原创,若有雷同属巧合,如有错误望指正,转载请标明来源和作者。

搜索CocoaChina微信公众号:CocoaChina
微信扫一扫
订阅每日移动开发及APP推广热点资讯
公众号:
CocoaChina
我要投稿   收藏文章
上一篇:对于iOS架构模式之争的一些思考
下一篇:iOS多线程全套:线程生命周期,多线程的四种解决方案,线程安全问题,GCD的使用,NSOperation的使用
我来说两句
发表评论
您还没有登录!请登录注册
所有评论(0

综合评论

相关帖子

sina weixin mail 回到顶部