How Mobile QQ Overcame 20 Years of Technical Debt with a Multi‑Phase Architecture Revamp
This article details Mobile QQ's 20‑year evolution, the overwhelming technical debt that made its monolithic architecture unsustainable, and the multi‑stage decoupling, refactoring, and NT architecture upgrades that dramatically improved modularity, performance, development efficiency, and user experience across all platforms.
Background
Mobile QQ has evolved for more than 20 years from a simple instant‑messaging client to a platform that hosts spaces, channels, short videos, premium services and many other business modules. The code base grew to roughly ten million lines of C/C++ and Java/Kotlin, and the original monolithic architecture mixed core and business code, resulting in tight coupling, large compile times, frequent merge conflicts and a high risk of regressions.
Phase 1 – Decoupling and Refactoring (Nov 2020 – Feb 2021)
The "Industrial Practice" project introduced a systematic business‑boundary split. The new design groups code by business module, enforces a top‑down dependency hierarchy and defines clear interfaces between modules.
Module cohesion : each module contains its own business logic; changes in one module no longer affect unrelated modules.
Interface clarity : dependencies are reduced, making unit‑ and integration‑testing easier.
Key outcomes of Phase 1:
≈300 万 lines of core code were decoupled into ~30 base modules and ~40 reusable components.
Compilation time decreased by about 50 %.
Code‑conflict files reduced by 60 % and conflict occurrences by 30 %.
Phase 2 – NT Architecture Upgrade
After the initial refactor, the team tackled version fragmentation across Android, iOS and desktop. The NT architecture replaces the silo‑style code base with a cross‑platform C++ core that hosts the IM logic, common services (database, protocol, networking) and resource management. The migration path was staged: first integrate the core into the desktop client, then gradually roll out to iOS and Android.
NT Architecture Design
The cross‑platform core provides:
Unified IM business logic (friend, group, channel, rich‑media, real‑time audio/video).
Common components such as SQLite‑based storage, protobuf encoding/decoding, network transport and thread/IO abstractions.
Platform‑specific wrappers that expose the core to the native UI layers.
By consolidating platform‑specific implementations into the C++ layer, code reuse across the three client families increased dramatically, and maintenance manpower was reduced.
IM Full‑Link Rewrite
The most critical upgrade was a complete redesign of the IM pipeline. Legacy data suffered from:
No unique identifier for friend messages, making import and deduplication difficult.
Pre‑2012 group messages lacked roaming and unique IDs.
~200 different message types per mobile platform, leading to divergent storage formats.
Solution steps:
Message format unification : defined a single protobuf schema, reduced the number of message types, and introduced a global message‑ID generation rule.
Database migration : designed a new client‑side DB (SQLite + WAL) and built a resumable import tool that can handle up to 100 GB of user data per device.
User tiering : users are classified into three size‑based tiers; import speed and UI feedback are tuned per tier to avoid device overheating.
Throttled import & background handling : import is paused when the app goes to background and can be resumed later, ensuring no data loss even if the process is killed.
Monitoring & fallback : extensive metrics (import progress, error rates, device temperature) are reported to a central dashboard; a fallback path guarantees that messages are not lost.
Core Feature Optimizations
Beyond messaging, core QQ functionalities were extracted into the NT‑Runtime component. The chat window (AIO) was rebuilt using a unidirectional Model‑View‑Intent (MVI) architecture with:
Data pre‑loading and asynchronous rendering to keep the UI smooth during fast scrolling.
Parallel message loading that reduces first‑screen latency.
Dynamic loading/unloading of messages to lower memory footprint.
Lazy loading of >200 business components, enabling on‑demand initialization.
Other major UI flows (message list, rich‑media send/receive, image/video preview) were refactored with the same pattern, yielding consistent performance gains.
Results and Metrics
Compilation time reduced by ~50 % across all platforms.
Code‑conflict incidents dropped 60 % and total conflict occurrences fell 30 %.
Cross‑platform code reuse lowered maintenance headcount and accelerated feature delivery.
Message list scrolling became fluid with negligible jank; memory usage decreased due to lazy component loading.
Key Technical Artifacts
Architecture diagrams and migration flowcharts are included in the original article:
Code example
相关阅读:Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Architect
Professional architect sharing high‑quality architecture insights. Topics include high‑availability, high‑performance, high‑stability architectures, big data, machine learning, Java, system and distributed architecture, AI, and practical large‑scale architecture case studies. Open to ideas‑driven architects who enjoy sharing and learning.
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.
