Android-客户端架构设计和应用|青训营笔记
这是我参加「第四届青训营」笔记创作活动第八天
客户端架构设计和应用
产品和架构的生命周期
、
不同技术领域的架构问题
典型的客户端架构——Android OS
应用框架层
- ApP开发者直接使用的接口层，UI的实现，数据的处理、资源的使用，都是利用这一层的API
系统服务
- 提供窗口管理、相机、音视频等重要的系统能力，包含各种子系统，内部逻辑十分庞大，往下调用HAL层封装的硬件能力，往上通过Binder暴露可以远程调用API
Binder IPC
- 提供跨进程访问能力，APP可以高效的访问由系统进程暴露的能力，APP进程与系统进程之间的通信是典型的C/S模型
硬件抽象层
- 屏蔽底层不同驱动差异，使得系统服务层可以快速适配到不同硬件设备
Linux内核
- CPU、内存、唤醒服务等重要的驱动实现都是基于该层操作系统的核心实现
典型的客户端架构——IOS
- 应用框架层
- Eventkit、GameKit、Mapkit、Pushkit
- 核心服务层
- Loocation、Motion、Health、GPS、Telephony、Foundation
- 图形图像层
- ULKit、Anumation、Graphice、Images
- 内核层
- Bluetooth、Security
典型的客户端架构——Flutter
- UI框架层
- 提供不同样式的组件和动画，声明式UI。采用Dart作为编程语言，能够同时支持JIT和AOT，在开发调试和运行阶段都能有不错的效率提升
- 嵌入式
- Floller引擎需嵌入不同的平台；Android/Windows/Linux等
- 引擎层
- 将上层定义的UI树转换层屏幕像素，提供平台调用接口和DArt虚拟机
常见的架构手段
小的架构手段——MVP/MVC/MVVM
小的架构手段——AOP
小的架构手段——LOC
直接依赖：
- 一个对象A要完成其功能，通常需要依赖于其他对象B、C等，其具体的实现方式就是在对象A中构建其所依赖的对象B、C等，这就相当于A控制了它所依赖的对象B、C
控制反转：
- 打破A直接控制B这层关系，B对象的生命周期交由LOC容器来控制，A不用再去寻找和初始化其所依赖的B、C了，只用等着LOC容器的投喂就可以
Service：通过接口或者类定义服务
大的架构手段
分层架构
- 表现层：接受用户输入，获取数据，呈现界面
- 业务层：处理业务数据，数据流转，安全检查
- 持久层：提供数据的增删改查能力
- 存储层：按照特定的格式存储数据
优点：
- 结构简单清晰，易于理解和管控
- 层级关系适合不同技能人员分工
缺点：
- 对层级管控要求严格，灵活性低
- 未来了解耦容易拆分出很多中间层
事件驱动架构
-
事件Event：一个消息，譬如触摸了屏幕、点击了按钮
-
事件处理器Processor：事件的实际消费者，对于关注的消息进行订阅，消息处理的过程的过程很灵活，可以在当前处理器“吞”掉一个消息，也可以将继续将消息交由其他消息队列处理
-
事件队列Event Channel：消息队列，事件将以消息的形式发布到队列中，并设计特定的派发机制来处理队列中的消息
优点：
- 使用广泛，容易扩展出不同变种
- 性能较好，支持消息的异步处理
缺点：
- 缺少约束，消息处理器容器膨胀
- 处理链路容易变长，理解成本高
事件驱动架构
- 事件发布：【YOu Moved】事件被处理器【Customer】接受处理
- 事件处理：【Customer】事件转换为【Change Address】并发布到消息队列
- 事件处理：【Quote】和【Claims】两个事件处理器都订阅了【Change Address】消息，并收到了从消息队列派发出的消息
- 事件处理：【Quote】将消息转换为【Recalc Quote】并将其派发给【Notification】这个处理器【Claims】将消息转换为【Update Claime】并将其派发给【Notification】和【ADjustment】
微内核架构
- 宿主容器：Core System ，一般不包含具体业务逻辑，而是从抽象出模型，相当于一个运行环境，供不同业务以插件的形式在其中运行
插件：
- Plug-in Compinent ，具体的业务实现，通过一定的技术手段挂载到宿主容器中，插件一般可以访问宿主的资源
优点：
- 高扩展性，需要什么就开发什么
- 插件隔离，能够简化业务耦合度
缺点
- 对宿主容器的要求很高，且宿主不易扩展
- 插件的注册和通信机制通常比较复杂
插件原理Mira ClassLoader
- 初始化时会调用MiraClassLoader.installHook()实现了在系统的BootClassLoader与应用PathClassLoader之间插入自定义的MiraClassLoader。
- 形成BootClassLoader--》MiraClassLoader-->pathClassLoader-->类加载结构，后续宿主里每一个类的加载与查找细节都会透明的经过MiraClassLoader
微服务架构
- 请求接入：服务使用方发起请求，请求以一定的方式（可以直接调用，也可以跨进程调用）发送到服务注册中心，等待请求处理
- 服务调度：Broker，将服务请求调度到对应的微服务节点上进行处理
- 微服务：Service Component,一个高度内聚的模块集合，对外暴露服务接口。每一个微服务都是独立的，分别向服务注册中心注册自身所能提供的服务接口
优点
- 健壮性好，单个服务不影响全局
- 服务隔离，服务之间互不相耦合
缺点：
- 容器出现服务数量腹胀难以管控
- 服务发现和通信需要额外的成本 不同形态的架构
