这是我参与「第四届青训营 」笔记创作活动的第9天
架构面临的问题
产品和架构的生命周期
客户端、服务端、前端面临的架构问题
- 交叉问题
跨端调用:JsBridge/JNI
多端一致:统一接口层/统一实现层
数据通信:IDL协议/压缩/安全
2.公共问题
编程思想:OOPIAOP/loC
问题分解:按业务/按技术
领域建模:接口设计/DSL
服务治理:模块化/容器化
流程机制:敏捷开发/单测手段架构标准:公约文档/数据监测 - 其他挑战
- 期望高
良好的顶层设计，从上到下有统一的认知
遵循共同的规范，写出让人舒适的代码
有没有“一劳永逸”的设计，可保基业长青
什么时候能从架构工作中找到成就感 - 责任大
设计不合理:这谁写的，看我推到重来
使用不规范:这压根就不该这么用
逻辑太晦涩:这谁看得懂
编码坑太多:这是隐藏技能啊，悄无声息改代码 - 事情难
业务历久弥新，历史包袱叠加新的场景
随便动动刀子就拔出萝卜带出泥
技术栈层出不穷，老朽学不动了啊
一方面要保持成熟稳定，一方面要积极探索落地 - 疗效慢
影响复杂度的因子众多，单个因子优化不足以撼动
没有一年半载，一波治理搞不下来
没有特效药，长期在隐隐作痛中前行
往往也只是开了一个“方子”，想要根治得长期健身
典型的客户端架构
- Android OS
- Flutter
常见的架构手段
小的架构手段
- MVC
- MVP
- MVVM
各自优缺点
- AOP和OOP
构架演进
分层构架
表现层:接收用户输入，获取数据，呈现界面
业务层:处理业务数据，数据流转，安全检查
持久层:提供数据的增删改查能力
存储层:按照特定的格式存储数据
优缺点
- 优点
结构简单清晰，易于理解和管控
层级关系适合不同技能人员分工 - 缺点
对层级管控要求严格，灵活性低
为了解耦容易拆分出很多中间层
事件驱动架构
事件Event:一个消息，譬如触摸了屏幕、点击了按钮
事件处理器Processor:事件的实际消费者，对关注的消息进行订阅，消息处理的过程很灵活，可以在当前处理器“吞”掉一个消息，也可以继续将消息交由其他消息队列处理(责任链)
事件队列Event Channel:消息队列，事件将以消息的形式发布到队列中，并设计特定的派发机制来处理队列中的消息
优缺点
- 优点
适用广泛，容易扩展出不同变种
性能较好，支持消息的异步处理 - 缺点
缺少约束，消息处理器容器膨胀
处理链路容易变长，理解成本高
今日学习总结
通过今天的学习，我对客户端的构架内容有了更深刻的理解，这对我未来的发展方向有者重要的影响。
注
所有图片均来自课程PPT
