Closed LeoYu007 closed 1 year ago
读写数据库会卡主线程, 且过于麻烦, 数据表不是对象结构体
本框架主要是为了打通本地序列化和内存对象的编程隔阂, 让读取本地配置像读取变量一样简单. Serialize本身不是让你存储大量数据内容, 而是一种配置对象
设计思路
文档中开头我就有提到对于关系型/列表数据/大体积数据还是推荐使用数据库完成, 但我认为对象或者说配置我认为也需要使用mmkv存储
没有抽离接口是因为早期设计目的过于简单, 早期没有"配置对象"思想, 仅仅是为了尝试使用委托属性简化.
但是目前而言我认为这种接口改造没有任何意义, 你是想用其他什么框架来实现?
读写文件会卡主线程, 并且管理过于复杂
关于抽象接口这个问题曾经Net经常被讨论. 认为应该不能依赖于OkHttp的Api, 应该像其他框架一样提供自己特有的Api, 底层实现交由用户去实现
但是在Android上谁能替代OkHttp? OkHttp已经是一个生态而不是简单的框架. 新增一堆函数去让用户去学习吗? 如果没有考虑到的功能别人怎么实现, 发生的异常问题该搜索什么来解决?
什么都想着抽象会害了你的
接口就意味着复杂绕的逻辑(为了实现接口而写接口), 带来的劣势不言而喻, 严重违背了项目初衷
有些开源项目我维护超过5年, 我认为框架迭代过程中很多时候并不需要什么底层全部更换或者说即使更换底层也很难保持完全不更改上层Api
其实大部分情况下的Serialize用法完全支持直接替换底层(前提你不使用参数kv:MMKV
), 个别的自己Replace一下好了
首先这是个很棒的库,我们项目也使用kotlin委托实现了读写变量自动保存本地的功能,但是没有提供可观察的LiveData,楼主提供了很好的思路。但是有个小问题和楼主交流一下:
SharedPreferences/MMKV/DataStore设计本意就是存储轻量级的key-value数据,直接提供hook来序列化复杂数据是否违背了初衷呢?个人认为,对于重要的结构化数据,数据库是首选,轻量级数据使用SP/MMKV,但对于一些不需要数据库建表那么重,又不适合直接存SP的数据,做本地文件缓存是比较合适的。
所以,是否可以再抽象一下,