iOSAPP开发项目搭建
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了iOSAPP开发项目搭建相关的知识,希望对你有一定的参考价值。
架构图:
架构原则:易读性、易维护性、易扩展性。
一、思考
做好一件事,花在思考上的时间应该多于执行。
首先根据产品需求和设计图,脑中先建立一个产品架构:
1. 产品的定位是什么。
社交?媒体?游戏?运动?音视频?电商……要搞清楚你要做一个什么类型的App,不同类型的产品,技术选型也有所不同,在这我是搭建一个基础App架构,可以在此基础上拓展社交、电商、音视频等!
2. 技术选型
根据当前产品的需求以及未来可能有的需求(我怎么知道未来会有什么需求?可以参照竞品,可以发挥想象,如果产品说:“我们要做IM文字聊天,只做文字!不做音视频,以后都不做!” 类似这样的承诺,你如果信了他的邪……后面的故事就精彩了。。哈哈哈哈哈哈。。。。所以说这时候你就要考虑到后面会有语音+视频聊天,在设计的时候不要偷懒,预留一定空间,当某天产品反悔的时候,你可以微微一笑,从容应对。
一把拉回话题,接着说技术选型,通常我会选择一些当下比较热门、好用的第三方框架,例如:YYKit ,YYKit 是一组庞大、功能丰富的 ios 组件,包含Model解析、图片加载、缓存等基础服务,都是基于Category设计的,使用方便且性能高于一些老的框架,用过的都说好。
其他框架的选择可以根据项目需求,去GitHub上搜索,星星多的每个都看一下,会给你增加一些思路。
程序猿长得可以保守,思想一定不能太保守。
二、搭建目录结构
如上图,我是这样搭建App目录结构的,从下到上,使用Pods管理第三方框架,将第三方框架进行二次封装,供给顶层使用,尽可能减少各模块之间的耦合度。
三、封装基础类
1. AppDelegate是应用的代理,应用级的事件都委托它处理,包含启动退出、推送等事件,以及IM、支付等第三方的回调,这使得AppDelegate内代码庞大,错综复杂,十分不利于阅读和维护,因此我新增了一个AppDelegate+AppService类别,用来处理生命周期之外的业务,AppDelegate作为事件入口,具体实现直接调用类别里的方法。
2. Modules包含了应用内的功能模块,根据底部Tab栏划分并关联实体文件夹(默认是虚拟的要手动建立实体文件夹拖进来),每个模块内使用的是MVC模式,有人会问为什么多了Resource和Service文件夹,MVC是一种设计思想,并非死套路就仨文件夹,根据实际需求适当增加,在这我选择在Service封装数据请求,VC里调用拿数据即可,至于Resource为什么在这,我认为当功能模块层级较多时,每个大功能模块都对应许多资源,对应到模块内用起来方便,当然也可以放到最外层的Resource文件夹里,建立对应的模块名称,在这儿我是选择把公共的放到最外层Resource里,功能相关的放到模块里的Resource文件夹内。
3. Manager的定义是全局基础服务,通常使用类方法或者单例来实现,主要包含对应用、用户的管理和服务,例如网络状态监听,广告页应用介绍页等;用户快速登录退出操作以及登录状态的获取等。
4. Utils文件夹内主要包含全局通用工具,来源于对三方框架的二次封装,或是自己写的工具类。在这个项目里,我封装了带AES加密网络请求工具,全局Toast提示,广告页等。
5. Base文件夹用来存放项目的基类,基类作用包含一些定制化的内容,例如页面样式,空数据页面等,使用基类来实现,可以统一控制,利于维护,减少冗余,也为更清晰。
6. 第三方文件夹放一些第三方的类库和对第三方封装,比如第三方登录、支付、IM等,现在项目我还没有添加第三方框架。
7.全局宏顾名思义是定义了一些全局通用宏。我这里定义了四个:
UtilsMacros定义的是一些工具宏,比如获取屏幕宽高,系统版本,数据类型验证等;
URLMacros定义服务器接口地址以及环境开关;
FontAndColorMacros定义全局用的色值、字体大小,这里建议跟设计师共同维护一个设计规范,例如:定义一个主色调宏 MainColor,色值是 0x333333,我们全局使用MainColor宏作为背景颜色,当某天App改版,色值改变,我们只需要去更改 0x333333即可,其他代码不需要动,同时也能一定程度约束设计师,不要随便增加一种颜色,非常接近的颜色应当使用一个。如果设计师不愿意维护这个规范,你可以尝试打一架,打不过的话,就只能自己维护了。
ThirdMacros 包含第三方框架相关的定义,例如keySecret等。
8. 资源文件,上面说到过,这里我是存放了全局的一些资源文件,功能模块的我放到了模块内的Resource文件夹内,个人喜好。
9. CocoaPods是iOS项目的依赖管理工具,开发iOS项目不可避免地要使用第三方开源库,CocoaPods的出现使得我们可以节省设置和第三方开源库的时间。
架构图
效果图
思考:
-
一、面对一个版本迭代频繁,改版频率高的项目,如何设计才能避免代码越改越乱?
-
二、当业务极其复杂时,如果减轻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的代码,必然清晰很多。
模块结构
三、大部分应用为了快速开发,都会使用一些第三方框架,但第三方框架如此之多,我们该如何选择才能够发挥它们最大优势?
首先要分析自己的应用,都用得着哪些框架,在同一类型的框架里选择的宗旨是——符合自身且维护及时,超过一年没更新的就要慎重了,下面是我选择时的一些思考:
1.网络框架
网络请求是一款APP必须的,大家通常都会选择AFNetworking作为基础网络框架,但这只是个基础框架,虽说可以直接调用请求数据,但如果有一些其他需求,例如加密或者加公共参数等,想要满足就比较费劲了,所以大多数开发者会对其进行二次封装,目的为了自定义一些需求,可以自己掌控并处理请求和返回数据,也为将来如果更换网络框架,减少代码改动量。很多人自己封装一些简单的Post Get请求方法,中小型应用使用起来也足够。
当前框架中我最开始选择的是PPNetworkHelper,原因是比较简单易用,其中还包含了缓存机制。后来看了猿题库的网络库YTKNetwork,引入使用了一下,发现使用方法跟PPNetworkHelper完全不同,YTKNetwork的思想是抽象每个接口为一个对象,实例化接口对象去发起网络请求,从而可以针对每个请求定制化,还有一些其他的功能,灵活性比较强,适合稍微复杂一些的项目,框架中两种我都保留了,大家可根据项目实际情况进行选择,但建议都了解一下,特别是后者。
YTKNetwork 实现数据请求
2. 基础组件库
之前就提到过的,功能强大,性能优秀的——YYKit
它包含了解析数据,缓存,图像处理,文本处理,异步绘制等组件,当然也有些瑕疵下面说
-
YYModel— 高性能的 iOS JSON 模型框架。
-
YYCache— 高性能的 iOS 缓存框架。
-
YYImage— 功能强大的 iOS 图像框架。
-
YYWebImage— 高性能的 iOS 异步图像加载框架。
-
YYText— 功能强大的 iOS 富文本框架。
-
YYKeyboardManager— iOS 键盘监听管理工具。
-
YYDispatchQueuePool— iOS 全局并发队列管理工具。
-
YYAsyncLayer— iOS 异步绘制与显示的工具。
-
YYCategories— 功能丰富的 Category 类型工具库
选择这个框架的原因是功能和性能都比较强大,用一个框架就可以做很多事,而且YYKit的设计思想是category,几乎没有入侵性,使用起来也非常方便。
但是同事发现YYWebImage— 这个高性能异步图像加载框架可能有点过时,因为其使用的是NSURLConnection请求,而SDWebImage已替换成了URLSession。所以图像异步加载上,我还是选择更加专业的SDWebImage。
YYKit
3. 布局框架
这里想必最大的分歧不是框架,而是布局方式,我了解的开发者通常有三种布局方式,分别是:代码计算frame、Masonry代码约束,SB/xib直拖约束。
我认为三种方式各有优缺点,不做评价,免得被骂,我个人是灵活运用,没有瞧不起任何一个,在不同的场景下,使用最合适的方式,才能达到最佳效果,举个栗子:“关于我们”,一个简单展示的页面,这时候通过xib拖出来这个页面,应该不超过5分钟,手写代码计算frame也许得10分钟,而且!代码写的东西不够直观,其他同事不能直接的看到你这个页面是什么样子。所以无论哪种方式都不是绝对的不好,也没有绝对的好,看场景,选姿势。
4.上下拉刷新框架
大部分应用都会有TableView或CollectionView,上下拉刷新是比较常用的,MJRefresh提供的功能比较强大,支持自定义,提供样式齐全,更新及时,所以,我选它!
MJRefresh
5. Toast提示
比较主流的两款Toast提示框架可供选择,分别是 MBProgressHUD 和 SVProgressHUD,二者更新都比较及时,功能也都类似,根据个人习惯了,选择哪个不重要,重要的是要对其二次封装,让它变得更好用,框架中我封装了一个MBProgressHUD+XY的category,类方法的形式调用。
MBProgressHUD
关于其他框架的选择,其实道理一样,首先要了解他们的优缺点,本着符合自身且维护及时的宗旨去选择就没有错。
以上内容的源码都整理在GitHub - UniversalProject框架内,大家可以下载参阅,顺便动动小手指点颗?
原文地址:http://www.jianshu.com/p/f09a4f21e0f9
下面对你也许有帮助:
-
iOS 团队编码规范—— 团队开发需要共同遵守的代码规范
-
代码注释,教你用快捷键+代码块实现快速注释—— 让注释不再是负担,快捷键帮你解决
-
通用工具类宏定义—— 进一步提升编码效率
作者:臭码农
链接:http://www.jianshu.com/p/d553096914ff
以上是关于iOSAPP开发项目搭建的主要内容,如果未能解决你的问题,请参考以下文章
基于.NetCore开发博客项目 StarBlog - 开始搭建Web项目