原文:http://www.csdn.net/article/2015-08-31/2825579
JSON——大家可能都知道它是几乎所有现代服务器都使用的轻量级数据交换格式。它体量轻,可读性强,通常比老式的、不友好的XML开发起来更加便捷友好。JSON是不依赖于开发语言的数据格式,但是在解析数据并将其转换到如Java对象时,会消耗我们的时间和存储资源。
几天前,Facebook宣布,其Android应用程序大幅提升了数据处理性能。这是由于几乎在全部应用程序中放弃了JSON数据格式,用FlatBuffers取而代之了。阅读这篇文章可以获得关于FlatBuffers的基础知识,学会如何从JSON转换到FlatBuffers。
虽然这东西是非常有前景的,但是乍一看其实现过程不是一下子就能明白的。而且Facebook也没有说得很详细。这就是为什么我要写这篇文章,在其中展示我们是如何使用Flatbuffers开展工作的。
总之,FlatBuffers是Google专门为游戏开发而创建的跨平台序列化库,就像Facebook所展示的那样,它在Android平台上遵循快速响应UI的16ms规则。
但是,在把所有数据迁移到FlatBuffers之前,你要确定确实需要这样做。因为,这样做有时对性能的影响是潜移默化的,而且数据安全性要比计算速度上几十毫秒的差异更重要。
什么使得Flatbuffers如此奏效?
由于是以二进制形式缓存,访问序列化数据时也无需数据解析过程。即使对于层次化数据也不需要解析。多亏不需要初始化解析器(初始化意味着要建立复杂的字段映射)和解析数据,这些都是需要花费时间的。
Flatbuffers数据不需要分配比自身使用缓冲区还要多的内存。我们不必像在JSON中那样为解析数据的整个层次分配额外对象。
要获得正宗的数据,就再读一读Facebook上关于FlatBuffers迁移问题的文章,还有Google自己的文档。
本文将介绍在Android应用程序中使用Flatbuffers的最简单方法:
JSON数据在应用程序之外的某个地方被转换成FlatBuffer格式的文件(例如,将二进制数据以文件的形式提交,还可以从API直接返回FlatBuffer二进制文件)。
在flatc (FlatBuffer编译器)的帮助下,手工生成数据模型(Java类)。
JSON文件存在一定的局限性(不能使用null字段,日期格式也被解析为字符串)。
将来,我们或许会提出更复杂的解决方案。
首先,我们需要flatc,即flatbuffers编译器。该编译器可以从Google所属的源代码构建,源代码位于Flatbuffers资源库中。我们下载并克隆它。整个构建过程在FlatBuffers构建文档中都做了描述。如果你是Mac用户的话,需要这样来构建:
在\{extract directory}\build\XcodeFlatBuffers.xcodeproj路径下,打开已下载的源代码。
点击Play按钮或⌘ + R,运行flatc scheme(默认情况下应该是被选中的)。
flatc可执行文件就会在项目的根目录下出现。
现在,我们可以使用schema编译器了,该编译器能够把给定的schema(在Java、C#、Python、GO和C++语言中的schema)生成为模型类,还可以把JSON转换成Flatbuffer的二进制文件。
接着,我们必须准备schema文件,该文件定义了要进行序列化和反序列化的数据结构。这个schema将用于flatc创建Java模型,把JSON转换成FlatBuffers的二进制文件。
这里是JSON文件的一部分。
完整版本在这里。这是略微修改后的版本,可以从Github API调用:https://api.github.com/users/google/repos 。
Flatbuffer schema是编写得很好的文档,所以就不深入探讨这个问题了。另外,本文中的schema不会很复杂。我们所要做的仅仅是创建3张表:ReposList, Repo和User,并定义root_type。这是schema的重要组成部分。
完整的schema文件在这里。
真棒,我们现在要做的是把repos_json.json转换成FlatBuffers二进制文件,生成能够以Java风格表示数据的Java模型(此处操作所需的全部文件都在我们的代码库中):
$ ./flatc -j -b repos_schema.fbs repos_json.json
如果一切顺利,会产生下列文件:
repos_json.bin(要将重命名它为 repos_flat.bin)
Repos/Repo.java
Repos/ReposList.java
Repos/User.java
现在来创建示例程序,在实践中来看看Flatbuffers格式是如何起作用的。这是截图:
在UI部分,ProgressBar仅用于显示不恰当的数据处理对用户界面顺畅度的影响。
应用文件看起来是这个样子:app/build.gradle
当然,在本例中不是必须要用Rx或ButterKnife这样的视图注入利器,但是为什么不让应用更细致一些呢??
我们把repos_flat.bin 和 repos_json.json文件放到res/raw/目录下。RawDataReader是工具类,它帮助我们读取Android应用中的原始文件。
最后,把Repo,ReposList和User这三张表对应的模型类代码放到项目源代码中。
使用Java语言编程过程中,FlatBuffers提供了可以直接处理这种数据格式的库,也这是flatbuffers-java-1.2.0-SNAPSHOT.jar文件。如果你想手工生成该文件,需要下载FlatBuffers源代码,再到目录java/下,用Maven生成该库:
$ mvn install
现在将.jar文件放到Android项目的app/libs/目录下。
好了,当务之急是实现MainActivity类,这是完整源代码。
我们最为关注的两个方法是:
parseReposListJson(String reposStr) - 这个方法初始化Gson解析器,并把JSON字符串转换成Java对象。
loadFlatBuffer(byte[] bytes) - 这个方法将字节(repos_flat.bin文件)转换成Java对象。
现在让我们把JSON和FlatBuffers在加载时间和资源消耗方面的差异形象化。测试是在带有Android M(beta版)的Nexus 5上进行的。
测量的过程是将其他文件转换为Java源文件,对所有(90个)元素进行迭代。
使用JSON:JSON文件(大小:478kB)平均加载时间200ms(时间区间:180ms~250ms);
使用FlatBuffers:FlatBuffers二进制文件(大小:352kB)平均加载时间5ms(时间区间:3ms~10ms)。
记得16ms规则吗?我们在UI线程中调用这些方法的原因就是要看看在这种情况下界面表现如何:
看出区别了吗?JSON数据的加载过程中, ProgressBar停顿了一会,界面不是那么顺畅(加载时间超过了16ms)。
还有什么想要测量的吗?也许应该测量一下Android Studio 1.3,还有那些新特性。例如,内存分配跟踪器(Allocation Tracker),内存状态查看器(Memory Viewer)和方法跟踪器(Method Tracer)。
这里所讲解项目的完整源代码都在Github代码库中。你不需要接触整个FlatBuffers项目,所需的内容全都在flatbuffers/目录下。