手段
业务抽象
分而治之
标准规范
组织管理

演进
解决问题
保持重构
迭代升级
应对衰退

公共问题

  • 编程思想
  • 问题分解
  • 领域建模
  • 服务治理
  • 流程机制
  • 架构标准

业务发展 - 越来越复杂 - 必然趋势

  • 理解成本变高

    • 宏大的规模不好理解
    • 复杂的结构不好理解

  • 预测难度变大

    • 业务变化
    • 技术变化

Android OS

应用框架层

App开发者直接使用的接口层，UI的实现，数据的处理，资源的使用，都是用这一层的API

Binder IPC

提供跨进程访问的能力，App可以高效的访问由系统进程暴露的能力，App进程与系统进程之间的通信是典型的C/S模型

系统服务

提供窗口管理，相机，音视频等系统能力，包含各种子系统，内部逻辑很庞大，往下调用HAL层封装的硬件能力；往上通过Binder暴露可以远程调用的API

硬件抽象层

屏蔽底层不同驱动的差异，使得系统服务层可以快速适配到不同的硬件设备

Linux内核

CPU、内存、唤醒服务等重要的驱动实现都给予该层操作系统等核心实现

IOS

应用框架层 Cocoa touch(application layer)

  • EventKit
  • GameKit
  • MapKit
  • PushKit

图形图像层 media layer

  • ULKit
  • Animation
  • Graphics
  • Images

核心服务层 core services

  • Location
  • Motion
  • Health
  • GPS
  • Telephony
  • Foundation

内核层 core os

  • Bluetooth
  • Security
  • Accessories

Android vs IOS

Activity ViewController
Intents Segues/ViewControllers
Service “Backgrond Mode”
ContentProvider CoreData
Layouts Storyboards and scenes

Flutter

UI框架层

提供不同样式的组件和动画，声明式UI，Dart作为编程语言，同时支持JIT和AOT

引擎层

将上层定义的UI树转换成屏幕像素，提供平台调用接口和Dart虚拟机

嵌入层

Flutter引擎需嵌入不同的平台

  • 架构设计是为了解决特定领域不同发展阶段的业务问题
  • 不同领域的架构有明显的技术差异，但是也有相似性
  • 架构要面临技术挑战，还要应对组织业务膨胀的熵增
  • 移动端需要利用有限的设备资源设计符合小屏幕的架构

小的架构手段

GoF设计模式

MVC

  • View和Controller容易膨胀
  • View和Model没有完全分离

    MVP

  • View和Model完全分离，可以修改试图而不影响模型，交互都发生在Presenter
  • Presenter与View的交互是通过接口来进行的，方便单元测试
  • 页面逻辑复杂的话，响应的接口也会变多，增加维护成本

    MVVM

  • ViewModel只负责处理和提供数据
  • ViewModel里面只包含数据和业务逻辑，没有UI，方便单元测试
  • 数据绑定使得程序较难调试，因为数据都是自动更新到UI

AOP

  • OOP
    1
    2
    3
    4
    类：代码以函数（Method）和字段（Field）的形式封装在类中
    函数：定义函数签名和函数体
    函数题：定义函数的执行逻辑
    编译器：将源代码转换成可执行代码
  • AOP 
    1
    2
    3
    4
    类：代码以切点（PointCuts），属性（Attributes）、植入（Advice）的形式封装在类中
    切点：定义植入（Advice）的锚点
    植入：定义需要植入的逻辑
    植入器：将植入逻辑插入到锚点处

loC

  • 直接依赖：一个对象A要完成其功能，通常需要依赖于其他对象B，C等，其具体的实现方式就是在对象A中构建（new）其所依赖的对象B、C等，这就相当于A控制了它所依赖的对象B、C
  • 控制反转：打破A直接控制B这层关系，B对象的生命周期交由loC容器来控制，A不用再去寻找和初始化（控制）其所依赖的B、C了，只用等着loC容器的投喂就可以
  • 实例SPI

大的架构手段

  • 单体架构
  • 分离架构
  • 分层架构
  • 服务化架构
    • 需要约定模块可以对外提供的能力
    • 模块之间需要遵循相同的调用方式
    • 旧的模块需要按照相同的标准来改造
    • 使用方不应该直接依赖于实现方
  • 事件驱动架构
  • 宿主-插件架构
  • 微内核架构
  • 微服务架构
  • 领域驱动架构

summary

  • 不同架构手段对共同目标是高内聚低耦合
  • 找到适合业务场景的脚骨
  • 一个复杂系统是多种架构模型的组合体

定义问题 确定架构 方案落地 结果复盘

认清问题 - 分类 && 分级

基础能力

常规能力建设

服务发现（SPI）

  • 基础能力服务化是一个重要的解耦手段

    路由能力

  • 统一schema信息管理，规范多端路由框架的使用接口

    字节码增强能力

  • 加强字节码增强技术的易用性，同时避免滥用

    网络能力

跨端能力建设

Web容器

  • 建设更好的web容器生态，为业务提供容易接入，性能可靠，灵活性高的容器组件

    JSBridge

  • 统一多套JSB框架，多端暴露一致的Native能力

Flutter

UI相关能力建设

基础UI控件

  • 保持基础的UI控件在多端的一致性

    夜间模式

  • 夜间模式能提升图文场景下的用户体验

    Native容器

  • Native容器的统一有利于代码复用和页面基础能力建设

    技术栈突破

    静默灰度能力

  • 显著提升版本升级率，加快需求验证

    新技术预研

  • 保持技术热情，探寻更好的解决方案

标准化

规范

  • 树立共同的认知

    公约/考试

    数据公示

    工程素养小活动

工具

  • 保障规范的落地

    重复资源

    大文件、大函数、圈复杂度

    依赖检测

宏观指标

  • 重复率
  • 组件数

无用代码

  • 无用setting
  • 未调用的函数

    工程架构

    物理结构优化

  • 良好的工程结构-开发的第一印象

    工程组织模式

  • 提供简洁高效的工程组织关系

    仓库治理

  • 保持仓库层级和数量在标准范围

    多端工程一致性

  • 保持多端在公共仓库和组件使用上的一致性

    组件治理

  • 目的：更新技术栈，服务多元业务

    组件依赖治理

  • 消费和拦截不合理的组件间以来

    组件内标准化改造

  • 保持每个组件职责清晰

    多端组件能力统一

  • 抹平不必要的组件多端差异

插件治理

  • 持续提升插件这项重度使用的动态化能力，能够让业务迭代更为灵活

    插件间依赖治理

    插件能力建设

  • 完善插件相关各项基础能力

    插件标准化改造

  • 规范多端插件调用和启动方式

    全局复杂度治理

    工具建设

  • 完善有利于代码复杂度问题消费的工具

    存量问题消费

  • 持续为各业务方消费存量代码复杂度问题做好配套服务

    防劣化建设

  • 通过规范或流程卡口帮助复杂度指标不劣化

业务架构

解耦

多业务之间的依赖

  • 提升单个业务迭代效率

  • 形成业务间依赖规范

    组件之间的不合理依赖

  • 降低组件迁移成本

  • 形成组件间接口规范

逻辑优化

业务设计和实现优化

  • 提升业务的复用率

组件逻辑优化

  • 提升组件的通用性

  • 减少重复代码，能力更稳定

核心能力中台化

视频

图文

Feed

内容生产

目标

技术基建

  • 工具流程易使用
  • 品质优化可复制
  • 质量基建强约束
  • 整体架构高可用

目标

  • 平台接入工具便捷 -> 持续集成流水线、埋点上报和分析平台，实验平台等
  • 本地工具随取随用 -> 各类IDE插件、编译工具链等可直接用于新产品
  • 通用场景直接复用 -> 诸如磁盘、内存、线程调度优化等，可直接复制迁移
  • 特殊场景沉淀基建 -> 诸如启动、预加载、分片处理等，需沉淀框架能力，形成通用组件
  • 线下监测分析准入 -> 代码静态检查和运行时监控、自动化测试、、内测众测等通用能力和流程
  • 线上监控止损归因 -> 各类指标监控报警手段、反馈舆情收集、熔断和回滚机制
  • 工程结构简洁清新 -> 架构模型、演进思路、工程要素的组织关系要做到清晰明确
  • 技术栈保持先进性 -> 工具、组件、Android版本、跨端、热修等动态化能力需持续更新

多个业务

  • 业务之间低耦合
  • 扇入扇出标准化
  • 业务集合可维护

目标

  • 服务注册发现机制 -> 利用中心服务管理模块进行解耦
  • 公共模块下沉机制 -> 利用具备公共代码的模块进行解耦
  • 接口使用规范一致 -> 多业务对外暴露的接口遵循相同的命名、参数、语义规范
  • 业务外部依赖收敛 -> 最小化业务对外部的依赖，同步多业务相同依赖的版本
  • 业务复用的清单制 -> 业务组合的场景很多，比如大业务拆开分层组合，需整体维护组合清单
  • 业务集合的准入制 -> 大而全，但整体可复用程度低的业务稽核，不如少而精

单个业务

  • 具备好的扩展性
  • 支持傻瓜式集成
  • 宿主依赖接口化

目标

  • 外围能力可插拔 -> 业务内部具备事件路由能力，能够将事件调度到外围
  • 扩展定制有范式 -> 差异化改造可用参照已有的扩展方式，不需要魔改
  • 样例文档完备 -> 可用人工支持频次的降低来衡量样例文档是否健全
  • 侵入式改造少 -> 减少集成的改造点和代码量
  • 数据链路闭环 -> 从外部获取数据后，尽量业务内部闭环处理，交付结果给外部
  • 默认实现兜底 -> 外部依赖尽可能有兜底实现，可让业务独立可调试