SQLite之问

Posted 2021-04-30 张翔宇写字的地方

• 项目的五味杂陈

想这个问题，是最近公司项目遇到的。虽然之前我都在科普Linux的相关内容，但是这个话题真的不吐不快。因为什么呢？因为我自己搭建的SQLite数据库被人家说砍就砍，整套项目几乎就只有清洁溜溜的android Media播放器留着了... ...

之前学生时代，一直想的就是，创业，创业，创业。总觉得一款软件搭料越多，软件技术性含量越高，越容易卖钱，也越容易拉到创投资金。现今，实际项目一次次打击打得我面目全非。当我想到做Android app用户管理时，想到的第一点就是本地SQLite数据库，云端数据库（可以是关系型，也可以是非关系型如LeanCloud这种）做协同。一次次经历背后，我在思考这个问题，SQLite到底价值几何？

• 什么是SQLite

SQLite是一个进程内的库，实现了自给自足的、无服务器的、零配置的、事务性的 SQL 数据库引擎。由于SQLite是一种轻量级的数据，所以吞吐量是远远不及其他服务器级数据库，SQLite也就适用于微端/终端的数据存储。

除了轻量级，SQLite还有什么优点呢？

1. 一个完整的 SQLite 数据库是存储在一个单一的跨平台的磁盘文件。完全配置时小于 400KB，省略可选功能配置时小于250KB。

2. SQLite 是自给自足的，这意味着不需要任何外部的依赖。

3. SQLite 事务是完全兼容 ACID 的（ACID，即数据库的四大特性，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）），允许从多个进程或线程安全访问。

4. SQLite 支持 SQL92（SQL2）标准的大多数查询语言的功能。

5. SQLite 使用 ANSI-C 编写的，并提供了简单和易于使用的 API。

6. SQLite 可在 UNIX（Linux, Mac OS-X, Android, ios）和 Windows（Win32, WinCE, WinRT）中运行。

可以明显地看到，多平台，文件关联型，上层SQL语言编写是它刨去轻量级以外最大的三个亮点。

• SQLite的何去何从

Okay，这么多新特性真的让我跃跃欲试。就像写个Hello World我就想整个递归一样，很多事情也许真的是过度设计了。不信？看看下面这个开发需求：

开发一款人脸识别app：

1. 注册需要提供用户名，性别，满足用户脸部特征质量（Quality>0.7）的照片保存至本地。

2. 登录用本地照片，现场每帧比对；完成跳转主页，不通过则返回登录/注册选择页（SDK别人做好，你只用取出照片，按提供接口比对即可）。

3. 主页其他功能。

粗看，刨掉3，注册/登录，蹦到你脑海里的第一个东西绝对是数据库，而不是文件。为啥？因为你已经接触太多的思维惯性，觉得数据库才是用户管理的唯一途径。我和你一样，刚开始也是这么想的，于是我开始写一个SQLiteManager来调停这中间所有功能。

那用SQLite需要准备什么呢？Easy，无非是TABLE_NAME, COLUME_NAME，COLUME_NAME无非就是这几列：id，usrName, sex, picture路径名。而查询和存取SQLite你可以调用游标Cursor，这样既省事又省力。

有毛病吗？没毛病，我之前学校做过的项目，PM2.5，iLab直播项目都是这套逻辑。这似乎已经是行走江湖的必备套路。

可是，你有想过有必要吗？使用你手机的可能只有你自己，你会轻易把手机借给他人脸部识别用吗？所以你的SQLite记录其实只有一行（如果你女朋友喜欢翻你手机，那可能是两行，hhhhha~~）。再拿我曾经带本科生开发过的iLab直播项目，你会把直播聊天记录存在本地SQLite吗？那你app文件夹容量岂不爆炸？所有你看过直播间的浏览记录都可以保存在本地，想要推荐你看过最多的房间号是吗？需要去网上HttpPost从云端拿吗？那你真的是脱裤子放屁了。那怎么做？现今我想到那时候我的确好像也是过度设计（脱裤子放屁）。

将浏览app房间号存至本地文本文件，txt类型（不过一般都不是这类型，app出于隐私保护会加密成其他扩展名）。每个房间号记录时配备一个count，当你打开一个房间，count++写入本地文件。然后你试想，我去云端数据库拿浏览房间记录次数，这性能开销，还要设置索引和查询算法加快速度。这开销不被打死算你牛逼。

• 理清思路，重新出发

回到上一节的开发需求：

1. 注册需要提供用户名，性别，满足用户脸部特征质量（Quality>0.7）的照片保存至本地。

2. 登录用本地照片，现场每帧比对；完成跳转主页，不通过则返回登录/注册选择页（SDK别人做好，你只用取出照片，按提供接口比对即可）。

你可能说用SQLite已经是本地数据库了，已经比云端好很多了。可是SQLite仍然是一个进程内的库，说白了，就是你这个app一启动，是要连带启动SQLite Service这套服务的。这就意味着，你的app进程需要占用更多内存，一个东西杂糅太多服务，就是花瓶，性能开销远比你想象的要多（一个重量级服务远胜集成十个轻量级服务）。

那我怎么完成这个问题呢？简单，我注册时需要提供用户名，我将照片名和用户名保持一致（毕竟人脸登录又不是游戏账号，没必要多次注册）。这样，不用担心重名，保存文件时会校验路径下的文件是否存在；不用担心多次注册，因为即使人脸识别SDK效率低，多次注册你也不会选相同的用户名；那登录跳转主页，仍然是只用读取照片的文件名即可。也根本不用想用json数组，xml做资源绑定，那样也是一种浪费。

或许今天我才感觉，工作后的工程和学校里面的项目真的是完全不一样的。工程项目有的时候真的像倚天屠龙记，张三丰教张无忌太极剑法的那段对白：

张三丰一路剑法使完，竟无一人喝彩，各人竟皆诧异：“这等慢吞吞、软绵绵的剑法，如何能用来对敌过招？”转念又想：“料来张真人有意放慢了招数，好让他瞧得明白。”

只听张三丰问道：“孩儿，你看清楚了没有？”张无忌道：“看清楚了。”

张三丰道：“都记得了没有？”张无忌道：“已忘记了一小半。”张三丰道：“好，那也难为了你。你自己去想想罢。”张无忌低头默想。过了一会，张三丰问道：“现下怎样了？”张无忌道：“已忘记了一大半。”

张无忌在殿上缓缓踱了一个圈子，沉思半晌，又缓缓踱了半个圈子，抬起头来，满脸喜色，叫道：“这我可全忘了，忘得乾乾净净的了。”张三丰道：“不坏，不坏！忘得真快，你这就请八臂神剑指教罢！”说着将手中木剑递了给他。

大道至简，知易行难。

带着对Linux && Android的热爱执笔。

”您的赞赏，是我写作的信心和勇气“