Administrator
Android数据持久化（五）：SP vs. DataStore vs. MMKV
一、 核心原理分析 1. SharedPreferences (SP) 存储格式： 基于 XML 文件，键值对存储。 I/O 模型： 全量读写。初始化时将整个 XML 加载进内存（Map 结构）；修改数据时，即使只改动一个字节，也会将整个 Map 序列化并覆盖写入文件。 线程模型： 读操作同步；写操
Android数据持久化（二）：SharedPreferences
SharedPreferences（简称 SP）是 Android 开发中最资深的轻量级存储方案。虽然在 2026 年我们有很多现代化的替代品（如 DataStore、MMKV），但理解 SP 的原理依然是每个 Android 开发者打好地基的必修课。 一、 核心定义 SP 是一种基于 Key-Va
Android 数据持久化（一）：存储方案概述
在 Android 开发中，持久化（Persistence）是指将数据保存到存储设备中，以确保应用退出或设备重启后数据依然存在。 根据数据的规模、结构化程度以及访问频率，主要有以下几种主流方案： 1. 键值对存储 (Key-Value Storage) 适用于保存应用设置、用户偏好或少量的简单状态。
Gradle：利用 [bundles] 消除冗余的依赖声明
在大型 Android 项目中，有些依赖库往往是“全家桶”出现的。比如： 网络请求：Retrofit + OkHttp + GSON 转换器 + 日志拦截器。 Jetpack Compose：Compose UI + Material 3 + Tooling + Activity Compose。
![Gradle：利用 [bundles] 消除冗余的依赖声明](/upload/dT9asdvH-8s81XIdaHVgUSiLs4C2Nn316O1iThnZN_8.webp?id=019c847e-50c1-71eb-ab60-636bcb1c2e51)
Gradle：告别 ext 与 buildscript：老项目平滑迁移到 libs.versions.toml 全记录
接手一个几年历史的老项目，打开 build.gradle，映入眼帘的往往是臃肿的 buildscript 块、散落各处的 ext { ... } 变量，以及各个子模块里相互打架的版本号。 如果你想让项目焕然一新，接入 Gradle 官方推荐的 Version Catalog (TOML) 是必经之路
Gradle：深入理解Version Catalog、libs.versions.toml、alias 与 apply false
升级一个 Gradle 插件或者库的版本，你需要在十几个 build.gradle 文件里疯狂搜索、替换，稍有不慎就会因为版本不一致导致编译失败。为了解决这个问题，Gradle 经历了从 ext 闭包管理到 buildSrc 的演进，最终在 Gradle 7.0+ 拿出了目前的终极方案：Versio
Gradle: Plugins 引入与 Classpath 引入：到底有啥区别？
在配置 Android 或 Java 项目时，你一定见过两种引入插件的方式：一种是在 plugins {} 块里写 id，另一种是在 buildscript {} 里写 classpath。 很多同学会觉得：“能跑就行，管它什么区别？”但当项目变大、构建变慢或者依赖冲突时，搞不清楚这两者的逻辑就会让
Android车载（一） Android Automotive OS
概述 AAOS 并没有大刀阔斧的改变 Android 原有的整体架构，几乎所有的核心服务 (AMS、WMS、PMS) 与手机并无区别，采用的是同一套源代码，所以我们可以将 AAOS 理解为 Android OS + Automotive Services + Automotive APPs ，即传统
