A heavy reader's entire library, imported in one select-all

The test device was a vivo foldable loaded with a snapshot of a real phone's storage (91 files, 570MB) on top of the device's own accumulated clutter. Smart scan turned up 315 webnovel txt files — in the QQ Browser download folder, inside other readers' private directories, buried in dot-prefixed hidden folders, encodings all over the map, the largest single file 30MB. Which is exactly the environment we wanted: not laboratory-clean data, but the way a heavy reader's storage actually looks.

The method was as blunt as possible: smart scan, select all, import, then open ten books at random. The ledger from two devices:

The numbers

Notes on what these numbers mean. “Batch ingestion ≈8 seconds” covers 315 books (about 1GB) from confirming the import to everything shelved — import is register-first, so books land in a pending state and full parsing happens on first open. Fast ingestion is not corner-cutting; the cost is amortized onto each book's first open (3 to 7 seconds, after which opens ride the index and are much quicker). The jank rate comes from Android's own frame accounting, not our self-reported telemetry.

The real bug this test caught

The best outcome of the round was not the numbers. During bulk import, books picked through the system file picker are first copied to a staging area; the old implementation staged them in the system cache directory, and pending books kept pointing there long-term. The problem: the OS is free to clear its cache directory whenever it wants — meaning that of your 315 imported books, the ones you had not yet opened could be permanently corrupted by a routine system cleanup.

The fix moved staging to a persistent directory, reclaims each copy the moment conversion succeeds, and sweeps orphans when the import finishes. Re-verified on both devices afterwards. The point of writing this down: performance testing earns its keep by forcing features through a full-scale, real-shape pipeline — a 315-book, 1GB pile builds scenarios a unit test never will.

Why we obsess over import, of all things

Because migration cost is the first wall around any reader. A book hoarder's library is not in a cloud; it is scattered across the odd corners of their phone. Whoever makes the moving-in step painless earns the right to talk about everything after it. Our trade-offs: scan wide (hidden folders included), ingest fast (feedback within ~8 seconds at the three-hundred-book scale), parse lazily (amortized to first open), and fail soft (encoding detection falls back and retries rather than rejecting).

What happens after the books arrive is other posts' territory: select any sentence and have AI continue it as a preserved branch, listen to whole chapters as an AI audiobook on the commute, or hand the shelf's chores to the resident agent. Same bookshelf, every door.