这是我参与「第四届青训营 」笔记创作活动的的第9天
客户端架构设计和应用
01 架构面临的问题
1.1 产品和架构的生命周期
1.2 不同技术领域的架构问题
1.3 一些其他挑战
1.4 典型的客户端架构——Android OS
1.5 典型的客户端架构——IOS
1.6 典型的客户端架构——flutter
1.7 小结
-
架构设计是为了解决特定领域不同发展阶段的业务问题
-
不同领域的架构有明显的技术差异，但也有很多相似性
-
架构不仅面临技术挑战，还要应对组织业务膨胀的嫡增
-
移动端需要利用有限的设备资源设计符合小屏幕的架构
02 常见的架构手段
2.1 小的架构手段——GoF设计模式
2.2 小的结构手段——MVC
视图：XML
控制器：Activity中设置点击事件
模型接口：更新UI
数据和视图并没有完全解耦，控制器和视图耦合在一起,Activity会膨胀
2.3 小的架构手段——MVP
数据和视图完全解耦了，控制回路太庞大。
2.4 小的架构手段——MVVM
2.5 MVC/MVP/MVVM
2.6 小的架构手段——AOP
面向切片编程思想。
2.7 小的架构手段——IOC
2.8 小的架构手段——IoC：实例SPI
2.9 大的架构手段
2.10 小结
-
不同架构手段的共同目标是高内聚低耦合
-
找到适合业务场景的架构而不是炫技滥用
-
一个复杂的系统是多种架构模型的组合体
03 架构演进的例子
3.1 孕育期
做一个信息流产品，可以无限刷的列表
-
首先，需要实现一个列表，支持上下滑动
-
然后，每次滑动，都需要请求服务端数据
-
接着，列表的每一项都需要响应点击操作
3.2 婴儿期
产品功能开始变多，需要拆分模块
-
首先，需要支持图文内容的组合混排显示
-
接着，需要引入账号体系，用户注册登录然后，用户可以收藏感兴趣的内容并分享 ...
-
继续，场景越来越多，拆分网络和多线程
3.3 学步期
业务场景变多，需要拆分业务
-
首先，支持用户发布文章，并给予奖励
-
接着，视频这个重要的内容也需要支持
-
然后，不同业务之间越做越大需要拆分
-
继续，拆分出视频业务，架构自成体系
-
继续，拆分出中台业务，供多业务使用
3.3.1 学步期——分层架构
3.4 青春期
不同业务和模块混合，需要解耦
-
首先，需要约定模块可以对外提供的能力
-
接着，模块之间需要遵循相同的调用方式
-
然后，旧的模块需要按照相同标准来改造 ...
-
继续，使用方不应该直接依赖于实现方
3.4.1 青春期——事件驱动架构
3.4.2 青春期——事件驱动架构实例
3.5 壮年期
业务变得更加内聚，需要灵活插拔
-
首先，扫一扫等能力不是所有场景都需要
-
接着，视频的子能力可以拆解后按需使用
-
然后，越来越多的业务想动态化发布产物
-
继续，动态化发布引入很多问题需要调优
3.5.1 壮年期——微内核架构
3.5.2 壮年期——插件原理Mira ClassLoader
3.5.3 壮年期——插件原理Mira插件注册
3.6 稳定期
用户规模和团队稳定，历史包袱重
-
首先，经过前期快速发展已经积累了大量历史包袱
-
接着，需要深入了解业务才能设计出更合理的架构
-
然后，很多改动牵一发动全局，代码被迫变得更差 ...
-
继续，新旧技术栈共存，版本依赖冲突，冗余代码
3.6.1 稳定期——微服务架构
3.7 贵族期
3.8 官僚期
-
人们相互甩锅
-
代码混乱无序
3.9 不同形态的架构
3.10 小结
-
架构随业务发展由简单变得复杂是规律
-
没必要最初用复杂架构来解决简单问题
-
需要用规范持续重构来对抗代码的腐朽
04 成为优秀架构师
定义问题 → 确定架构 → 方案落地 → 结果复盘
4.1 认清问题
4.1.1 认清问题——分类
架构的问题是盘根错节的，将所有问题放在一起，就有轻重缓急之分，就有类别之分
区分问题的类别，就能在一定的边界内，匹配上对应的人来解决问题
4.1.2 认清问题——分级
挑战、问题、手段这些经常混为一谈，哪些是挑战?哪些是问题?那些是手段?
其实这些都是一回事，就是矛盾，只是不同场景下，矛盾所在的层级不同
4.1.3 认清问题——问题背后的问题
4.2 勤于编码
Ctrl c + v
