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

一、前言

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

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

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

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

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

二、JSON 文件的本质

JSON 文件是什么？

复制代码

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

👉 所以：

❗JSON ≠ 存储方案

JSON 文件适合什么场景？

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

❌ 不适合

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

三、JSON 文件为什么会卡？

问题本质

复制代码

全量加载 + 全量解析

❌ 常见错误

java 复制代码

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️⃣ 流式解析（重点）

什么是流式解析？

复制代码

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

示例：

java 复制代码

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

而是：

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