前言：
前段时间刚离职，面试了几家公司，不免会问道架构方面的知识，可是我发现了一个局限性，都是偏于开发模式的选择，比如ＭVC、MVVM等。对此，个人感觉过于片面。下面就是我自己对于架构的思考。
一、团队规模
如果说团队规模比较大，采用MVVM，Router路由方案,都是比较合适的，这样便于模块化的开发。减少合作的过程中的干扰。但是如果团队较小，MVC反而是最适合的。考虑到C或边的越来越大，可以考虑使用简化版的MVVM。只是把部分业务从C中分摊到VM中。
二、业务类型
这里是真APP的具体实用场景，例如，外卖类的app,无可避免的就的考虑电量优化。定位及导航是非常耗费电量的。此时需要考虑的就是如何减少电量的损耗。降低定位精度，减少后台开销（关闭不必要的任务，对业务处理建立优先级制度），还有就是减少不必要的数据加载。
三、模块化能力
1、目前APP的功能模块比较固定，如，支付，推送，地图，网络，数据库，异常监控及上报等，并且大多数情况下都是使用第三方的SDK，此时我们在接入这些SDK的时候就需要考虑升级换代的事情，最简单的方式就是对这些SDK进行二次封装，当我们面临添加， 修改，更换SDK的时候，我只需要修改我们封装的部分，二不会去修改使用的部分，极大的提升 了开发的效率
2、常用UI控件的封装，如果有已经封装好的UI,当我们需要使用的的时候，就不用重0开始去费劲巴拉糊胶水代码，拿来就可以用，这个做了几年iOS开发都是有属于自己的一套东西的。
四、可扩展性，
现在好多应用为了快速的开发， 在前期是用的都是XIB这种拖拽式的快速开发模式，这有他的好处，同时页面的维护成本也增加了，同时对于页面的利用率也大大的降低了，长时间下去，不对的拖新的，扔旧的，整个项目的体积也会慢慢增大的。还得费劲巴拉的去删除，我个人提倡是纯代码化。
五、项目的健壮性
很多人都觉得，做开发应该是遇到问题解决问题。很少去考虑从一开始就就行程序健壮性的研究。说的直白点，就是懒，其实就是自己多百度一点东西，然后拿回来，进行封装修改，形成自己的东西，很简单的一点，我们经常会遇到数组越界的情况，那么可以通过runtime进行方法替换。这样再加上我们写代码的时候进行防止越界的保护操作，就可以极大的降低APP的奔溃。
六、通用性
做项目，免不了会使用一些公共的部分，比如自定义的工具类，支付，网络请求的二次封装等，更换的可能性很小，但是调用很多的的部分，这里可以提取到通用模块。这样可以快速的适配，更改，迭代等！提升开发的效率。程序员都是懒人，所以最好在前期勤快点，后面就能轻松很多！
目前这些就是个人的理解，希望大家能帮忙指正错误以及丰富内容
