这是我参与[第四届青训营]笔记创作的第 33 天

架构面临的问题

全新业务，历史包袱，技术熵增，信息流通
客户端架构
Android OS: 应用框架层，Binder IPC，系统服务，硬件抽象层，，Linux内核
iOS: 应用框架层,核心服务层，图形图像层，内核层
Flutter:UI框架层，引擎层，嵌入层
架构设计是为了解决特定领域不同发展阶段的业务问题
不同领域的架构有明显的技术差异，但也有很多相似性
架构不仅面临技术挑战，还要应对组织业务膨胀的熵增
移动的需要利用有限的设备资源设计符合小屏幕的架构

常见的架构手段

业务抽象，分而治之，标题规范，组织管理
不同架构手段的共同目标是高内聚低耦合
找到何时业务场景的架构而不是炫技滥用
一个复杂的系统是多个架构模型的组合体
单体架构，分离架构，服务化架构，微内核架构，领域驱动设计

GoF设计模式

MVC，MVP，MVVM

MVC:优点：模块职责划分明确，主要划分层M,V,C三个模块，利于代码的维护。缺点：View和Controller容易膨胀；view和Model没有完全分离
MVP：优点：view和Model完全分离，可以修改视图而不影响模型，交互都发生Presenter.Presenter和view的交互是通过接口来进行的，方便单元测试。缺点：页面逻辑复杂的话，相应的接口也会变多，增加维护成本。
MVVM：viewModel与view耦合更彻底。viewModel只负责处理和提供数据。view Model只包含数据和业务逻辑，没有UI，方便单元测试。缺点：数据绑定使得程序较难调试，数据都是自动更新到UI

AOP

AOP:面向切面。类，切点，植入，植入器
OOP：面向对象。类，函数，函数体，编译器

IoC(控制反转)

不属于直接依赖。

大的架构手段

架构演进的例子

解决问题，保持重构，迭代升级，应对衰退
架构随业务发展有简单变得复杂是规律
没必要最初用复杂的架构来解决简单问题
需要用规范持续重构来对抗代码的腐朽
孕育期：做一个信息流产品，可以无限刷的列表（想法）
婴儿期：产品功能开始变多，需要拆分模块
学步期：业务场景变多，需要拆分业务
青春期：不同业务和模块混合，需要解耦——事件驱动模型
壮年期：业务变得更加内聚，需要灵活插拔（数组插件，微内核架构）
稳定期：用户规模和团队稳定，历史包袱重（微服务架构）
贵族期：对抗架构衰老
官僚期：代码混乱无序

客户端架构设计和应用|青训营笔记