Android ORM 个人小结

写在前面：
如果您是想了解Android流行ORM框架以及性能、api易用性等方面的话，那恐怕本篇文章让你失望了。本文是结合我个人开发环境而做出的比较，另外随着各个ORM新版本的迭代，本文的某些观点随着时间的流逝可能不再适用。
总之一句话：适合自己的才是最好的！鞋合不合脚只有自己去穿一穿最清楚。

由于之前的项目要不干脆不用本地数据库，要不就是操作Android原生的SQLite编写几条简单的原生SQL语句，但接下来的项目不用到ORM框架不行了，业务复杂，所以这段时间在选择ORM框架。零零散散的选择了2、3个了，谈谈感受吧。

先说下我的轨迹：Realm -> GreenDAO -> DBFlow

先笼统说下这三个ORM框架吧。如果你没有用过这三个ORM框架，下文的叙述可能对你来说有些云里雾里的，还是回归前面我说的那句话，这篇文章是个人小结，不是来长篇大论来对比这三个数据的。
有些坑，只有自己亲自踩过才会刻骨铭心啊！

一、Realm

Realm其实不是SQLite数据库，他是基于自身的数据库引擎开发的一款跨平台数据库，支持iOS和Android、MacOS等。性能很好，几乎秒杀其他ORM。但是呢，正是由于他是基于自己实现的数据库引擎，所以避免不了要引入.so文件，arm，x86, arm64，mips等几个平台都有，所以等你发布你的Apk的时候你会发现你的应用体积一下子就增加了不少。当然这不是最大的问题，我在开发中遇到的最大的问题是他对我的数据模型侵入很大，如果你的数据模型里用到了List，那么这个List必须改为他的RealmList。当然这个这也不是我最头疼的，这个我也能克服，最头疼的是他的跨线程查询传递数据。如果你放到后台线程查询本身是没有问题，但是你把数据扔给Adapter后，当Adapter开始从List数据里获取对象数据的时候肯定会报错，因为查询是在后台线程，查询结束时这个线程也就结束了，与RealmList有关的Realm对象也就没了。现在Adapter在主线程获取数据，需要Realm对象，但是这个对象随着后台线程一起没了，你访问就抛错了。。。讲白了他是懒加载，你数据模型里的List（RealmList）实际上在查询完成的时候并没有填充数据，当你的Adapter去一个个访问的时候他才开始真正的查询获取。你可能会讲，那我都扔到主线程里去增删改查就好咯，扔到主线程（UI线程）操作是没问题，但是和你如果要对这个List里的数据做处理呢，你如果还是在主线程高负荷操作可能会阻塞UI，不在主线程吧访问又抛错。。。。
还有个坑，在查询完获取数据后，你不能像SQLite那样去关闭数据库，一旦你关闭数据库了，那么同样你获取RealmList里的数据还是会报错（懒加载，获取到的数据并没有真正的填充）。还有一点，Realm支持监听数据变化，但是必须在有Looper的线程中运行。如果你的项目中用到了RxJava或RxAndroid，和这货结合起来使用绝逼烦死了，只要碰到他，你的RxJava操作几乎都必须切到mainThread,不然等你访问对象数据的时候就抛错给你看。总而言之，这货跨线程访问就是个坑！

二、GreenDAO

其实我是非常喜欢GreenDAO的，我当时用的是最新版的3.2.1,集成到项目也很简单，classpath 加上GreenDAO，模块apply plugin一下，dependency里加一下依赖就OK了。使用GreenDAO的开发者也非常多，有问题的话解决起来也很方便，社区很活跃。但是但是，我喜欢用lambda，用了retro-lambda,在项目里的很多地方都用了，也不打算继续用匿名内部类了（当然有的没办法的另当别论）。GreenDAO在生成代码的时候检测到lambda和方法引用时就报错，无可奈何去GreenDAO上找issue，发现早在16年7月份就有人提出来了，可是GreenDAO官方人员的答复却是准备4.0再支持。BTY,我真的很不理解一个生成数据库操作类代码的库为毛要检测用户业务逻辑代码里是不是有lambda，况且我的lambda表达式也不是写在数据库实体类中。。。
哎，可惜了，总而言之，我们后会有期吧。。。

三、DBFlow

这个也是比较流行的ORM框架，当然和GreenDAO相比还是逊色了一些，资料少一些，仅可供参考的资料就是GitHub上的demo和各个语法的说明文档。但是这个ORM都没有上面的这些问题，与RxJava结合的很好，数据库操作where语法同GreenDAO很相似，目前用的很好。

如果读者有什么意见或建议欢迎留言讨论

---

关注我的公众号.jpg