项目架构、重构、项目优化

项目架构

架构要考虑的问题

1、代码整齐，分类明确，一个类尽量不要做两种事情、代码规范

2、不用文档，或很少文档，就能让业务方上手，对业务方该限制的地方有限制，该灵活的地方要给业务方创造灵活实现的条件，后续架构容易传承

3、易测试，易拓展，保持一定量的超前性

4、接口少，接口参数少，

5、高性能

具体来分析的话 分为多个层次

1、代码风格层面

代码风格决定了项目是否容易扩展、是否会遇到很多问题

2、业务块的结构

业务块最繁重的就是UI与数据的交互，如何优雅的去处理

MVC模式

M应该做的事：

基本数据模型
给ViewController提供数据
给ViewController存储数据提供接口

C应该做的事：

管理View Container的生命周期
负责生成所有的View实例，并放入View Container
监听来自View与业务有关的事件，通过与Model的合作，来完成对应事件的业务。

V应该做的事：

响应与业务无关的事件，并因此引发动画效果，点击反馈（如果合适的话，尽量还是放在View去做）等。
界面元素表达

MVVM模式

MVVM的关键是要有View Model，给Controller瘦身

Model做的事情：

基本数据模型
给ViewModel提供数据
给ViewModel存储数据提供接口

V应该做的事：

响应与业务无关的事件，并因此引发动画效果，点击反馈（如果合适的话，尽量还是放在View去做）等。
界面元素表达

C做的事情：

有了ViewModel就不要Controller是错误的，严格来说MVVM其实是MVCVM。从图中可以得知，Controller夹在View和ViewModel之间做的其中一个主要事情就是将View和ViewModel进行绑定。在逻辑上，Controller知道应当展示哪个View，Controller也知道应当使用哪个ViewModel，然而View和ViewModel它们之间是互相不知道的，所以Controller就负责控制他们的绑定关系。

ViewModel做的事情：

C中拆出来一个专门负责处理数据的模块

3、网络层

网络层独立抽出来的原因在于，项目的网络架构是比较稳定，比较少变更的部分，但同时也是覆盖面最广的一部分。这一部分的架构影响着整个项目。

4、View的组件化

很多团队会由一个问题，人一多，就会出现同一个组件UI的代码会出现很多份，即使有版本管理控制也会有这种情况，就比如说写个菜单组件，每个开发写一个，工程里面就会冗余很多没有意义的代码

所以把耦合低的组件做成轮子、进行组件化很有必要，轮子丰富后，减少开发时间，如果涉及到统一修改也方便

但这就涉及到一个问题，不是什么都能做成轮子，轮子不能耦合业务或者特殊需求。

5、工程的组件化

项目达到一定规模，业务线就会比较多，如果没有工程组件化，项目就会显得很凌乱，这种情况需要根据项目层面（MVC等）做出工程的调整，基础组件需要沉底，另一方面是业务层面，不同业务线，是否有完全独立的功能性业务线可以独立在外，例如通过pod的方式引入。

2、如何优雅的重构

1、代码一开始就要很好的思考清楚如何设计更合理，最好画个思维导图，考虑清楚各种场景

2、设计清晰后，如何去更优雅的实现，使用那些设计模式去调整

3、设计的东西尽量简化、清晰，不要去考虑给用户打包一个全家桶，设计一个库需要的是功能点明确

4、代码的命名、文件的命名，跟着功能走、功能是做什么的，最好就是叫什么，实在不清晰的命名需要备注注释

设计原则

前面五种被称为面向对象设计中常用的SOLID原则。

https://www.jianshu.com/p/e5c69c7b8c00

3、项目如何在代码层面进行优化

https://blog.csdn.net/hello_hwc/article/details/53147910

项目的优化分为编译优化 和 运行优化

编译优化指的是 优化方向是优化我们的开发过程，例如编译速度，代码效率，迭代效率，扩展性等

运行优化指的是 优化方向是app的运行，例如，列表流畅度、交互体验、网络延时等等

编译优化

https://www.jianshu.com/p/87402d73602d