时隔两年，LitePal终于又更新了！

大家早上好，看到这个标题，相信很多喜欢LitePal朋友应该是一把鼻涕一把泪。两年多了，今天终于又升级了

是的，我看了一下时间，LitePal的上个版本还是2018年10月份发布的，之后就再也没有更新过。因为我接下来将主要的时间都放在了giffun这个项目上，忙完giffun紧接着又开始编写《第三行代码》，以至于完全没有时间和精力去维护LitePal。

期间有不少朋友咨询过我，是不是放弃维护LitePal了？莫名感到有点心酸，我欠这个项目的有点多了。

那么时隔两年之后的更新，LitePal又发生了什么变化呢？我们一起来看一看吧。

/   Close Issues   /

这两年时间里，我不光没有时间更新LitePal的功能，甚至连GitHub上的issues都无暇顾及，以至于积累了大量的issues。那么在开发新功能之前，首先要做的，肯定是解决这些issues。

我将所有的issues都浏览一遍之后，发现大体可以归为以下几类：

1. 用法的咨询。对于这类issue我基本都进行了回复，只是回复的有点太晚了，可能没能帮上你们的忙，这里非常抱歉。

2. 功能上的建议。这些年来许多朋友都在LitePal的功能性方面提供了不少建议，也让LitePal变得更加强大。不过关于功能建议方面的事情我待会还会再谈，这里暂时先跳过。

3. 系统类型的Bug。有些朋友使用LitePal时遇到了崩溃，就认为是LitePal的bug，但有的时候并非如此。比如CursorWindows这个bug被提了好几次，但其实这是系统底层的限制，CursorWindow缓存数据达到最大限制就会抛出异常。即使你不使用LitePal，用原生的SQLiteDatabase也会出现这个异常，所以这种问题我确实无法修复，大家只能在使用层面尽量减少这种一次性加载大量数据的场景。

4. LitePal的Bug。对于提出这类问题的朋友我非常感谢，这次确实又发现了几个LitePal内部的bug。比如特定情况下升级数据库会丢失数据、Date类型字段无法保存1970年以前的数据、findFirst()方法在某些时候查询速度会非常慢等等。这次在开发新版本之前，我将这些提出的bug全部都进行了修复，保证这是一个更加稳定的版本。

那么现在LitePal的GitHub中还剩下多少issue呢？给大家看一下：

没错，就只剩下一个了。并且这是一个新功能的建议，我确实计划在之后的版本中考虑加入这个功能，所以暂时将它保留了下来。

好了，现在issues都解决掉了，接下来终于可以对LitePal进行升级了。

/   合二为一   /

在之前的LitePal 3.0.0版本当中，我为了让它支持一些Kotlin中不错的语法特性，将原来的一个库变成了两个库，如下图所示：

是的，使用哪种编程语言就引入哪个库，我本来认为这是一件很好的事情，然而没过多久我就后悔了，这是一个非常错误的决定。

将库分成了Java和Kotlin两个版本之后，它们又会共同引入Core库来作为依赖，Core库是主业务逻辑实现的地方。那么当需要添加什么新功能的时候，我需要在Core库中进行具体的功能实现，然后在Java库中添加一个对外接口，在Kotlin库中添加一个对外接口，还要为Kotlin的专属语法再添加一个对外接口。本来只需要在一个地方维护的代码现在变成了要在四个地方维护，所有API的数量也变成了四倍，导致代码维护成本急剧增加。

这个问题是我必须要解决的ÿ