Android 面试高频：JSON 文件、大数据存储与断电安全（从原理到工程实践）

一、前言

在实际开发和面试中，经常会遇到这样一类问题：

• JSON 文件数据很大，读取卡顿怎么办？
• JSON 能不能当存储方案？
• SQLite 能不能存 JSON？
• 大数据应该用 JSON / KV / SQLite？
• 写文件时断电，数据如何保证安全？

这些问题的本质不是 API，而是：

❗数据存储设计能力 + 工程可靠性能力

本文将从实际工程角度，系统讲清楚这些问题。

二、JSON 文件的本质

JSON 文件是什么？

JSON 是一种数据交换格式， 文件只是它的载体。

👉 所以：

❗JSON ≠ 存储方案

JSON 文件适合什么场景？

• 配置文件
• 初始化数据
• 导入导出
• 小规模数据缓存

❌ 不适合

• 大数据量
• 高频更新
• 复杂查询

三、JSON 文件为什么会卡？

问题本质

全量加载 + 全量解析

❌ 常见错误

String json = readAll(); // 一次读完 parse(json); // 一次解析

问题

• 内存占用高
• 解析慢
• UI 卡顿甚至 OOM

四、JSON 优化方案（核心）

1️⃣ 拆分大 JSON

一个大 JSON → 多个小 JSON

👉 降低单次处理成本

2️⃣ JSON Lines（重点）

什么是 JSON Lines？

每一行是一个 JSON 对象

示例：

{"id":1,"name":"A"} {"id":2,"name":"B"} {"id":3,"name":"C"}

3️⃣ 流式解析（重点）

什么是流式解析？

逐步读取 → 逐步处理 → 不全量加载

示例：

BufferedReader reader = new BufferedReader(new FileReader(file)); String line; while ((line = reader.readLine()) != null) { parse(line); }

本质

❗避免一次性加载全部数据

五、SQLite 能不能存 JSON？

结论

可以存，但不推荐存“大 JSON”

❌ 为什么不推荐？

• 需要整块解析
• 无法利用索引
• 无法局部更新
• 性能差

✅ 正确方式

JSON → 拆结构 → 表结构

六、KV 是什么？

❓KV 存储

Key-Value（键值对） 类似 HashMap，但可持久化

❓适用场景

• 配置
• 状态
• 小数据高频读写

❌ 不适合

• 大数据
• 复杂结构
• 查询需求

七、JSON / KV / SQLite 如何选型？

选型原则

JSON：小数据 + 低频 KV：简单数据 + 高频 SQLite：结构化数据 + 查询

❗关键判断

是否结构化 是否需要查询 是否需要局部更新

八、大 JSON 正确处理方案

❌ 错误方式

超大 JSON → SQLite TEXT

✅ 正确方案

1️⃣ 拆结构（推荐）

JSON → 表结构

2️⃣ 分片文件

data_1.json data_2.json

3️⃣ JSON Lines + 流式处理

九、断电数据安全（面试重点）

问题

写文件过程中断电怎么办？

❌ 错误方式

直接覆盖原文件

👉 风险：

• 文件损坏
• 数据丢失

✅ 正确方案（核心）

1. 写入临时文件 2. fsync 确保落盘 3. rename 原子替换

核心原理

❗rename = 原子替换文件

保证

要么旧数据在 要么新数据完整 不会损坏

十、面试高分总结

🎯 三大核心

性能：避免全量加载 安全：避免直接覆盖 架构：选择合适存储方案

🔥 一句话总结

❗JSON 决定数据格式，KV/SQLite 决定存储能力，架构决定是否合理。

十一、结语

这类问题的本质不是：

❌ 会不会用 JSON / SQLite

而是：

✅是否具备数据建模 + 工程设计能力