How QDPaging Boosts Android App Performance with Preloading and State Management

1. Background

Since joining Qidian, we iterated the Qidian Reading community business. In the benchmark Weibo list we rarely see a loading state at the bottom, indicating data preloading. Our app shows a Loading state when scrolling to the bottom.

2. Solution Selection

Android Jetpack's Paging provides preloading, but both Paging 2 and Paging 3 have pain points.

Paging 2 Issues

API is hard to use: different data sources for different scenarios.

No state management: difficult to monitor request status and update UI.

Paging 3 Issues

Adapter conflicts with existing RecyclerView adapters, making integration difficult.

Data interface returns extra information (e.g., circle info) besides the list, complicating handling.

We therefore created a custom wheel QDPaging .

3. Framework Structure

3.1 Basic Functions

The core requirements are data preloading and state management.

3.1.1 State Management

State management interacts with UI. QDPaing borrows the state structure from Paging 3.

Corresponding states:

Refresh : refresh scenario.

Append : load more.

Prepend : load previous.

3.1.2 Data Preloading

Unlike Paging 3, QDPaging does not use coroutines and Flow; it uses Paging 2's thread pool + LiveData for loading.

Preloading is triggered when:

Binding data: Adapter's getItem meets conditions.

loadMore: RecyclerView's wrapped loadMore method fires.

refresh: refresh scenario.

3.2 Other Functions

3.2.1 Transmitting Non‑list Data

When an API returns extra data, we can wrap it in an Any field (similar to Java's Object) and expose it via LiveData.

3.2.2 Data Capacity Limitation

QDPaging uses a doubly linked list; each page is a node. When capacity exceeds a threshold, nodes are dropped from the front or back to control memory.

3.2.3 Code Reduction

Automatic triggering of refresh and load‑more requests.

Automatic UI state switching for loading, refresh, and normal data.

Error handling.

4. Results

We define the request triggered by scrolling to the bottom as an “effective loading wait scenario”. After applying QDPaging, the average effective wait count per user dropped from 4.485 to 0.015, a 99% reduction.

Additional benefits:

Reduced logical code.

Combined Android Jetpack LiveData and Lifecycle to lower crash risk from component lifecycles.

Data capacity control reduces memory usage.

5. Conclusion

QDPaging achieves the desired performance improvements, but further work is needed: decouple the paging library from Qidian UI components and expand preloading to more pages. Android Jetpack remains a valuable toolkit for future development.