Introduction

On Android, a very large dictionary stored as a normal in-memory HashMap often wastes too much memory, especially when keys are strings. The right storage strategy depends on the access pattern: exact lookup, prefix lookup, update frequency, and whether the data can stay on disk.

Start With The Real Requirements

Before choosing a data structure, decide:

• are keys integers or strings
• do you need exact lookup or prefix search
• is the dataset read-only after shipping
• must everything stay in RAM
• how fast is "fast enough"

These questions matter more than the word "dictionary." A read-only word list has different requirements from a frequently updated cache.

A HashMap Is Fast But Expensive

A HashMap<String, String> gives average O(1) lookup, but object overhead is large:

• each entry object consumes memory
• each String object has its own overhead
• the table itself has unused capacity for hashing efficiency

That makes HashMap convenient, but often not the best memory footprint on Android.

Sorted Arrays Plus Binary Search Are Often Better

If the data is read-only, a compact sorted array can be much smaller than a HashMap.

1val keys = arrayOf("apple", "banana", "carrot", "date")
2val values = arrayOf("fruit", "fruit", "vegetable", "fruit")
3
4fun lookup(key: String): String? {
5    val index = keys.binarySearch(key)
6    return if (index >= 0) values[index] else null
7}
8
9println(lookup("carrot"))
10println(lookup("pear"))

Lookup is O(log n) instead of expected O(1), but for many mobile datasets that tradeoff is worth it because memory use drops substantially.

SQLite Or Room Is Often The Best Practical Answer

If the dictionary is large enough that keeping it all in RAM is wasteful, store it in SQLite and index the key column.

1CREATE TABLE dictionary (
2    term TEXT PRIMARY KEY,
3    value TEXT NOT NULL
4);

Then query by key.

1val cursor = db.rawQuery(
2    "SELECT value FROM dictionary WHERE term = ?",
3    arrayOf("banana")
4)

This approach works especially well when:

• the dataset is large
• lookups are frequent but not millions per second
• the data should persist across launches
• memory matters more than pure in-memory speed

Use Specialized Structures For Special Needs

If you need prefix search, autocomplete, or compressed lexicon storage, a trie or a DAWG can be better than both HashMap and SQLite.

These structures reduce duplication among shared prefixes. For dictionaries like natural-language word lists, that can save a lot of space.

They are more complex to build, so they make sense mainly when prefix lookups are part of the product.

Avoid Loading More Than You Need

A strong design on Android often combines disk storage with caching.

For example:

• keep the full dataset in SQLite or a binary asset
• load entries on demand
• cache recently used results with LruCache

That gives you predictable memory usage while keeping repeated lookups fast.

Binary Formats Can Shrink The Footprint Further

If the dictionary ships with the app and never changes, a compact binary format can beat JSON and often beat naïve SQLite imports too. Fixed-width offsets, shared string tables, and prefix compression can reduce both APK size and runtime allocations.

This is more engineering work, but it is worth considering for very large offline datasets.

Common Pitfalls

The most common mistake is assuming HashMap is automatically the best answer because lookup is theoretically constant time.

Another mistake is optimizing only for lookup speed and ignoring startup cost or total RAM usage.

Developers also sometimes choose SQLite and then forget to add an index, which destroys lookup performance.

Finally, if prefix search is required, exact-match structures such as HashMap or a simple indexed table may still be the wrong tool.

Summary

• For read-only exact lookups, sorted arrays plus binary search are often memory-efficient.
• For large persistent datasets, SQLite or Room is usually the most practical solution.
• Use tries or DAWGs when prefix search matters.
• Combine disk storage with an LruCache when you need low RAM use and good repeat performance.
• Pick the structure based on lookup pattern and update frequency, not on big-O alone.