三种DBus传输数据的方式的比较

列出基于DBus的三种传输数据所使用的时间数据，依赖于具体平台，仅供参考。

测试数据是传输一个U盘目录下的32766个文件的全路径与文件名，数据总大小在1.5MB以下。

1. 直接函数调用

这个基于DBus应用的最直接实现，一次函数调用，返回分别为全路径与文件名的2个字符串，数据量不超过40字节，整体性能受限于单次DBus函数的执行时间。在我的测试平台上，单次DBus的函数调用在4ms以上（还是Peer to Peer）的，因此，所有数据传输完成的时间是130多秒。。。，性能完全不能满足要求；

2. 基于GVariant的DBus数据直接传递

GDBus支持在Bus上直接传递结构体数组。定义DBus接口时，声明参数是"a(ss)"类型，即由俩个字符串构成的结构体的数组，而实际在Bus上传递的是一个GVariant对象。这种方式在DBus上传输时会遇到数据封包的限制：DBus上最大的数据包为32KB，因此一个GVariant对象可能会被拆成多个DBus数据包，因此导致额外的负载。在我的测试平台上，GVariant化后的总数据大小在2MB多，总的封装GVariant+解封装GVariant+DBus数据传输的时间是11s左右，比直接函数调用降了一个数量级；

3. 基于Share Memory的数据传递

由于GVariant对象的数据可以很容易的序列化，因此可以使用在DBus接口中封装共享内存的方式，省去在DBus上传输、拷贝数据的时间。测试后的时间花费在5.5秒左右，主要消耗在数据的打包与解包上，对于一个通用的序列化算法来说，似乎没有再优化的空间了。