Android 业务场景架构实战

0. 背景：前端视角下的购买流程 在具备支付功能的 APP 中，下单购买流程是绕不过去的话题，时至今日，从体验端到设计端，这套流程已经趋于统一的方案。站在用户视角观察，点击“购买”按钮后，APP 会拉

本文记录了笔者在真实业务场景里遇到的适配问题，本文在保留技术方案设计的基础上，隐去了部分实现细节。 1. 背景介绍与关键问题 1.1 业务背景 对于 Android APP 的介绍 这是一个用于配合智

1. 引言：问题从何而来 这是一个真实的业务场景，发生在前后端协同工作的过程中。 1.1 场景复现 在“手机主题管理” APP 中，用户可以在“我的主题”页查看自己账号下的所有已购买主题。由于已购买主

我在使用 Kotlin Flow 实现业务功能模块的过程中，遇到一些细节上的问题，虽然微小，但仍值得思考、学习和记录。请将本文结合前一篇文章《【业务场景架构实战】4. 支付状态分层流转的设计和实现》共

title: 支付状态分层流转的设计和实现 设计目标 层次清晰：结构遵循 UI → ViewModel → Repository → SDK/Backend，并尽可能精炼。 解耦：将数据和 UI 逻辑

最近在开发新功能引入一个SDK时，遇到了这个问题。算得上是比较典型的客户端开发场景，因此在本文中整理记录。 问题描述 背景阐述 产品新需求里需要用到端侧 AI 能力，已有 AI-SDK.aar 提供相

业务场景 已知有一个 聚合支付 SDK —— 可以把它理解成，封装了支付宝、微信等支付渠道 SDK，提供统一的完成支付和结果通知接口。 当前业务上新增支付需求，需要把聚合支付 SDK 集成到当前的项目

从这篇文章开始，我将记录在实战中进行的架构优化/升级方面的经验。目前我所承接的是一个 维护了7年，包含10余个复杂模块 的庞大 APP，有无数祖传代码累积。而我现在要做的，就是要为这一辆行驶中的小汽车