iOS基础架构搭建（初级的我）

最新推荐文章于 2022-04-05 13:10:02 发布

XYDEV

最新推荐文章于 2022-04-05 13:10:02 发布

阅读量345

点赞数

分类专栏： iOS菜鸟的我

本文链接：https://blog.csdn.net/xy19921108/article/details/89385251

版权

iOS菜鸟的我专栏收录该内容

1 篇文章 0 订阅

订阅专栏

iOS基础架构搭建（初级的我）

前言
1.搭建基础结构框架的一些想法
2.具体内容
3.说明
4.一些想法
5.没有图片和demo
end

前言

从事iOS好几年了，接触了很多项目，遇到很多问题。一直没有用文字的习惯（但是要写demo，从不整理记录），这是第一次用文字记录。突然一个想法，重新写一个关联低又要有实际作用的基础框架，可能称为原始框架比较合适。只想满足两个功能，一个是只针对中小项目并可快速搭建，并且能在此基础进行衍伸。二是节省自己精力，把能通用的功能全部统一在一起管理。

好几年没有弄过这么简单的内容了，不知道什么时候开始，每次写项目都是新建一个，然后就是拖拖拖，点点点，新项目框架就完成了。

我害怕再过几年，我就想不起来最开始的我是怎么做项目的

我本来想写一个RAC+MVVM+Router的demo工程，但是突然想到一个问题“以前我怎么做的”让我纠结很久，我不知道为什么，只是觉得以前我和现在的的很不一样，想的不一样，做的不一样，内心的跌宕促使我记录一下最开始接触iOS之后两三年的想法，因为随时时间增加，自己思想变化，已经对以前一些思想有些模糊，我自己有些不知道感觉，我想把最开始的一些东西记录下来的。最好的就是这个基础框架了，我会一直用可能会改变很多，但是记录一下以前怎么弄的，可能过了好几年我再看看还能记得以前的自己。

1.搭建基础结构框架的一些想法

你能做的别人比你做的更好
天才是极少数人拥有的特权
大多数开发者没有足够时间和条件的历练
开发者对技术足够的热爱

实际工作中，大多数移动端项目基本基于MVC、MVP、MVVM，尤其是MVC可以说是绝大多数程序员是必须熟悉。如果我把原始的提取出来，关联度低一点，这样我只需要一直更新我自己的所熟悉和需要的部分就可以了，与之对立就像YYKit的作者为了方便大家将框架小模块进行拆分。我搭建一个这样的原始框架原因只是为了方便自己，比把小模块分开搭建更更加快捷的多，总之一句话方便自己。
基于现实，真实情况是现实中一般开发者绝大多数工作量都是基础代码和问题的解决，而不是造轮子，讲理念。对大多数开发者来说能发现问题比解决问题更重要.
开发者在真正开发中所扮演的角色是不一样的，大多数开发者只是代码的搬运工或者常规所认识的写UI的程序员，包括本人都是常年在小公司和创业公司游荡的人。在实际工作中真实条件和限制是不允许你很牛逼。
开发中大多数情况事实上已经有了很优秀的解决方案，不需要你来攻克，需要的只是了解学习。只有当你技术提升到一定层次，能解决某个痛点或者能给出更适合的方案的时候，那你就用自己的轮子跑或者换一个质量更好的轮子都是没有问题的。
初中级别的程序员必须要坚持一个简单框架，因为不知道下一个要做的项目是什么情况，因为大多数情况下你都是被选择的那一个。但是有一套最熟悉最基础的并没有错.

2.具体内容

1. 网络层
1. 常用第三方
3. 工具类
4. Base基类（待商榷）
5. Config

3.说明

网络层

网络层底层基本没有其它选择，选择AFNetworking。至于原因：功能强大，应用广，使用时间长，熟悉（个人），简单……等等原因，至于其它选择还有一些不错的框架，但是影响不大。

本人更习惯对AFNetworking进行再一次封装，其中会有API，胖瘦model，加密，验证等等不可分割的操作进行统一管理，这样的网络层才是可移植性好，常规适用。

网络层封装自己认为有几个点是必须考虑

离散型和集约型设计，这个是直观面对开发者，其实这种知识网上已经很多详细介绍，也很基础。
性能实现：viewModel与胖瘦model或者莲蓬头理论，block和delegate和网络层的配合使用，低耦合与单一职责，这几个知识点需要看一下，有几种方案，但尽量使用自己最能掌握的。网络层责任很明确就是一个数据交换，良好的设计与不同模式的配合才能达到网络层的高效使用。网络层最终是服务于项目整体，所以不同项目情况下只有合适与否，并没有对与错。

第三方库的选择

常规第三方库这种类似AFNetworking,SDWebImage，这种常用功能强大，广泛的，尽可能学习使用，熟练掌握，不要搞特殊，小众化。一般来说，最开始的你要考虑的是不是做很牛逼的事情，而是学习别人的优秀。

一些需要注意的点

一些关于HUD或者toast引用和拓展，wrapper再使用，维护简洁，常规，普通几种普通形式就好，不适合深度定制，如果项目有需要，把深度定制内容单独进行管理。
model解析尽量标准，MJExtension，YYModel，JSONKit类似这些选择其中之一就好，也可以自己简单写一下，不要想着能有完美的解析方案，你永远不知道服务器返回的数据有多少种错误，你做的只能是把模块标准化，高效化，易拓展。
crash方案是需要做的，但不是最重要的，支付宝和微信都会有崩溃，崩溃情况千千万，现阶段的crash机制，基本是现成的方案，不需要写更多代码，只需要引用，了解容错处理，避免常规crash，跟上最新技术就好。
RAC根据情况使用，不要太迷信，RAC可以节省一部分代码，某些地方让逻辑更清晰，但是这是有成本的，最直观的问题就是协同开发时你大量使用RAC，其它开发不习惯使用RAC或者不会使用，当出现互相维护代码，人员更替，产品功能修改，所以RAC使用是为了代码逻辑的高可读性与可维护性，如果没有实现，不要为了节省代码而去使用。
有一些东西需要自己写比较好，前期可以使用别人的，当了解通透自己写一整个比较好，比如第三方登陆，分享，支付等（这些更多是机制，流程，协议的问题，技术难度很低，代码量很少，非常适合自己完整写一次或者整合一套），加密（非常简单，大多数是固有算法，复制和引用就好，了解一下有这个东西就好，概念比较多，可能每个工程都不一样，还是wrapper使用就好，基础概念和一些通用语比较多，AES,DES,对称，非对称，base64,md5,加盐，gzip,三方回调验证，公私钥，ssl等等之类）。分类和扩展的第三方：（根据情况来看，一般来说这个是根据自己经验和技术长期完善的一个东西，不妨直接借用别人优秀的），还有一些就不一一列举了。

工具类

这个不怎么好说，正常使用，创建一些类似timer工具，进制转换，灰度图，图片取色工具这些就可以了，当然还有其它很好用的，万能的网友几乎都会有一些，根据自己情况来吧。

基类

快速开发非常好用，其中比较典型的有VC中的公共参数，界面退出等，header引用，全局监控，默认提示框调用等，还有在统计分析时可以选择性使用。view的基类设置，类似x，y这样的简单写法。

基类的使用会简化一部分重复的代码，可以在实现修改一处改变全局的作用，但是基类的使用也别过度，基类控制越多，保持不同模块之间的互不干扰也就越麻烦（高内聚，低耦合）
基类的使用要根据产品未来较长时间来看，但是保持工程的高拓展性是必须的，当代码迭代较多时候，少用基类，减少粘连，新写一个并不会多很多代码，拓展和维护情况会好的多。