.webp){kind=small}
LTT
Android JobIntentService：一个曾经用来兼容后台任务的过渡方案
在 Android 后台任务体系里，JobIntentService 是一个很有时代感的类。 它出现的背景是：以前我们经常用 IntentService 来处理后台任务，比如上传日志、同步数据、处理广播后的耗时操作。但从 Android 8.0 开始，系统加强了后台执行限制，普通后台 Service
Android AlarmManager 系统级定时触发机制
一、AlarmManager 是什么？ AlarmManager 是 Android 提供的一个系统服务，主要用于在未来某个时间点触发任务。 它不是普通的定时器，而是由系统统一管理的时间调度机制。App 设置一个闹钟任务后，即使 App 进程暂时不在前台，系统也可以在合适的时间触发对应操作。 常见使
Android JobScheduler解析
一、JobScheduler 是什么 JobScheduler 是 Android 5.0，也就是 API 21 引入的系统任务调度机制。 它的作用不是让任务立即执行，而是让 App 把后台任务交给系统，由系统根据当前设备状态选择合适的时机执行，比如网络状态、电量状态、是否充电、是否空闲等。 官方文
Hybrid 开发方案
下面是一篇可以直接作为技术方案初稿的 Hybrid 开发方案。 Hybrid 开发方案 一、方案背景 在移动端开发中，纯 Native 开发体验好、性能强，但开发成本高、发版周期长；纯 H5 开发迭代快、跨平台能力强，但性能、系统能力和用户体验相对弱。 Hybrid 开发是一种折中方案： 将核心体验
Android IntentService 原理、实践与废弃
1. 概述 IntentService 是 Android 提供的一个抽象类，继承自 Service。它被设计用来按需处理异步请求（以 Intent 为载体）。它本质上是一个集成了“工作线程”和“消息队列”的后台服务，非常适合执行那些不需要与 UI 交互、且执行时间较短的耗时任务（如下载文件、写入日
接口幂等性：重复提交与重复下单的防坑指南
在分布式系统中，重复提交和重复下单的因果关系及防御策略要点如下：重复提交源于用户行为、网络重试等原因，导致重复下单。幂等性需分层防御——前端防抖减少冗余请求；Token机制（如Redis存储唯一Token）确保请求一致性；业务层用分布式锁（分片设计）或唯一标识（如用户ID+商品ID）管控并发；数据库唯一索引作为兜底防线，冲突时返回已有订单而非失败。常见陷阱包括：单方案失效（某电商因索引冲突导致锁竞争瘫痪）、业务状态未校验引发扣款、锁过期设置不合理造成并发问题，需采用2-3倍耗时设置或自动续期机制。分层防御体系（防重→Token→锁→唯一索引/消息去重）可降低重复率至0.002%，年省损失千万级。核心结论：幂等性需多层级组合方案，避免依赖单一机制，特别是高并发场景需同时使用Token和业务锁。数据库唯一索引可作为最终兜底，但更新操作需结合状态机校验当前状态。
工作流引擎
📊 主流工作流引擎选型对比表 下表以BPMN（国际标准的流程建模语言）派系为主，并延伸到更广阔的场景。 引擎 类型/架构 核心特点 优势 劣势 典型适用场景 学习成本 性能与部署 Flowable BPMN引擎 (Java) 从Ac
SSO单点登录实现方案
1. 什么是 SSO SSO，全称是 Single Sign-On，中文叫 单点登录。 它解决的问题是： 用户只需要登录一次，就可以访问多个相互信任的系统。 比如公司内部有这些系统： OA 系统 CRM 系统 财务系统 工单系统 数据看板系统 如果没有 SSO，用户访问每个系统都要登录一次，体验很差
