服务化概念
- 将后台的服务化思路借鉴到客户端
- 分为微服务和服务两种类型
- 微服务的定义是只供调用，不调用其他人
- 服务的定义是既对外提供服务，又调用其他人的服务
- 在iOS客户端，可以不区分微服务和服务，统一称为服务，xxxService
单例还是类方法？
可以说单例和类方法都可以，两者也都有优缺点。
- 单例可以有自己的属性，调用方便
- 类方法在实现某些功能的时候受限，因为没有成员变量或者是数据啊
- 类方法是最简单的调用方式，只要一个类名就可以了
- 类方法可以调用单例，实例方法；而单例再套一个类方法感觉有点奇怪
- 单例的统一方法，一般都是sharedInstance，反复写感觉有点浪费
- 使用者并不关心是单例还是实例，这是实现层面的内容
选择建议：
- xxxService统一采用类方法对外提供功能
- 统一用函数的方式提供功能，放弃属性的方式
- xxxService作为一层接口封装，只做调度，没有具体实现
- 具体功能由单例或者实例对象提供，数据由实现者持有
普通三层
- iOS的Native部分，大致可以分为数据，逻辑和界面三层，这是符合常见思维的
- 界面层入手最简单，不过经历多了之后，就会发现，界面层其实是最麻烦的
- iOS程序一开始都很小，不存在分层的概念，所有的事情在一个UIViewController完成。而且设计思路是代理模式，系统为开发者提供了一些代理函数来自定义行为。每个页面代表一个UIViewController，大家都差不多，只是具体内容由应用开发者自定义。每次也只有一个页面在显示，其他的要么在排队，要么没加载。
- 后来，随着业务逻辑的增长，UIViewController就变成了“上帝类”，什么都做，难复用，维护困难
- 所以，后来出现了iOS架构的概念，把一些跟业务无关的内容抽出来，提高复用度，逐渐形成逻辑层，数据层的概念
- iOS架构的核心，一般都是为UIViewController瘦身。因为它什么都能做，所以目标是让它“什么具体的事情都不做”，只做一个“调度者”，就像一个“企业的CEO”一样，专门负责“按开关的”
- UIViewController是系统的代理，属于界面层，难复用，所以界面层入手简单，其实是最复杂的
- 既然要界面层本质上是最复杂的，那么iOS架构的界面层要尽量薄
- 逻辑层一般是按照业务概念来分的，比如登录，注册，订单等
- 数据层一般是按照功能来分的，与具体业务无关，比如网络，数据库，加解密等等
- 在模式上，参考Object-C到Swift的发展，偏向于用组合代替继承。一般有BaseUIViewController的，很难称得上是优秀的架构
