BigImageViewPager: an Android image and video viewer built around tiled decoding

What the library actually solves

The repository description is unusually direct about the problem: an image or video browser library that supports oversized images, very long images, animated images and video, with gestures, original resolution viewing, download, and load percentage progress. The technique behind it is named as block reuse loading, described as reducing memory footprint and lowering the risk of an out of memory condition. That is the entire premise, and it is a real one. Android will refuse to decode an image whose pixel dimensions exceed its own limits, and a full height panorama screenshot will also blow past the bitmap budget on most devices.

The feature list expands on that in a few directions: two finger zoom, pan, and horizontal swipe to move between items; viewing the original file, downloading, and listening to load progress; a choice of video autoplay policies; dynamic addition and removal of data sources at runtime; and the tiled loading approach already mentioned. The repository is written in Chinese, which matters for anyone who needs to modify it, since the class and method names are in English but the documentation around them is not. The topics include 16kb page sizes and android16, alongside the image oriented tags, and the changelog records 32 bit 16KB page size support arriving in 8.4.7, which is the detail that matters most if you are shipping to recent Android hardware.

Core library and optional Media3 video plugin

Since version 9.2.2 the video capability has been split out of the core library into a separate optional plugin, and the migration guidance in the README is explicit about which artifact you need. Image only apps keep just `BigImageViewPager`; apps that preview video add `BigImageViewPager-media3`. The maintainer also recommends that the two artifacts be published under matching version numbers, which is a sensible rule for anyone mirroring the pattern.

dependencies {
    // 必选：核心库（图片能力）
    implementation "com.gouqinglin:BigImageViewPager:androidx-9.2.2"

    // 可选：视频插件（需要视频预览时添加）
    implementation "com.gouqinglin:BigImageViewPager-media3:androidx-9.2.2"

    // 必选：Glide
    def glideVersion = "4.16.0"
    implementation "com.github.bumptech.glide:glide:$glideVersion"
    annotationProcessor "com.github.bumptech.glide:compiler:$glideVersion"
    implementation "com.github.bumptech.glide:okhttp3-integration:$glideVersion"
}

Three details stand out in that block. Glide is a required dependency rather than an optional one, the annotation processor is still the older `annotationProcessor` mechanism rather than KSP, and the OkHttp integration is what makes progress reporting possible at all. The module layout in the repository tree matches the artifact split, with a `library/` directory and a `library-video-media3/` directory alongside a `sample/`. The library was renamed to an `androidx` version prefix, so the coordinates in the README are not the ones older tutorials and Stack Overflow answers will show you. Projects building against the source tree directly are shown as commented out `project(...)` references, one per module.

Progress reporting depends on replacing Glide's URL loader

The one piece of setup the README insists on is a Glide module, and it explains why in a single line: without it, load progress for the original image can stall at 1 percent. The mechanism is a standard Glide extension point where you replace the loader used for network URLs with one that reports progress:

@GlideModule
public class MyAppGlideModule extends AppGlideModule {
    @Override
    public void registerComponents(@NonNull Context context, @NonNull Glide glide, @NonNull Registry registry) {
        super.registerComponents(context, glide, registry);
        registry.replace(
                GlideUrl.class,
                InputStream.class,
                new OkHttpUrlLoader.Factory(ProgressManager.getOkHttpClient())
        );
    }
}

This is worth understanding rather than copying, because the same technique applies to any image library where you want a real progress bar. Glide has no built in knowledge of download progress for a plain URL, so the library ships its own OkHttp client through a `ProgressManager` and swaps it in at registration time. Once that is in place, launching a preview is a single chained call:

ImagePreview.getInstance().setContext(MainActivity.this).setMediaInfoList(imageInfoList).start();

The singleton with chained setters is not the most modern Android API style, but it does keep the entry point to one line and it is the shape most existing snippets in the wild use. For video, one more setter selects the autoplay policy, with three documented options: `WiFiOnly`, `WiFiAndMobile` which is the default, and `Manual`. The README also states the runtime behaviour at both ends of the optional module: if you have not added the media3 plugin, a video entry degrades to a message saying the video capability is unavailable without breaking image preview, and if you have, video works with no extra initialisation. Closing the preview page releases the video runtime, and re-entering rebuilds the cache and player session.

Licence, versioning, and what the tree reveals

There is a licensing ambiguity here that you should resolve yourself before shipping the library. The repository tree contains a `LICENSE` file, the README carries a licence badge pointing at that file, and the README's licence section quotes the Apache License 2.0 header in full, attributing copyright to SherlockGougou from 2018. GitHub's own licence detection, however, reports NOASSERTION for this repository, meaning it did not resolve a licence from the metadata it can parse. Both facts are in evidence, and the practical advice is to open the `LICENSE` file and read it rather than relying on either the badge or the API.

Version naming is the other thing to get right. Tags are prefixed by the support library generation, so the current release is `androidx-9.2.2` from July 2026, preceded by `androidx-9.2.1` in April 2026 and `androidx-8.4.8` in November 2025. The 9.2.x line is where the plugin split and the play policy landed; 8.4.x was the pre-split line with video in the core. The changelog in the README is a good record of the recent decisions: 9.2.1 fixed a bug where a video Fragment retained audio after being recycled and cleaned up leftover View references, and 9.2.0 made ExoPlayer via Media3 an optional dependency specifically so image only builds could shrink the APK.

The rest of the tree is more about process than product. There is a `build.gradle.kts` and `settings.gradle.kts` at the root, so the project itself is on Kotlin DSL, alongside three shell scripts for publishing (`publish.sh`, `upload-central.sh`, `package-central.sh`) and a `common-60.keystore` file committed into the repository. An `AGENTS.md` at the root suggests the maintainer keeps agent instructions alongside the code. Documentation beyond the README lives in `doc/`, with `doc/DETAIL.md` named as the reference for the full parameter list, which is where you should go after the one line launch call stops being enough.

Editorial conclusion

BigImageViewPager solves one unglamorous problem properly: showing an image too large for Android to decode whole, or too long to fit a screen, without the out of memory crash that usually follows. The tiled loading strategy and the Glide integration for real progress percentages are the parts worth borrowing conceptually even if you write your own. Two decisions shape adoption. First, video support moved out into a separate Media3 plugin at 9.2.0, so image only apps take a smaller dependency set and video entries degrade to a clear unavailable message rather than crashing. Second, the licensing is stated inconsistently, with a LICENSE file and an Apache 2.0 notice in the README while GitHub itself reports no recognised licence, so read the file yourself before shipping it. Start with the core artifact and add the media3 module only if you need video.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. SherlockGougou/BigImageViewPager on GitHub