Mobile Development 21 min read

How to Supercharge Mobile Seat-Selection Apps: Data, Caching, and Rendering Optimizations

This article details comprehensive strategies for handling massive seat‑selection data on mobile devices, covering data modeling, interface pre‑loading, static and dynamic compression, view hierarchy tweaks, bitmap reuse, drawing optimizations, hardware acceleration, and multithreaded task handling to dramatically improve load times and frame rates.

Alibaba Terminal Technology
Alibaba Terminal Technology
Alibaba Terminal Technology
How to Supercharge Mobile Seat-Selection Apps: Data, Caching, and Rendering Optimizations

Mobile apps usually avoid processing massive data due to device constraints, but seat‑selection scenarios like Damai's require handling tens of thousands of seats efficiently.

The venue model includes static seat data (id, price, coordinates, angle, position) and dynamic seat status, which together can exceed 9 MB for static XML and 1.8 MB for dynamic JSON in a 60 k+ seat stadium.

Interface Pre‑loading Strategy

Seat selection uses many network calls; pre‑loading static data (Areainfo, StaticSeat, StaticSvg) and early dynamic calls (DynamicInfo, Seatstatus) reduces CPU spikes.

Render time: Areainfo, StaticSeat CDN, StaticSvg CDN, DynamicInfo, Seatstatus

Refresh time: DynamicInfo, Seatstatus

During selection: Precheck, CalcPrice

Static Data Pre‑loading

Static assets are cached on CDN and downloaded during idle time before entering the seat‑selection flow.

Network Interface Pre‑loading

In Android, requests for DynamicInfo and Seatstatus are triggered in Activity.onCreate() to spread load and avoid a burst of concurrent calls.

Static Data Caching

Static seat data and SVG files are cached using BaseLoader and strategic caches with soft references to enable reuse without excessive memory pressure.

ImageLoader – SVG/JPG loading and caching

Seat3DVrImageDataLoader – VR image download and decryption

Seat3DVrDataLoader – VR structured data download and decryption

SeatLoader – generic static seat data download, decryption, caching

Static Data Compression

Seat Data Compression

The "Quantum" solution compresses static seat files using ZigZag integer encoding and dictionary techniques, achieving >70% size reduction over XML+GZIP and >80% faster parsing.

Static VR Data Compression

VR seat data stored with Protocol Buffers shrinks from ~640 KB (JSON) to ~250 KB, and after GZIP to ~8 KB, a >35% reduction.

Dynamic Seat Data Compression

Dynamic seat status (2 for available, 8 for sold) originally required 1.8 MB JSON; a custom compression removes seat IDs and uses run‑length encoding, reducing the payload to ~67 KB (>90% reduction) and cutting parse time from 200 ms to 5 ms on a OnePlus 7 Pro.

Dynamic Compression Strategy

By ordering seats consistently, the server can stream status strings per stand, using patterns like "(6,2)8" for repeated values, and in the simplest case a single "5000,2" for an entirely available block.

View Hierarchy Optimization

ViewStub is heavily used to lazily inflate rarely visible views, and unnecessary common layout layers are removed to keep the hierarchy shallow.

Rendering Performance Optimization

Seat bitmaps are reused based on four attributes (color, angle, type, selection flag) by encoding them into a 64‑bit key stored in a LongSparseArray, eliminating costly StringBuilder allocations and improving frame rates by ~4 fps.

private final HashMap<String, Bitmap> mSeatPool = new HashMap();

public Bitmap get(int color, float angel, int type, boolean addAlpha) {
    int angelInt = (int) angel;
    String key = "key_" + color + "_" + angelInt + "_" + addAlpha + "_" + type;
    Bitmap seat = mSeatPool.get(key);
    if (seat == null) {
        seat = newBitmap(color, angel, type, addAlpha);
        mSeatPool.put(key, seat);
    }
    return seat;
}

After switching to a long‑based key and LongSparseArray, memory spikes disappear and average frame rate exceeds 50 fps.

Drawing Efficiency

Only seats within the viewport are drawn; for large venues, the stand overview is shown first, and detailed seats are rendered on demand.

Angle Calculation Optimization

Replacing Matrix transformations with direct Math trigonometric calculations reduces overhead.

Floating‑Point Optimization

Converting float dimensions to int where precision loss is acceptable improves performance without noticeable visual jitter.

Hardware Acceleration

SVG rendering is performed with Picture objects; hardware acceleration is enabled on API 28+ devices, while lower APIs fall back to software rendering, with a remote switch to disable if issues arise.

Thread Task Handling

Pre‑loaded static data and SVG are parsed on background threads; dynamic data is decompressed quickly, preventing main‑thread blocking as shown by Perfetto traces.

Summary

Since 2021, these layered optimizations have cut page load time from ~850 ms to ~320 ms and raised average frame rate from 38 fps to 54 fps, making the seat‑selection experience one of the fastest and most data‑intensive screens in the app.

References

Google Developers – Protocol Buffers; Android Developer – Hardware Acceleration; Perfetto tool.

mobilePerformanceAndroidcachingdata compression
Alibaba Terminal Technology
Written by

Alibaba Terminal Technology

Official public account of Alibaba Terminal

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.