新安人才网,霍青桐别传,天筑网
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，提升了整体框架的稳定性，如果这些正是你所需要的话，那就赶快升级吧。
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对移动技术网的支持。如果你想了解更多相关内容请查看下面相关链接
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复
Android studio开发小型对话机器人app(实例代码)
Android通过Java sdk的方式接入OpenCv的方法
Android 通过cmake的方式接入opencv的方法步骤
Android Studio finish()方法的使用与解决app点击“返回”(直接退出)
Android 进度条 ProgressBar的实现代码(隐藏、出现、加载进度)
网友评论