说一个小小的缺点

[nbwzlyd]

最近自己写的项目准备引入这个库来替换sp，但是遇到了两个问题
1个问题是Gson转换导致的，可参考issue
#16
第二个问题是，假设你一开始用
fastkv.putInt("testKey",1).
但是后面的业务你准备把testKey对应的value设置为String
fastKv.putString("test","1234")
这个时候就会直接报错了。虽然业务上大概率不会这么做，我是在测试时发现了这个问题

然而sp和mmkv是没有这个缺陷的。

主要是因为框架把key和container做了一层映射关系，这种关系是强绑定的，导致后面key的value不能做任何类型的变更，一旦出现这个问题，就会应用崩溃，只有卸载重装或者重新发包覆盖才可解决。

这两个问题从本质上来说，属于同一个问题

[BillyWei01]

1. #16 你也说了，不是库的问题，是Gson转换的问题；
2. 同一个key，前后版本换类型，无论是什么框架都是很危险的，
   比方说上一个版本你sp.edit().putString("test", "foo"), 这个版本你决定"test"应该用int类型，于是你编写了int a = sp.getInt("test"), 这个就会崩溃。
   再说mmkv, 上一个版本编写了putString("test", “foo"), 下一个版本，在没有调用过putInt("test", 1)之前，你先调用了
   int a = getInt("test"), 你会得到什么结果？

你说"虽然业务上大概率不会这么做"，事实上，就不应该这么做。

[nbwzlyd]

确实前后版本变更数据类型是很危险的操作。
主要的缺憾是fastkv在put阶段就直接崩溃了，后续无法通过get来纠正。比如我开始putInt，后面putString,再改成getString，sp mmkv均能正确解读。
总之，感谢大佬回复。

[BillyWei01]

sp和mmkv可以对同一个key连续putInt和putString而最终完成putString的原因我清楚，
FastKV要支持这个我也有办法，但是需要付出一定的代价，代价比收益要高，所以我不打算支持这个case。

[BillyWei01]

最近补了些代码。
支持对相同的key连续调用
fastkv.putInt("testKey",1);
fastKv.putString("testKey","1234");
(虽然不建议）