离线包不会包含在应用里，主要是处理翻译的组件，这些组件必须跟应用一起发布并且体积比较大。
其实如果你能安装谷歌翻译应用的话，你也可以直接用Dict Tango调用谷歌翻译进行离线翻译。
Mdict 中查询单本词典时，貌似就是加载了全部词条。这时查词更像是定位到词条列表中相应位置，在词条中点击了跳转，像是定位到词条列表中新的位置，而且很顺畅，似乎没有进行大量运算。这时点击查询框，它的“词条列表”就定位到了当前词条。我清空手机缓存及 Mdict 的用户数据，其词条顺序没有变化。
PS：说了这么多，并不是我多想要这个功能，只是为楼主提供一个参考。
其实MDICT在背后并没有加载全部，因为Mdict应用本身并没有索引，你可以发现它的中文词条并不是按拼音排序的，这个时候加载词条不会花太多资源，直接mdx文件就行。但DictTango是经过索引按拼音重新排序的，所以两者的处理的处理方式并不一样。
以后有时间我再想一个比较好的处理办法。
辛苦楼主了，是我的要求太多了 
也不是，从用户的角度来看这要求很合理，只是我还没有找到一个解决方案而已，哈哈
用数据库就好了，多一点存储空间，在 2022 年应该不是什么问题了。
MDX 在以前为了减小存储空间，浪费太多时间了。
供参考：23 万词条的 MDX 包含压缩块信息的 sqlite 数据库文件大小是 15MB。
LDOCE5++ V 1-35.mdx.db (15.2 MB)
词头可以存数据库，词条内容还是压缩一下比较好
我之前还真有想过用sqlite来替代mdx的想法，但后来还是放弃了。
第一点主要是sqlite的查找还是比用二分法查找mdx文件的方法慢，一两个词典可能不明显，但如果词典数量多的话，还是有影响的。
第二是sqlite有一定的几率会出现数据库文件的损坏
其实很多mdx比较大的原因不是里面真正的内容多，而是为了展示这些内容的所使用的html代码比较多，我觉得最理想的是把展示层的html代码和数据分开来处理，用比较流行的网页模板方式来实现，这样子应该大大减少mdx的占用空间
不用替代，就像我发的那样，做增强索引就行，不存内容。另外不太可能 sqlite 比二分查找还慢吧，可以跑 1M 查询测试下，我不太信。。 损坏可能是 日志 的问题。
这里有个很好的帖子，其中二楼写了代码证明哈希算法是比二分法快，但这个结论是在数据要先进行排序的前提下的。
个人觉得，如果数据已经预先排好序，二分法还是无敌的。
https://www.sqlite.org/queryplanner.html#_lookup_by_index
也是 binary search。不存在词典数量多导致两者速度上有太大差异把？
我觉得Sqlite只在精确匹配的情况下才会做Binary search。
这里说了Binay search只是在fruit='Peach‘ 才会执行，如果fruit like ‘Peach%’ 就未知了，而在mdx查词的时候，我们往往是需要用到fruit like ‘Peach%’ 这种方式的，还有sqlite在fruit='Peach‘ 时会做两次的binary search (看上图的加粗部分），而现实情况中，我们只需要取第一次的结果进行显示。
2.1.7版本安装包56.4MB，太大了，能否精简一下体积呢？（2.1.6版本只有15.1MB）
请参考一下我这里的说明
这些组件是进行文字识别必需的，如果要精简也不是没有办法，但前提是每个人的手机上都安装谷歌的GMS才行，目前来说这个前提不是很现实。
而且相对于动辄几百M的词典来说，我相信50M对于现在的手机存储完全不是问题。
感谢回复。很多国产手机不支持Google的GMS，其中最典型的是华为手机（手机操作系统自带登录Google账号的，基本上支持Google的GMS。大家都可以检查一下自己的手机，看看支不支持Google的GMS）
我知道的不多，不好说这个。官网有关于 LIKE 的优化的文档。
不过对与你的说的需要两次 binary seach 那是在要获取该 row 的其他 column 的时候吧。
不是的，你看它的解释，第一次是在索引里Binary Search, 获取结果后根据rowid再到表的记录做多一次Binary Search
左边是 ：
SELECT fruit FROM fruitsforsale WHERE fruit=‘Peach’;
右边是：
SELECT price FROM fruitsforsale WHERE fruit=‘Peach’;
明显右边多了一个 OpenRead
挺好，以前安卓上面主要用goldendict 同时辅助mdict，
果断下载替换了mdict，准备逐步也把goldendict中的词典全部转移过去