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.
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
