内存高效且快速的 iPhone/Android 词典存储/访问
我在老一代 iPhone（ipod touch 第一代、第二代等）上遇到了内存问题。这是由于我加载和存储 170k 单词词典时分配的内存量所致。
这是代码（非常简单）：
string[] words = dictionaryRef.text.Split("\n"[0]);
_words = new List<string>(words);
这在启动时分配了大约 12mb 的存储空间，我认为 iphone 有大约 43mb 的存储空间。所以+纹理+声音+它往往会破坏操作系统。
就速度而言，使用二分搜索访问就可以了。但它更有效地将其存储在内存中（并且更有效地加载）。
text.Split 似乎占用了大量堆内存。
有什么建议吗？
Im having trouble with memory on older generation iPhones (ipod touch 1st gen, 2nd gen e.t.c). This is due to the amount of memory allocated when I load and store a 170k word dictionary.
This is the code (very simple):
string[] words = dictionaryRef.text.Split("\n"[0]);
_words = new List<string>(words);
This allocates on start around 12mb of storage, iphone has around 43mb I think. So that + textures + sounds + the OS it tends to break.
Speed wise, accessing using a binary search is fine. But its storing it in memory more efficiently (and loading it more efficiently).
The text.Split appears to take up alot of heap memory.
Any advice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我必须同意 Morningstar 的观点，即使用 SQLite 后端进行文字存储听起来是您想要做的事情的最佳解决方案。
但是，如果您坚持使用单词列表，这里有一个建议：
在我看来，dictionaryRef.text 是通过读取整个文本文件（File.ReadAllText() 或类似文件）来构造的。
与其这样做，为什么不使用 TextReader.ReadLine() 一次从文件中读取 1 个单词到 List 中，从而避免使用 String.Split() 并使用大量临时存储空间？
最终这似乎就是你想要的......并且 ReadLine() 将为你“分割” \n 。
I would have to agree with Morningstar that using a SQLite backend for your word storage sounds like the best solution to what you are trying to do.
However, if you insist on using a word list, here's a suggestion:
It looks to me like dictionaryRef.text is constructed by reading a text file in its entirety (File.ReadAllText() or some such).
Instead of doing that, why not use TextReader.ReadLine() to read 1 word at a time from the file into a List, thus avoiding the need to use String.Split() and using tons of temporary storage space?
Ultimately that seems to be what you want anyway... and ReadLine() will "split" on \n for you.
您不能过多地依赖这些 3.0 之前的设备在启动时有多少可用内存。 43 MB 是相当乐观的。您的应用程序只是检查该单词是否在列表中吗？您可能想要滚动自己的哈希表而不是使用二分搜索。我会搜索一些文献和堆栈溢出，以寻找有效的方法来存储具有特定字长的大型词典。谷歌搜索哈希表可能会给你一个更好的实现。
You can't count too much on how much memory these pre-3.0 devices have available on startup. 43 MB is rather optimistic. Is your app just checking to see if the word is in the list or not? You might want to roll your own hash table instead of using a binary search. I'd search some of the literature and stack overflow to look for efficient ways to store a large dictionary with the particular word sizes you have. A google search on hash table might give you a better implementation.
使用 SQLite。它将使用更少的内存并且速度更快。在单词列上创建索引，瞧，您可以进行二分搜索，而无需将整个字典加载到内存中。
Use SQLite. It will use less memory and be faster. Create an index on your words column and voila, you have binary search, without having the whole dictionary loaded in memory.
首先，如果 dictionaryRef.text 是一个字符串（看起来是这样），那么您已经分配了一些巨大的内容（每个字符 2 个字节）。检查一下，它很可能占分配的总内存的很大一部分（接近一半）。您应该考虑缓存它（数据库的想法是一个很好的想法，但文件可以在将来的执行中使用 File.ReadAllLines）。
接下来你可以尝试做比 Mono 的 Split 方法更好一点的方法。它创建一个列表，然后在最后将其转换为一个数组（调用 ToList） - 您最终将从中创建一个新列表。由于您的要求（仅“/n”）相当基本，我建议您推出自己的 Split 方法（或从 Mono 复制/粘贴/减少该方法）并避免临时内存分配。
在任何情况下，都会进行大量（内存）测量，因为分配（对于字符串来说更是如此）经常发生在我们不注意的地方;-)
First if dictionaryRef.text is a string (and it looks so) then you already got something huge being allocated (2 bytes per characters). Check this it might well account for a large (near half) amount of the total memory being allocated. You should think about caching this (the database idea is a good one, but a file could do to then use File.ReadAllLines in future execution).
Next you can try do a bit better than Mono's Split method. It creates a List and then turn it into an array (calling ToList) at the end - which you end up creating a new List from. Since your requirement (only '/n') is fairly basic I suggest you to roll your own Split method (or copy/paste/reduce the one from Mono) and avoid the temporary memory allocations.
In any case take a lot of (memory) measurements since allocations, even more for strings, often occurs where we don't look ;-)