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，提升了整体框架的稳定性，如果这些正是你所需要的话，那就赶快升级吧。

总结

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