2018-App架构相关

小刚—主要是概念上的泛谈，比较浅，不涉及实际操作

1. 架构是什么

• 组成派：架构=组件+交互：软件系统的架构将系统描述为计算组件及组件之间的交互。

• 决策派：架构=重要决策集：软件架构是在一些重要方面所作出的决策的集合。

2. 架构规划

需求决定架构，架构适应需求。

需求分为三种，优先级由高到低：

• 商业需求

从客户群、企业现状、未来发展、预算、立项、开发、运营、维护在内的整个软件生命周期涉及的商业因素，包括了商业层面的目标、期望和限制等。

• 功能需求

功能需求描述了系统应该提供的服务，必须对该业务领域足够了解，这样才能更好地抽象建模。对功能需求的架构规划，主要就是建立业务领域模型。

• 质量需求

从软件产品本身的角度，各方面的质量需求。

3. 架构设计

当然这个具体采用哪种方式也是看实现的是系统的哪一方面或者哪个层级。

设计方法：

• 面向过程（怎么做）

流程清晰、性能好

不易扩展、耦合高

• 面向对象（谁来做）

业务抽象、建模

牺牲部分性能

• 面向切面

可以说是面向对象的一种功能扩展，将与业务无关的部分剥离出来以横切的方式注入。

• 面向服务

组件化，封装、易拓展迁移

设计原则：

1. 关注点分离

BA51485A-B5C2-45C5-A547-8E6F1ABA7672.jpg

2. 高内聚、低耦合

3. 适度设计

设计不足

过度设计

Casa系列

1. 泛谈

2. 视图层

3. 网络层

4. 持久化层

5. 组件化

1.泛谈

目前很多app做的工作无非是：获取数据(API/Cache)、展示列表、选中单项->展示页面

以上几个功能，可以归结为：

1. 网络API调用（方便、安全、体验）

2. 数据持久化（性能、适用）

3. 页面展示（低耦合、降低复杂度）

4. 动态部署（提供新内容、修复bug）

对于公司层面来讲，还需要：

1. 用户数据的收集

2. 提高开发效率

3. 代码质量

好的架构设计需要从以下几点出发：

1. 搞清楚要解决哪些问题，并找到解决这些问题的充要条件

2. 问题分类，分模块

3. 搞清楚各问题之间的依赖关系，建立好模块交流规范并设计模块

4. 推演预测一下未来可能的走向，必要时添加新的模块，记录更多的基础数据以备未来之需

5. 先解决依赖关系中最基础的问题，实现基础模块，然后再用基础模块堆叠出整个架构

6. 打点，跑单元测试，跑性能测试，根据数据去优化对应的地方

总而言之就是要遵循这些原则：自顶向下设计（1，2，3，4步），自底向上实现（5），先测量，后优化（6）。

好架构的标准：

1. 代码整齐，分类明确，没有common，没有core

2. 不用文档，或很少文档，就能让业务方上手

3. 思路和方法要统一，尽量不要多元

4. 没有横向依赖，万不得已不出现跨层访问

5. 对业务方该限制的地方有限制，该灵活的地方要给业务方创造灵活实现的条件

6. 易测试，易拓展

7. 保持一定量的超前性

8. 接口少，接口参数少

9. 高性能

2.View层

• View代码结构的规定

1. getter/setter(对此持保留意见)

2. Mark

3. 代码分段位置有讲究

• 关于view的布局(约束、frame使用封装的工具，不要直接怼数值)

• 何时使用storyboard，何时使用nib，何时使用代码写View(建议尽量使用代码)

• 是否有必要让业务方统一派生ViewController？（不要继承，使用AOP）

1. 集成成本

2. 上手成本

3. 架构维护难度

• MVC、MVVM、MVCS、VIPER（后面的都是对MVC的拆分）

• 本门心法

• 跨业务时View的处理（依赖下沉）

3.网络层

• 网络层跟业务对接部分的设计

1. 数据交付方式(delegate?block?)

2. 交付什么样的数据给业务层(胖瘦model，去model化+业务reformer)

3. 集约、离散调用方式的选择（实际上是底层与业务层的区别）

• 网络层的安全机制实现

1. 判断API调用方的权限（签名）

2. 数据传输安全（HTTPS）

• 网络层的优化方案

1. 链接建立环节优化（缓存、请求合并、DNS优化、IP表择优请求）

2. 链接传输数据优化（压缩）

3. 链接复用优化

4.持久化及动态部署

• iOS可选持久化方案：

1. NSUserDefault

弱业务、小量

2. KeyChain

加密、可保留、iCloud同步

3. File

Plist、archive、Stream

4. 数据库存储

CoreData、FMDB等

• 持久层架构隔离性要求：

1. 持久层与业务层的隔离

首先，区分model与modelLayer的概念。

model应该是更贴近业务层，但是model不太适合组件化，所以使用去Model化，在业务层再使用reformer的设计。

modelLayer实现增删改查的功能即可。

2. 数据库读写隔离

不是指对读写操作进行隔离，而是以一条界限为准，界限以外的所有数据模型的读写行为都不影响数据库的数据。CoreData这方面就做的不太好。

4. 多线程控制导致的隔离

5. 数据表达和数据操作的隔离

数据表达和数据操作应分开。

virtualRecord、强弱业务分离。

• 数据库性能调优：横切、纵切

• 数据版本迁移方案

• 数据同步方案（单向、双向）

• 动态部署方案（数据驱动、H5/RN）

5.组件化方案

• 远程调用只是本地调用功能的子集

• Target-Action方案

• 去Model

• 使用中间件Category(接口参数约束，参数封装dict)->中间件->BusinessTarget（dict还原为参数）->Business的方式解耦