本地持久化存储的方式

这是一个海外app开发的一个很重要的内容。因为国外的法律针对互联网产品的角度普遍来讲比国内的法律严格很多，有很多数据是不可以放在服务器的数据库上面存储的，这个时候本地如何去存储这部分的内容就很重要了。

国内的一些app开发也是需要使用到本地持久化存储的，比如做一个缓存层存着上一次拿到的数据，当下一次的网络请求出现异常的时候，可以把当前本地数据库的信息拿出来凑凑数给到用户看到先（如果是那种不太会修改到的数据信息，是可以这么做的，这种问题得具体去和产品经理聊了，从技术的层面都是可以实现的，只是从产品合理性的角度，得交给产品经理去判断了）。

文件存储方式

• 这种方式很便捷，其实是按照一个数据库的方式建立好所有的ER关系之后，如同数据库那样把Entity对象反序列化成为字符串或者相对应文件的格式存入txt、json或者csv中，每次读的时候，获取出数据之后再序列化成为相应的Entity，按照MVVM的流程作为Service的数据源。
• 但是：
  • 自己团队封装的代码可不可靠？( 我的建议是：尽可能靠TDD的模式去开发这一块的业务吧，如果是手动在开发阶段多测几遍，我认为远没有在开发开始之前把所有可能以TDD的形式写好再去开发来得靠谱)
  • 文件升级时候会不会出现Throwable？出现了会怎么样呢，是Crash还是怎么样？（我的解决方式是：都放在RxJava中作为onError的状态流或者Kotlin Coroutines开发过程中用try-catch模式捕获异常状态）
  • 重复代码会出现多少呢？（封装的重要性）
  • 如果是重大业务开发，不要使用这种模式去存储，因为产品那边可能会针对这一块的业务调整，之后就涉及ER关系的变化，这种存储模式在实现表升级的时候，自己写的操作总归没有官方数据库（SQLite）或者框架（Room）之类的那么靠谱。

关系型数据库存储方式

• Android中，能够使用的关系型数据库只有SQLite，这个也是Android团队唯一提供的，也是最合适于Android这种客户端机器去运行的数据库。
• 在这个基础上，衍生出来的就有多种操作SQLite数据库的方式，最直接的就是使用Android提供的SQLiteHelper去操作数据库，但是这种方式太多重复代码了。
• 于是，一大堆第三方操作SQLite数据库的框架如同雨后春笋般出现，比如GreenDao、LitePal等等。但是这些第三方SQLite操作框架都有一个问题，就是它的维护，得看相应的开发者。很多框架在出来的一两年便不再维护，而且当Google官方推一些新的功能的时候，这些框架并不能第一时间适配这些新功能。比如LitePal，对RxJava和Kotlin Coroutines均不支持。
• 为了解决这个问题，Google官方推出了JetPack Room数据库操作框架，这是一个很强大的数据库操作框架，它可以支持我们常用的两大线程调度框架，RxJava和Kotlin Coroutines。通过Database、Dao、Entity三个地方，实现了相应的对象关系映射（ORM），在MVVM中可以把这里理解为整一个Service层。

非关系型数据库存储方式

• 非关系型数据库存储方式 Realm 冷冻模型 Freeze
• 这个Realm，就是由大名鼎鼎的MongoDB团队，站在移动端的角度，推出的非关系型数据存储解决方案。
• 这个内容，与我们熟知的Jetpack Room、GreenDao这些都不尽相同，前面说的那些，都是基于SQLite数据库而推行的ORM工具，让我们作为开发者屏蔽实现更好地去编写一些数据接口。
• 而Realm则是一个完全摒弃了SQLite那种负责的关系结构的存储方案，和MongoDB相似，它是直接存储一段JSON就可以了。
• 这个事情，对于习惯了关系型数据库那种严谨结构的工程师，是难以接受的。就类同很多的Java SpringBoot工程师看待Node.JS这个事情一样。但实际上，Realm绝对是一个优秀的选型方案。

键值对存储方式

• SharedPreference
• MMKV
• Datastore

如果这一块的内容，硬要有什么类比的话，和后端开发的那个Redis很相似，就是用一个键值匹配的机制，去存储一些轻量化的内容。

SP是Android官方在Android SDK内置的方案，API直接调用就行了。所有的键值内容都是存储进去一个XML文件里面，没有什么考究的事情。唯一值得讲究的事情，就是SP的CRUD如果不去做任何线程调度的话，是不合理的，理论上任何IO操作都不能放在UI线程去处理，CRUD行为就是一个IO操作。但是也有很多团队很多开发者，因为懒也因为SP的CRUD实在是太快了，快到可以忽略他的IO阻塞UI时间，加上没有使用Kotlin Coroutines以及在RxJava上面也不愿意多去嵌套一层Single.create()予以调度线程，所以这个事情就看不同人之间的一些共识问题。

MMKV是Tencent Wechat那边的团队推出来的解决方案，说是比SharedPreferences多一些优点吧，我也不懂底层实现的东西，反正我不懂的，也暂时用不上的东西，就当你是绩效项目就行了。