a). Extract images from zim to local file system and provide them over a
ContentProvider.
b) Replace image src with base64 encoded image data. (Either directly on loading
of article or by using java script)

I'd be inclined to try the base64 data URIs for simplicity: you won't have to deal with cleaning up and maintaining a cache of extracted files.

On the other hand, data URIs will probably take up more memory, and you have to spend a little extra time on base64 encoding/decoding. Try it and see! :)

While this is not a problem with C code
even on embedded devices, it seems to be a problem with Java: Reading an article
at the end of a cluster takes close to 20 s on
my test android phone. As the phone is pretty low end (Orange
Boston ) and uses an old android version (Eclair) without a just-in-timer
compiler I expect that other models
are significantly faster. However, I doubt that the performance gain will be
sufficient to bring article load time in a range of << 1 s.
I am going to try it out, but I'd expect that we probably have to switch to
native code for zimlib support. (At least for liblzma).

Eek! Definitely should test on newer devices/OSs as well, at least to get a baseline to compare the native code against.

(Note that not all Android systems are necessarily ARM -- for best portability, being able to use the Java LZMA code if the native library can't be loaded might be nice.)

An other approach is to reduce cluster size of zim files. I am not sure right
now whether this would be sufficiently fast, but it is
worth considering it as an option: While for android being able to use the java
implementation is a benefit, it is also not a big thing
if native code has to be used. However, more concerning is that it may not be
possible to support for Windows Mobile at all with the
current cluster size. (Because AFAIK not native code is supported)

Windows Mobile / Windows Phone should have a decent JIT compiler for .NET code, so it's at least worth testing...

-- brion