Mobile Development 16 min read

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.

Architect
Architect
Architect
How Mobile QQ Overcame 20 Years of Technical Debt with a Multi‑Phase Architecture Revamp

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:

Architecture timeline
Architecture timeline
Old vs. new module layout
Old vs. new module layout
Compilation & conflict metrics
Compilation & conflict metrics

Code example

相关阅读:
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

cross-platformPerformance OptimizationCode Refactoringmobile architecturelarge‑scale system
Architect
Written by

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.

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.