如何在 Android 上高效存储位集
我的应用程序要求我在 Android 平台上存储位集以及一些附带的元数据（目前只读）。现在显然我可以实现 Serialized 接口，但我听说它在 Android 上非常慢（我可以想象必须对自定义 VM 和编译器做一些事情，从而使此类反射功能效率低下）。 我应该：
- 使用 Android 的 Parcel 系统，这似乎是一种“辅助”编组技术。
- 使用自定义二进制格式（可能是去除了标头信息的 BMP 样式）。
- 手动存储到 XML 文件中，使用 XML 解析器检索数据。
现在，据我了解，XML 序列化或打包在 Android 上并不是真正向后兼容？ XML 的吸引力当然在于这些持久文件可以在常规文本编辑器中进行编辑。这让我陷入了困境，因为我讨厌编写冗余的代码。
在这一点上，我非常倾向于第一个选项（即位集被分割）。有经验丰富的 Java/Android 程序员愿意告诉我，我可以期望它的执行效果如何吗？我是否必须将位集扩展为布尔数组才能获得可接受的运行时性能？当然，这样做的问题是，即使是基本的基准测试也必须在 Dalvik VM 上运行，因为我不能指望 Sun 在 x86 上的 VM 具有与 ARM 上的 Android 类似的性能。 Android模拟器是如何工作的？它是 x86 主机之上的虚拟机，还是模拟 ARM 指令集并运行针对 ARM 的虚拟机？
我希望这篇ADD帖子不会让大家感到困惑，因为它让我感到困惑。 ：D
My application requires me to store sets of bits along with some accompanying metadata on the Android platform (read only for now). Now obviously I could just implement the Serializable interface, but I hear it's very slow on Android (I can imagine has to do something with the custom VM and compiler that makes such reflective features inefficient).
Should I:
- Use Android's Parcel system which seems to be an "assisted" marshalling technique.
- Use a custom binary format (maybe BMP style with the header information stripped).
- Store into an XML file manually, use XML parser to retrieve data.
Now from what I understand XML serialization or parcelization isn't really backwards compatible on Android? The appeal of XML is of course that these persistent files could be edited in a regular text editor. Which leaves me in a difficult position, since I hate writing code that is redundant.
At this point I am heavily leaning towards the first option (i.e. bitset being parcelized). Any experienced Java/Android programmers care to tell me how well I can expect this to perform? Would I have to expand the bitset into an array of booleans to get acceptable runtime performance? Of course the problem with this is that even a rudimentary benchmark would have to be run on the Dalvik VM since I can't expect Sun's VM on x86 have similar performance to Android on ARM. How does the Android emulator work? Is it a VM on top of the x86 host or does it emulate the ARM instruction set and run the VM targeted at ARM?
I hope this ADD post didn't confuse everyone because it confused me. :D
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您听说过序列化速度很慢的传言，因此您打算使用 XML？哈哈。
您需要为自己编写一些现实的基准，序列化您实际需要处理的位集类型（大与小，密集与稀疏，等等）。我强烈推荐 http://code.google.com/p/caliper/ 进行写作您的基准。 http://code.google.com/p/vogar/ 知道如何运行Android 设备上的卡尺基准测试。
正如我在性能设计中所说，模拟器行为就性能而言，与设备行为完全不同。您需要在您真正关心的性能最低的设备上进行测试。
you heard a rumor that serialization is slow, so you're going to use XML? lol.
you need to write yourself some realistic benchmarks, serializing the kinds of bitsets you actually need to deal with (large versus small, dense versus sparse, and so on). i strongly recommend http://code.google.com/p/caliper/ for writing your benchmarks. http://code.google.com/p/vogar/ knows how to run a caliper benchmark on an Android device.
as i say in Designing for Performance, emulator behavior is nothing like device behavior when it comes to performance. you need to test on the lowest-performance device you actually care about.
我认为第三个选项是最好的，因为在 BitSet 中，尽管在某些情况下它消耗的内存较少，但如果您以二进制模式存储，它可能会浪费空间，一个例子是：
在这种情况下，您只有一个设置位，但它只会当您以位图或序列化格式存储在文件中时，会浪费所有未设置位的空间。Anroid 的包裹系统我不知道它是如何工作的，所以我无法评论它。
如果您确定这些位不会是大数字，那么请选择二进制模式，否则请选择 XML 模式或仅存储 b.toString() 的文本，并在需要时从文件中解析它。
I think the 3rd option would be the best since in BitSet even though its less memory consuming in some cases it can simply waste space if you store in binary mode,an example is:
In this case you have only one set bit but it will simply waste space for all the unset bit's when you store in file either as bitmap or in serialized format.Anroid's parcel system I'm not aware about how it works so i can't comment on it.
If you are sure the bits won't be big numbers then go for the the binary mode else go for the XML mode or simply text where you store b.toString() and parse it from file when required.