一、架构是什么？
简单来说就是调API，展示页面，然后跳转到别的地方再调API，再展示页面。
二、为啥要讨论架构
App确实就是主要做这些事情，但是支撑这些事情的基础，就是做架构要考虑的事情。
调用网络API
如何让业务开发工程师方便安全地调用网络API？然后尽可能保证用户在各种网络环境下都能有良好的体验？页面展示
页面如何组织，才能尽可能降低业务方代码的耦合度？尽可能降低业务方开发界面的复杂度，提高他们的效率？数据的本地持久化
当数据有在本地存取的需求的时候，如何能够保证数据在本地的合理安排？如何尽可能地减小性能消耗？动态部署方案
iOS应用有审核周期，如何能够通过不发版本的方式展示新的内容给用户？如何修复紧急bug？
三、架构设计的方法
第一步：搞清楚要解决哪些问题，并找到解决这些问题的充要条件
你必须得清楚你要做什么，业务方希望要什么。而不是为了架构而架构
关于充要条件我也要说明一下，有的时候系统提供的函数是需要额外参数的，比如read函数。还有翻页的时候，当前页码也是充要条件。但对于业务方来说，这些充要条件还能够再缩减。
比如read，需要给出file descriptor，需要给出buf，需要给出size。但是对于业务方来说，充要条件就只要file descriptor就够了。再比如翻页，其实业务方并不需要记录当前页号，你给他暴露一个loadNextPage这样的方法就够了。
搞清楚对于业务方而言的真正充要条件很重要！这决定了你的架构是否足够易用。另外，传的参数越少，耦合度相对而言就越小，你替换模块或者升级模块所花的的代价就越小。第二步：问题分类，分模块
第三步：搞清楚各问题之间的依赖关系，建立好模块交流规范并设计模块
关键在于建立一套统一的交流规范，不是两套，不是多套。你要坚持你的价值观，不要摇摆不定。要是搞出各种五花八门的规范出来，一方面有不切实际的炫技嫌疑，另一方面也会带来后续维护的灾难。第四步：推演预测一下未来可能的走向，必要时添加新的模块，记录更多的基础数据以备未来之需
第五步：先解决依赖关系中最基础的问题，实现基础模块，然后再用基础模块堆叠出整个架构
第六步：打点，跑单元测试，跑性能测试，根据数据去优化对应的地方
四、什么样的架构叫好架构？
代码整齐，分类明确，没有common，没有core
代码整齐是每一个工程师的基本素质，分类明确的字面意思大家一定都了解，但还有一个另外的意思，那就是：不要让一个类或者一个模块做两种不同的事情。如果有类或某模块做了两种不同的事情，一方面不适合未来拓展，另一方面也会造成分类困难。不用文档，或很少文档，就能让业务方上手
思路和方法要统一，尽量不要多元
没有横向依赖，万不得已不出现跨层访问
没有横向依赖是很重要的，这决定了你将来要对这个架构做修补所需要的成本有多大。要做到没有横向依赖，这是很考验架构师的模块分类能力和是否熟悉业务的。
跨层访问是指数据流向了跟自己没有对接关系的模块。有的时候跨层访问是不可避免的，比如网络底层里面信号从2G变成了3G变成了4G，这是有可能需要跨层通知到View的。但这种情况不多，一旦出现就要想尽一切办法在本层搞定或者交给上层或者下层搞定，尽量不要出现跨层的情况。跨层访问同样也会增加耦合度，当某一层需要整体替换的时候，牵涉面就会很大。对业务方该限制的地方有限制，该灵活的地方要给业务方创造灵活实现的条件
易测试，易拓展
提高模块化程度，尽可能减少依赖关系，便于mock保持一定量的超前性
接口少，接口参数少
高性能
五、那么我们怎么做分层？
应该如何做分层，不是在做架构的时候一开始就考虑的问题。虽然我们要按照自顶向下的设计方式来设计架构，但是一般情况下不适合直接从三层开始。一般都是先确定所有要解决的问题，先确定都有哪些模块，然后再基于这些模块再往下细化设计。然后再把这些列出来的问题和模块做好分类。分类之后不出意外大多数都是三层。如果发现某一层特别庞大，那就可以再拆开来变成四层，变成五层。
所谓的分层都是出架构图之后的事情了。所以你看别的架构师在演讲的时候，上来第一句话差不多都是："这个架构分为以下几层..."。但考虑分层的问题的时机绝对不是一开始就考虑的。另外，模块一定要把它设计得独立性强，这其实是门艺术活。
