ios APP项目架构心得

最新推荐文章于 2024-06-23 09:38:56 发布

hebia0

最新推荐文章于 2024-06-23 09:38:56 发布

阅读量3.1k

点赞数 4

分类专栏： IOS 文章标签： ios 项目架构 ios工程

本文链接：https://blog.csdn.net/chmod_R_755/article/details/81032489

版权

IOS 专栏收录该内容

102 篇文章 0 订阅

订阅专栏

iOS项目架构分为以下几步，这些都是总结的经验之谈

1.架构

1.架构这个概念很抽象，但是用一句话来说叫看菜吃饭，有些人喜欢先看UI在架构，有些人喜欢先把该有的东西有了再看UI，其实都可以…..
2.cocoapod 这个是必备的，现在第三方包基本用这个管理
3.尽量找出项目中相似的东西：操作行为（eg：需求登录，需求权限，需求授权，分享等），视图行为（字体，字号，有规律控件）；我们需要将这些相同的或者相似的东西尽量多找出来，写一些工具类或者写一个基类让自己的类继承
4.不建议使用xib等可视图工具或插件开发iOS，不为什么，经验
5.Xcode自带的svn/git 工具挺好，国内私有代码托管码云不错；githu是国际化路线私有收费不建议，而且天朝国情github速度性能托管代码没有码云好
6.代码每一个固定的周期备份，在完成一个比较重要的模块的时候记得备份
7.某个模块有独立的功能的时候，把模块独立出来，同样把模块的资源文件也独立出来；项目自带的Images.xcassets 里面文件分类最好对应相应的UIView
8.开发证书先弄好，正式&开发推送等证书先弄好，或许现在用不上用上的时候再搞听操蛋的；各种秘钥先申请好微信分享，微博分享，推送，统计，支付等等一大推的秘钥我是建议在开发之前先申请好，别老是更新APP的名字或是icon 要改的地方很多。。。
9.建议iPhone和iPad分成两个项目来搞（小厂另说，若UI设计的很相似的话如微信可共用一套）

2.UI

1.首先导入Masonry 不解释，肯定要用的
2.确定下UI的布局形式：a）字号不变 b）字号变化，这里单独拿出来是因为ios的几个机型宽度高度存在着一定的差异，iPhoneX 和 iPhone6 同宽不同高，iPhone5和iPhone6及iPhone6Plus的关系应该是 iPhone5 ->@2x.png而 iPhone6Plus对应的是->@3x.png ，并不是iPhone6->*@2x.png ；但是平时UI妹子（也有汉子）在设计的时候会以iPhone6为准那么在640x1136的屏幕上怎么呈现需要先说明，别到最后BB的那就蛋疼了，然后是字号怎么变化的问题先说好
3.android有android的UI风格，同样ios有ios的UI风格，SB的UI会说做成一样的；ios的状态栏，导航条，tabbar栏（tabbar里面的图片大小，文字大小其实都有一套标注的），toolbar栏的高度是固定，自定义UI另说
4.iOS中可以使用第三方字体，注意版权的问题（还是推荐使用苹果自己的字体）小厂没事情，大厂就瞎了。。。。不解释
5.阿里icon里面有好多可以用的icon，同样注意版权问题
6.icon需要1024x1024的（商店需要），有很多工具（有在线的）可以生产icon，所以你只需要一张1024的图就行，别自己ps处理浪费时间
7.APPstore中 iPhone的图可以截屏或自定定义；但是iPad的图可以截屏如果要自定义的话图片中必须有iPad（图片中必须画一个iPad，然后在iPad上画自定义UI，否则审核可能会不过的，不能直接拿着iPhone的图放大）

3.网络

1.网络框架AFNetworking这个不解释，AFNetworking 是异步操作
2.MVC这我我要说的是Model，应该这个会伴随整个项目，你选用的基础model（Manually,YYModel,FastEasyMapping,JsonModel,Mantle,MJExtension）可能会影响你写代码，我推荐使用YYModel,当然还有配套的工具 JSONModel 方便格式化成对象
3.建议接口调用加密，加密方式我总计代码加密和证书加密；代码加密很简单，就是在传入参数的时候通过一定的排列规则组合成一个秘钥当参数传入，可以防止别人恶意刷接口（例如短信验证码），写一套加密规则；证书加密就比较麻烦，分单认证和双向认证，金融类的APP可以这么高，小厂APP这么搞时间成本高不建议（通常是服务端吃不消，小厂的服务端不像大厂，况且小厂哪有那么多屁事搞得跟真的似得）
4.更新图片的时候图片需要重命名（这个有必要跟接口说下，有些接口就是SB），ios图片缓存是根据名称来缓存的
5.AFNetworking其实自带缓存功能，网络请求方式有很多种、常用的是 POST和GET，其实还有DELETE，PUT，HEAD,PATCH,TRACE,OPTIONS（其实远不止这些但是get和post足够了）
6.参数传递可以通过header和parameter两种方式

4.数据存储

1.FMDB是个好的sqlite框架，这个不解释12K+的star
2.最好有一点SQL基础，因为你可能需要自己写SQL语句
3.数据库还有考虑以后增加字段等问题，数据库的类型不好把握数字（整形）用Integer其他用Text
4.ios中支持可视化的数据库CoreData，而且CoreData有增删改查对应的方法或者事件，至于怎么选择看自己的习惯或者说看业务的要求
5.CoreData也有很多优秀的开源项目

5.安全

1.手机被越狱之后安全不是ios开发工程师考虑的
2.网络请求这块建议https+证书认证，参数加盐加密（别只是SB的MD5），做到这两点可以抵挡99%非法操作（如果受剩下的1%入侵，我觉得你们厂至少在Hong Kong上市。。。都能在Hong Kong上市，那肯定不差钱请安全砖家了）
3.如果说是图片类的公司，最好搞个神马水印上面，实在是搞不了水印的保存到本地可以把图片二进制文件打乱再保存，视频类文件也是一样的
4.ios有加密APP的工具，不过收费的居多，但是app商店能抵挡一些恶意操作，总体感觉是加密的话成本较大不推荐
5.授权安全：ios不像android，android偷偷地，后台偷偷地干些事情；iOS会有提醒，最常用的授权就是通信录、相机、相册、位置等
6.注意私有API的使用，部分框架中包含了私有api，实时关注第三方API的更新情况

6.统计、bug管理

1.统计无可厚非肯定是第三方统计，原因：技术成熟框架稳定；可以自己写统计，但是其一麻烦，其二维护难；统计现在好多公司在做，友盟，sharesdk，极光都在搞统计，友盟的统计是比较受认可的，友盟本来就是统计出生的，然后友盟的爹是阿里，不解释；统计用友盟！！！
2.统计这块会牵扯到一个问题，那就是版本：也就是项目必须有一个版本管理的模块，从项目准备做开始就得要设计这个模块
3.统计为什么和bug管理扯上关系了，bug 管理也是和版本有关的，我们常用的远程bug工具是腾讯的bugly，友盟应该也有类似的工具，但是腾讯的这个还可以
4.iOS不支持热修复，死了这条心
5.版本号，其实这个没有神马共识，爱怎来怎么来，但是最好是出一套规定，版本号怎么更新
6.统计，bug管理，版本管理最好在项目一开始就要干

7.分享

1.分享为什么要单独拿出来了？首先分享有两大家， sharesdk 和友盟，还有其他乱七八糟的不多介绍了，个人建议都用友盟的，因为你的统计用了友盟的了，你再用sharesdk分享的话，你的APP会大很多，减少APP大小从我做起
2.截屏分享的功能苹果官方是禁止的，若查到无法上架的（凭运气）
3.有支付和没有支付的分享导入的第三方包不一样
4.几乎所有的第三方分享都支持用户自定义分享界面

8.推送

1.推送几大家族：极光，个推，百度云，友盟等 … 这么多推送其实都是为了照顾android，因为ios自己的推送本身很稳定，或者说很容易实现
2.推送证书最好提前准备，正式版和测试版，名称、密码最好搞一样的，省的以后麻烦，当然你都导入了友盟统计和分享，推送也可以用友盟的，省事；但是android可能就没有那么走运了，中兴华为小米各个推送分分钟让人想自杀。。。。。
3.推送证书有有效期的，推送不灵了，注意查看证书的有效期
4.可以自定义推送，最好是能将推送与登录用户关联起来
5.推送需要用户主动授权，不授权就瞎了