这是我参与「第四届青训营 」笔记创作活动的第7天
1. 架构面临的问题
产品和架构的生命周期
不同技术领域的架构问题
- 前端: 语言: JS/TS/H5/CSS
框架: RN/Angular/Vue/JQuery
组件: ElementUI/AmazeUI
- 服务端: 语言: Java/Python/Go
框架: Spring/Flask/Beego
平台: CentOS/Windows
- 客户端: 语言: Java/Kotlin/Swift
框架: GMS/Flutter/Cocos
平台: Android, ios
交叉问题 公共问题
跨端调用: JSBridge/JNI... 编程思想: OOP/AOP
多端一致: 统一接口层 问题分解: 按业务/技术
数据通信: IDL协议/压缩/安全 领域建模: 接口设计/DSL
2. 常见建构手段
小的架构手段-GoF设计模式
单例模式哪个更优：
B和C没有绝对的更优，B多了一个懒加载。
B在虚拟机角度更优 因为它用了volatile 保证内存数据之间的同步
小的架构手段-MVC
如果页面元素很多，控制器很多 MVC就不太适合解决这种很复杂的逻辑
小的架构手段-MVP
P是表现层，View还是接收用户输入，但是视图会明确定义一个更新UI的接口
public interface IView{
void updateUI(string text)
}
然后当视图有数据更新的时候 我们是通过表现层操作模型的
Presenter怎么调用模型qvq
他是直接调用模型里的累加器，当数据更新以后，通知表现层再更新UI。
好处：数据和模型完全解耦 但这样Presenter会变得很复杂
小的架构手段-MVVM
之前的presenter换成了ViewModel
当视图接受用户操作的时候 通过视图直接调用到视图模型的更新器，完成数据的更新。之后通知数据更新->实现UI刷新。
总结
3. 架构演进
孕育期：单体架构
婴儿期：分离架构（因为产品功能开始变多，所以需要拆分模块）
学步期：业务1 业务2...业务N （业务场景变多 拆分业务，比如拆分出视频业务，架构自成体系）
青春期：不同业务模块混合需要解耦（需要约定模块可以对外提供的能力，模块之间需要遵循相同的调用方式，旧的模块需要按照相同标准来改造，使用方不应该直接依赖于实现方）
壮年期：使用宿主-插件架构
