客户端设计（下）：场景流派与实战设计方式

客户端架构：为什么、什么时候、怎么做https://blog.csdn.net/mix39/article/details/161257993客户端设计（上）：MVC/MVP/MVVM 与高内聚低耦合https://blog.csdn.net/mix39/article/details/161257807客户端设计（中）：OOP、SOLID 与设计模式https://blog.csdn.net/mix39/article/details/148036409

客户端设计（下）：场景流派与实战设计方式https://blog.csdn.net/mix39/article/details/161322269?spm=1001.2014.3001.5501

前言

ok，我们前面三张文章讲了为什么要做架构、什么时候需要架构和怎么做、常用设计原则和设计模式，感兴趣可以点击上方链接再看看，再讲一下这些年遇到的具体的问题和解决策略。

本文涉及到代码的地方均已微信为例，提供想象空间，并不是真的业务代码，只抽象出这些年见过的一些常见公共通用架构设计能力。写过安卓app或者客户端app代码的人都会，俺做一下整理归纳。

8.6 大型互联网 App

核心矛盾：多团队并行 + 快速迭代 + 稳定性要求高

一句话：互联网 App 的设计重点是"怎么让几百人同时改一个 App 还不炸"。

互联网 App 的设计核心：

• 解耦——几百人改同一个 App，改动不能互相影响
• 可控——任何功能都能远程开关，任何异常都能降级
• 可观测——线上发生了什么必须看得见，不然就是完全不可观测
• 可恢复——出问题能秒级回滚，不用发版

8.7 厂商类型内置 App

核心矛盾：一套代码跑几十个机型/品牌/渠道 + 系统限制多 + 资源受限

一句话：厂商 App 的设计重点是"一套代码跑几十个项目，改一次全部生效"。

厂商 App 的设计核心：

• 通用——套代码适配所有差异，不是每个场景写一套

• 可插拔——功能模块可以按需组合，不同 App 不同配置

• 可配置——同一个二进制跑在不同渠道，行为由配置驱动

• 极致省——包体积、内存、功耗，每一点都要抠

8.8 具体设计方式详解

8.6 和 8.7 定义了两种场景流派的设计重点，下面展开每个设计方式的详细做法。

21 种设计方式总览：

8.8.1 现代化编程

三件套：声明式 UI + 状态管理 + 异步编程

声明式 UI

命令式：告诉 UI 怎么做（setText、setVisibility、setColor……）
声明式：告诉 UI 是什么样（state → UI 映射，框架帮你刷新）

命令式（Android View）： if (hasUnread) { badgeView.setVisibility(VISIBLE); badgeView.setText("3"); } else { badgeView.setVisibility(GONE); } 声明式（ArkTS）： if (this.hasUnread) { Badge({ count: this.unreadCount }) } // state 变了 UI 自动变 声明式（Vue）： <Badge v-if="hasUnread" :count="unreadCount" /> // state 变了 UI 自动变

好处：不用手动同步 UI 和数据——数据变了 UI 自动跟着变，不会出现"数据更新了 UI 忘了刷"的 bug。

代表：ArkTS（鸿蒙）、Compose（KMP）、React、Vue

状态管理

本质是观察者模式的工程化——UI 观察状态，状态是唯一权威。

原则： 1. Single Source of Truth——一个状态只有一个写入者 2. 状态不可变——改状态 = 创建新状态，不是原地改 3. 状态下沉，事件上浮——子组件只读父组件的状态，事件回调给父组件处理 ArkTS：@State / @Prop / @Link 装饰器，AppStorage 全局状态 React：useState + useReducer + Context，Redux / Zustand 全局状态 Vue：ref / reactive + Pinia 全局状态 KMP Compose：MutableStateFlow + StateFlow， ViewModel + stateIn

异步编程

链式编程 + 闭包

链式的本质是流畅接口（Fluent Interface）——方法返回 this 实现链式调用，Builder 模式是链式的一种应用。

badgeManager .tab("chat") .show() .withNum(3) .withAnim(true) .onComplete { log("done") }

闭包让行为参数化——把"做什么"当参数传进去，而不是写死。

代表：ArkTS、React Hooks、KMP Compose、Vue Composition API

8.8.2 生产者消费者模式

生产者和消费者互不知道对方存在，中间靠队列解耦。

Producer → Queue → Consumer (未读数数据源) (消息队列) (未读数展示)

客户端场景：

为什么用生产者消费者：

• 解耦——生产者和消费者各自独立演进
• 异步——生产不等消费，不阻塞主流程
• 缓冲——峰值时队列兜住，消费端按自己节奏处理
• 可控——队列大小、消费速率、背压策略都可配置

8.8.3 线程池隔离

不同业务用不同线程池，一个炸了不拖垮其他。

有规模的 App 一般都需要，特别是启动优化那块——不然一启动就噶或者请求个数据一直搁那转圈圈。需要线程管控、资源调度。

大型 App 启动时如果不同业务同时开线程去进行耗时操作，有可能整个 App 都在抢夺资源，抢夺资源失败的业务直接 return 没有处理线程任务。且数量太多 App 可能直接噶掉。

❌ 一个共用线程池： 未读数加载 + 图片下载 + 数据同步 + 埋点上报 全挤在一起 图片下载阻塞了 → 未读数加载不了 → 用户体验炸 ✅ 隔离线程池： IO_POOL：图片、文件 BADGE_POOL：未读数计算 UPLOAD_POOL：埋点上报 DB_POOL：数据库读写 互相不影响

线程切换应有且仅有一条规则：

• 主线程 → 后台：统一一个入口（如 Dispatchers.io() 或统一的 ThreadScheduler）
• 后台 → 主线程：统一一个入口（如 Dispatchers.main() 或统一的 UiHandler）
• 不允许业务代码直接 new Thread、直接 runOnUiThread

线程池分配原则：

• 关键路径独占：启动、未读数展示这种用户可感知的用独立池
• 非关键路径共享：埋点上报、日志这种可以共享一个大池
• 第三方 SDK 隔离：SDK 用自己的池，别跟你的业务挤在一起

8.8.4 抗弱网

核心思想：没网不是空白页，慢网不是转圈页

客户端弱网设计的黄金法则：

每次网络请求都要问自己： 1. 失败了怎么办？→ 兜底值 2. 超时了怎么办？→ 缓存值 3. 没网了怎么办？→ 离线数据 4. 数据过期了怎么办？→ 先展示旧的，后台拉新的 推荐：TTL 过期 + 读时刷新 组合

8.8.5 Native 壳 + 跨端组件业务

壳稳定、肉灵活——平台能力在 Native，业务逻辑在跨端。

跨端框架的代价：跨端框架省的是编写成本，不省验证成本。选型时要问：双端验证成本、能力边界、抽象泄漏、工具链成熟度、代码归属、三端差异文档化、语法基因。

选型决策线：

业务复杂度低 + 组件够用 + 静态页面多 → 跨端框架收益大 业务复杂度高 + 需要动态能力 + 页面交互复杂 → 跨端框架成本 ≥ 原生

8.8.6 场景切面（AOP）

横切逻辑——日志、埋点、权限、性能监控、登录检查——从业务里抽出来集中管理。

✅ 有 AOP： @RequireLogin @Trace("chat_open") @Log fun openChat() { chatManager.open(...) // 只写业务 }

客户端怎么做 AOP：

8.8.7 动态化设计

编译期定死的越少越好，运行时可变的越多越好。

动态化三层：

• L1 资源动态化：运行时加载图片/动画/字体 → 最简单
• L2 布局动态化：服务端下发 UI 描述，客户端渲染 → 中等
• L3 逻辑动态化：服务端下发脚本/规则，客户端执行 → 最强但风险最大

动态化设计原则：降级兜底、版本兼容、安全校验、大小控制、离线可用、回滚能力。

8.8.8 组件化 vs 模块化

组件化设计要点：组件可独立运行、可插拔、组件间通信（路由+接口+事件总线）、组件隔离（api/implementation分离）、资源隔离、组件生命周期。

8.8.9 事件驱动设计

发出事件的人不知道谁在监听，甚至不知道有没有人监听。

解耦程度：直接调用 < 观察者 < 事件驱动

设计原则：

1. 事件命名表达"发生了什么"，不是"要做什么"
2. 事件携带数据，不携带行为
3. 事件要有生命周期——谁注册谁反注册
4. 事件总线不是万能的——一对一强依赖用接口，链路需要可追踪用接口
5. 防事件风暴——事件 A 触发 B，B 触发 C，C 又触发 A，循环了

8.8.10 内存防御设计

内存泄漏不是写错了一行代码，是架构设计没管好生命周期。

防御原则：对外不信任，对内信任——模块边界全加防御，模块内部正常写。

8.8.11 降级设计

L0: 完美体验 → 全部功能正常 L1: 功能降级 → 核心功能可用，非核心关闭 L2: 内容降级 → 实时数据不可用，用缓存数据 L3: 展示降级 → 富媒体不可用，用文字/占位图 L4: 优雅失败 → 功能完全不可用，提示用户 L5: 崩溃 ← 必须尽一切努力避免

降级设计原则：

1. 每个关键路径都要有降级方案
2. 降级是配置驱动的，不是代码写死的
3. 降级要可观测（埋点上报）
4. 降级要可恢复（开关关了自动恢复）

8.8.12 缓存设计

缓存三层：请求 → 内存缓存 → 磁盘缓存 → 网络

客户端推荐：TTL 过期 + 读时刷新 组合——先返回旧数据，后台静默拉新。

8.8.13 启动设计

启动很大程度上取决于设计，而非编码。

设计原则：

1. 有向无环拓扑排序——依赖不能成环
2. 核心路径预加载 + 非核心懒加载 + 空闲时预热
3. 每个阶段耗时打点，启动慢了能定位
4. 任何任务失败都不能卡住启动

8.8.14 状态机设计

当一个对象的行为取决于它当前的状态，且状态之间有严格的转换规则时。

设计原则：

1. 状态是有限的、明确的——枚举所有状态，不允许"未知"

2. 转换是受限的——定义合法转换，非法转换直接拒绝

3. 副作用在转换上，不在状态上

4. 状态机优先单调（只能往前走，除非显式重置）

8.8.15 防御式编程

假设所有外部输入都是恶意的，所有外部调用都可能失败。

过度防御：每个方法每个参数都判空，代码 50% 是防御逻辑 → 可读性炸
适度防御：模块边界防御，内部信任 → 清晰 + 安全

原则：对外不信任，对内信任。

8.8.16 通信设计

强依赖用接口，弱依赖用事件。接口调用要超时。事件不能代替接口。跨进程通信最小化。

8.8.17 通用能力设计

一次改动，后续再加需求改动量最小化。

这是厂商类型 App 最看重的设计哲学——通用能力一旦写好，新的 App、新的渠道、新的场景来了，改动量最小化。

通用能力 vs 专用能力：

通用能力设计四步法：

第 1 步：抽象共性 共性抽象成接口，差异抽象成配置。 第 2 步：配置驱动 所有差异用配置表达，不用代码表达。 配置来源：本地默认值 → 远程下发 → 运行时环境感知 第 3 步：扩展点预留 不确定未来会不会变的地方，留扩展点（回调/策略/插件） 确定不变的地方，坚决不抽象 第 4 步：验证套件 配置校验 → 兜底值 → 异常上报 → 日志追踪

通用能力设计原则：

过度通用的信号：配置项比业务代码还多、为了通用引入了三层抽象、新接一个 App 还是要改通用代码、通用能力的开发比业务开发还慢。出现这些信号，说明抽象过头了，该收缩边界。

8.8.18 设计思维

从需求推导到设计：

需求 → 理解问题 → 识别变化点 → 选择模式 → 定义接口 → 写实现

设计评审的核心问题：

8.8.19 音频焦点策略

这是厂商类型 App 的核心设计问题之一，也是观察者 + 状态 + 策略的综合实战。

为什么需要音频焦点：

系统可能有几十种音源——音乐、导航、电话、倒车提示、系统通知……如果每种音源都自己播放，几秒内可能变化十几次，造成混音 chaos。

音频焦点策略就是让所有音源遵守同一套规则：出声前申请焦点，拿到才播放。

长焦点 vs 短焦点：

混音排查流程：

1. 两个音源同时播放了 → 混音了 2. 检查两个音源是否都申请了焦点 ├─ 没申请焦点就播放 → 那个业务的问题 └─ 都申请了焦点 3. 检查最后一次焦点在谁手里 ├─ 焦点在A，但B也在播放 → B 的业务问题 └─ 焦点只有一个，另一个没拿到焦点 4. 拿到焦点的音源正常播放，但另一个音源也在响 ├─ 另一个业务调了播放接口 → 那个业务的问题 └─ 另一个业务根本没调播放接口 → Audio框架的问题

音频焦点设计用到的模式：

8.8.20 Pipeline（流水线编排）

把一个复杂流程拆成多个阶段，每个阶段独立处理、独立线程池、阶段间用队列连接。

生产者消费者是"一个生产一个消费"，Pipeline 是"一串阶段串起来，每个阶段既是消费者又是生产者"。

输入 → Stage1(解析) → Queue1 → Stage2(校验) → Queue2 → Stage3(处理) → Queue3 → Stage4(输出) → 结果

三要素：Stage（阶段）、Queue（队列）、ThreadPool（线程池）

实战例子：直播推流管线

Camera 采集 → OpenGL 渲染 → MediaCodec 编码 → 封包 → RTMP 推流 30fps GPU 处理 硬编耗时 快 受网络影响

每个阶段速度不一样——Camera 30fps 稳定输出，编码可能跟不上，推流看网络。如果一条线程串下来，推流卡了编码也卡了，编码卡了相机也卡了。用 Pipeline：每个阶段自己的队列兜住，推流慢了编码队列积压，背压传导回相机降帧，而不是全线崩溃。

背压：下游处理不过来，压力向上游传导。

背压不是自动的——队列满了 BlockingQueue.put() 会阻塞生产者线程导致线程饥饿，实际工程中需要显式选择背压策略：丢帧（offer 失败就丢）、等待限时（offer + timeout）、降速（通知上游降频）。不同场景选不同策略，不能无脑用阻塞队列。

什么时候用：

8.8.21 Hook（钩子）

不修改原始代码，在运行时插入自己的逻辑或者替换原始行为。

Hook 不是 GoF 23 种设计模式之一，但它是一种广泛使用的设计思想——预留扩展点，外部插入逻辑。

从温和到暴力，Hook 分很多层：

实战例子1：反射替换（运行时 Hook）

正常流程：App → IActivityManager.startActivity() → 系统检查 Manifest → 拒绝 Hook 后： App → AMSProxy.startActivity() → 替成占坑 Activity → 系统检查通过 → 换回真实 Activity

三步走：找到目标 → 构造替代品 → 偷梁换柱

1. 反射拿到系统的 AMS 代理对象
2. 创建自己的代理类（持有原始对象），在 startActivity 里把 Intent 替掉
3. 把代理塞回去，以后系统调的都是你的代理

本质上就是代理模式，只不过代理对象是运行时偷偷塞进去的。

实战例子2：ClassLoader 拦截（加载时 Hook）

场景：插件化框架加载插件的类。

正常加载：ClassLoader.loadClass("PluginActivity") → 找不到 → 崩溃 Hook 后： ClassLoader.loadClass("PluginActivity") → 拦截 → 用插件 ClassLoader 加载 → 成功

两种 Hook 对比：

Hook 的设计模式本质：Hook 是目的（插入逻辑改变行为），各种设计模式是实现手段。你在日常开发中写的 onCreate()、setOnClickListener()、Interceptor，都是 Hook——只是你没叫它 Hook。