How QQ Space Overcame Code Decay with Progressive Refactoring

Background of the Space Refactor Project

QQ Space turned 18, and its codebase—over 1.5 million lines across five processes and two plugins—had become increasingly tangled due to multi‑team collaboration, leading to severe code decay and high maintenance risk.

Why a Refactor Was Needed

The code quality metrics were among the lowest in the ecosystem, bugs accumulated faster than they could be fixed, and the architecture could no longer support rapid feature iteration, making a large‑scale rewrite inevitable.

How the Architecture Degraded

Low extensibility caused heterogeneous business code to pollute core components.

Absence of isolation and a unified programming paradigm led to cross‑team coupling and style divergence.

Maintenance costs exploded, creating a vicious cycle of patch‑and‑break.

The Feeds stream ballooned to 18 scenarios and 60+ card types, turning the code into an impenetrable “forest”.

Four Guiding Principles for the Refactor

Progressive refactor – treat the rewrite like changing a tire on a highway, making small, safe steps.

Improve extensibility and reuse – enable low‑cost migration to other apps.

Long‑term complexity control – prevent complexity growth despite many teams.

Prevent degradation – quickly detect and isolate newly introduced bad code.

How Progressive Refactoring Is Implemented

Large problems are broken into many small, independently refactorable parts while keeping the system always runnable. The team first used the internal RFW‑Part framework to isolate legacy code, then refactored each Part according to priority, ensuring each change could be tested and released immediately.

Architecture Fusion

Old technical components were discarded in favor of the clean RFWComponent library, which is UI‑agnostic and can be used across apps. The middle layer now bridges RFW components with the unified Hand‑Q UI system, allowing developers to focus on business logic.

Pre‑emptive Technical Debt Reduction

Before touching business features, the team removed plugins, unified processes, optimized project structure, and improved compilation, simplifying the runtime environment and making subsequent refactor work more agile.

Ensuring Extensibility and Reuse

A finer‑grained layering was introduced:

Business layer – thin, focusing on middle‑layer responsibilities.

Technical layer – clean RFW components with no business intrusion.

Middle layer – bridges the two, can be migrated to other apps within a week.

Complexity Control with Part & Section

Part

provides page‑level isolation; Section further splits card logic into independent modules. Each Section is a self‑contained UI + logic unit, bound to a ViewStub for on‑demand loading. The framework includes Assembler, SectionManager, DataCenter, and an IOC system for communication.

Reliability Measures

Dynamic switches allow disabling any Part or Section via configuration, preventing faulty modules from affecting core functionality. Crash protection uses keyword‑based degradation to downgrade or disable problematic features. Extensive performance monitoring is built with Hand‑Q RMonitor, custom tracing, and ARTMethodHook for view‑level timing.

Performance Optimizations

First‑screen startup was accelerated by asynchronous layout rendering, pre‑loading cached layouts, and extending Part lifecycles so non‑critical features initialize after the initial screen. List performance was improved by async inflate of upcoming cards and replacing deep‑nested components with custom, fixed‑height widgets.

Results: cold‑start speed up 56 %, hot‑start speed up 53 %, and overall FPS increase of 4.9 % on the friend‑feed page.

Results and Outlook

AB‑test data shows higher code quality, better performance, and improved business metrics, which also boosted advertising KPIs. The most complex Feeds flow has been fully rewritten, half of the album module is refactored, and the remaining legacy code will soon be replaced, enabling faster delivery of new features.