Android在Kotlin中更好地使用LitePal

Kotlin 是一个用于现代多平台应用的静态编程语言，由 JetBrains 开发。

Kotlin可以编译成Java字节码，也可以编译成JavaScript，方便在没有JVM的设备上运行。

Kotlin已正式成为Android官方支持开发语言。

自从LitePal在2.0.0版本中全面支持了Kotlin之后，我也一直在思考如何让LitePal更好地融入和适配Kotlin语言，而不仅仅停留在简单的支持层面。

Kotlin确实是一门非常出色的语言，里面有许多优秀的特性是在Java中无法实现的。因此，在LitePal全面支持了Kotlin之后，我觉得如果我还视这些优秀特性而不见的话，就有些太暴殄天物了。所以在最新的LitePal 3.0.0版本里面，我准备让LitePal更加充分地利用Kotlin的一些语言特性，从而让我们的开发更加轻松。

本篇文章除了介绍LitePal 3.0.0版本的升级内容之外，还会讲解一些Kotlin方面的高级知识。

升级到3.0.0

首先还是来看如何升级。

为什么这次的版本号跨度如此之大，直接从2.0升到了3.0呢？因为这次LitePal在结构上面有了一个质的变化。

为了更好地兼容Kotlin语言，LitePal现在不再只是一个库了，而是变成了两个库，根据你使用的语言不同，需要引入的库也不同。如果你使用的是Java，那么就在build.gradle中引入如下配置：

dependencies {
  implementation 'org.litepal.android:java:3.0.0'
}

而如果你使用的是Kotlin，那么就在build.gradle中引入如下配置：

dependencies {
  implementation 'org.litepal.android:kotlin:3.0.0'
}

好了，接下来我们就一起看一看LitePal 3.0.0版本到底变更了哪些东西。

泛型的优化

不得不说，其实LitePal的泛型设计一直都不是很友好，尤其在异步查询的时候格外难受，比如我们看下如下代码：

在异步查询的onFinish()回调中，我们直接得到的并不是查询的对象，而是一个泛型T对象，还需要再经过一次强制转型才能得到真正想要查询的对象。

如果你觉得这还不算难受的话，那么再来看看下面这个例子：

可以看到，这次查询返回的是一个List<T>，我们必须要对整个List进行强制转型。不仅要多写一行代码，关键是开发工具还会给出一个很丑的警告。

这样的设计无论如何都算不上友好。

这里非常感谢 xiazunyang 这位朋友在GitHub上提出的这个Issue(https://github.com/LitePalFramework/LitePal/issues/396)，并且给出了建议的优化方案，LitePal 3.0.0版本在泛型方面的优化很大程度上是基于他的建议。

那么我们现在来看看，到了LitePal 3.0.0版本，同样的功能可以怎么写：

可以看到，这里在FindCallback接口上声明了泛型类型为Song，那么在onFinish()方法回调中的参数就可以直接指定为Song类型了，从而避免了一次强制类型转换。

那么同样地，在查询多条数据的时候就可以这样写：

LitePal.where("duration > ?", "100").findAsync(Song.class).listen(new FindMultiCallback<Song>() {
  @Override
  public void onFinish(List<Song> list) {
  }
});

这次就清爽多了吧，在onFinish()回调方法中，我们直接拿到的就是一个List<Song>集合，而不会再出现那个丑丑的警告了。

而如果这段代码使用Kotlin来编写的话，将会更加的精简：

LitePal.where("duration > ?", "100").findAsync(Song::class.java).listen { list ->}

得益于Kotlin出色的lambda机制，我们的代码可以得到进一步精简。在上述代码中，行尾的list参数就是查询出来的List<Song>集合了。

那么关于泛型优化的讲解就到这里，下面我们来看另一个主题，监听数据库的创建和升级。

监听数据库的创建和升级

没错，LitePal 3.0.0版本新增了监听数据库的创建和升级功能。

加入这个功能是因为 JakeHao 这位朋友在GitHub上提了一个Issue(https://github.com/LitePalFramework/LitePal/issues/414)，在他说明了应用场景之后，我认为监听数据库创建和升级这个功能还是非常有意义的。

要实现这个功能肯定要添加新的接口了，而我对于添加新接口保持着一种比较谨慎的态度，因为要考虑到接口的易用性和对整体框架的影响。

LitePal的每一个接口我都要尽量将它设计得简单好用，因此大家应该也可以猜到了，监听数据库创建和升级这个功能会非常容易，只需要简单几行代码就可以了实现了：

需要注意的是，registerDatabaseListener()方法一定要确保在任何其他数据库操作之前调用，然后当数据库创建的时候，onCreate()方法就会得到回调，当数据库升级的时候onUpgrade()方法就会得到回调，并且告诉通过参数告诉你之前的老版本号，以及升级之后的新版本号。

Kotlin版的代码也是类似的，但是由于这个接口有两个回调方法，因此用不了Kotlin的单抽象方法(SAM)这种语法糖，只能使用实现接口的匿名对象这种写法：

这样我们就将监听数据库创建和升级这部分内容也快速介绍完了，接下来即将进入到本篇文章的重头戏内容。

一次不可思议的升级

从上述文章中我们都可以看出，Kotlin版的代码普遍都是比Java代码要更简约的，Google给出的官方统计是，使用Kotlin开发可以减少大约25%以上的代码。

但是处处讲究简约的Kotlin，却在有一处用法上让我着实很难受。比如使用Java查询song表中id为1的这条记录是这样写的：

Song song = LitePal.find(Song.class, 1);

而同样的功能在Kotlin中却需要这样写：

val song = LitePal.find(Song::class.java, 1)

由于LitePal必须知道要查询哪个表当中的数据，因此一定要传递一个Class参数给LitePal才行。在Java中我们只需要传入Song.class即可，但是在Kotlin中的写法却变成了Song::class.java，反而比Java代码更长了，有没有觉得很难受？

当然，很多人写着写着也就习惯了，这并不是什么大问题。但是随着我深入学习Kotlin之后，我发现Kotlin提供了一个相当强大的机制可以优化这个问题，这个机制叫作泛型实化。接下来我会对泛型实化的概念和用法做个详细的讲解。

要理解泛型实化，首先你需要知道泛型擦除的概念。

不管是Java还是Kotlin，只要是基于JVM的语言，泛型基本都是通过类型擦除来实现的。也就是说泛型对于类型的约束只在编译时期存在，运行时期是无法直接对泛型的类型进行检查的。例如，我们创建一个List<String>集合，虽然在编译时期只能向集合中添加字符串类型的元素，但是在运行时期JVM却并不能知道它本来只打算包含哪种类型的元素，只能识别出来它是个List。

Java的泛型擦除机制，使得我们不可能使用if (a instanceof T)，或者是T.class这样的语法。

而Kotlin也是基于JVM的语言，因此Kotlin的泛型在运行时也是会被擦除的。但是Kotlin中提供了一个内联函数的概念，内联函数中的代码会在编译的时候自动被替换到调用它的地方，这就使得原有方法调用时的形参声明和实参传递，在编译之后直接变成了同一个方法内的变量调用。这样的话也就不存在什么泛型擦除的问题了，因为Kotlin在编译之后会直接使用实参替代内联方法中泛型部分的代码。

简单点来说，就是Kotlin是允许将内联方法中的泛型进行实化的。

那么具体该怎么写才能将泛型实化呢？首先，该方法必须是内联方法才行，也就是要用inline关键字来修饰该方法。其次，在声明泛型的地方还必须加上reified关键字来表示该泛型要进行实化。示例代码如下所示：

inline fun <reified T> instanceOf(value: Any) {}

上述方法中的泛型T就是一个被实化的泛型，因为它满足了内联函数和reified关键字这两个前提条件。那么借助泛型实化，我们到底可以实现什么样的效果呢？从方法名上就可以看出来了，这里我们借助泛型来实现一个instanceOf的效果，代码如下所示：

inline fun <reified T> instanceOf(value: Any) = value is T

虽然只有一行代码，但是这里实现了一个Java中完全不可能实现的功能 —— 判断参数的类型是不是属于泛型的类型。这就是泛型实化不可思议的地方。

那么我们如何使用这个方法呢？在Kotlin中可以这么写：

val result1 = instanceOf<String>("hello")
val result2 = instanceOf<String>(123)
// result1为true，result2为false

可以看到，第一行代码指定的泛型是String，参数是字符串"hello"，因此最后的结果是true。而第二行代码指定泛型是String，参数却是数字123，因此最后的结果是false。

除了可以做类型判断之外，我们还可以直接获取到泛型的Class类型。看一下下面的代码：

inline fun <reified T> genericClass() = T::class.java

这段代码就更加不可思议了，genericClass()方法直接返回了当前指定泛型的class类型。T.class这样的语法在Java中是不可能的，而在Kotlin中借助泛型实化功能就可以使用T::class.java这样的语法了。

然后我们就可以这样调用：

val result1 = genericClass<String>()
val result2 = genericClass<Int>()
// result1为java.lang.String，result2为java.lang.Integer

可以看到，我们如果指定了泛型String，那么最终就可以得到java.lang.String的Class，如果指定了泛型Int，最终就可以得到java.lang.Integer的Class。

关于Kotlin泛型实化这部分的讲解就到这里，现在我们重新回到LitePal上面。讲了这么多泛型实化方面的内容，那么LitePal到底如何才能利用这个特性进行优化呢？

回顾一下，刚才我们查询song表中id为1的这条记录是这样写的:

val song = LitePal.find(Song::class.java, 1)

这里需要传入Song::class.java是因为要告知LitePal去查询song这张表中的数据。而通过刚才泛型实化部分的讲解，我们知道Kotlin中是可以使用T::class.java这样的语法的，因此我在LitePal 3.0.0中扩展了这部分特性，允许通过指定泛型来声明查询哪张表中的内容。于是代码就可以优化成这个样子了：

val song = LitePal.find<Song>(1)

怎么样，有没有觉得代码瞬间清爽了很多？看起来比Java版的查询还要更加简约。

另外得益于Kotlin出色的类型推导机制，我们还可以将代码改为如下写法：

val song: Song? = LitePal.find(1)

这两种写法效果是一模一样的，因为如果我在song变量的后面声明了Song?类型，那么find()方法就可以自动推导出泛型类型，从而不需要再手动进行<Song>的泛型指定了。

除了find()方法之外，我还对LitePal中几乎全部的公有API都进行了优化，只要是原来需要传递Class参数的接口，我都增加了一个通过指定泛型来替代Class参数的扩展方法。注意，这里我使用的是扩展方法，而不是修改了原有方法，这样的话两种写法你都可以使用，全凭自己的喜好，如果是直接修改原有方法，那么项目升级之后就可能会造成大面积报错了，这是谁都不想看到的。

那么这里我再向大家演示另外几种CRUD操作优化之后的用法吧，比如我想使用where条件查询的时候就可以这样写：

val list = LitePal.where("duration > ?", "100").find<Song>()

这里在最后的find()方法中指定了泛型<Song>，得到的结果会是一个List<Song>集合。

想要删除song表中id为1的这条数据可以这么写：

LitePal.delete<Song>(1)

想要统计song表中的记录数量可以这么写：

val count = LitePal.count<Song>()

其他一些方法的优化也都是类似的，相信大家完全可以举一反三，就不再一一演示了。

这样我们就将LitePal新版本中的主要功能都介绍完了。当然，除了这些新功能之外，我还修复了一些已知的bug，提升了整体框架的稳定性，如果这些正是你所需要的话，那就赶快升级吧。

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对我们的支持。如果你想了解更多相关内容请查看下面相关链接