Mobile Development 21 min read

Douyin’s Dynamic Performance Framework: Design, Perception, and Optimization Practices

The article details Douyin's Dynamic Performance Framework (DDPF), covering its evolution from static resource scheduling to a multi‑dimensional signal‑driven system, the perception and decision layers including low‑interaction detection and end‑side intelligence, and concrete VM tuning cases that illustrate how dynamic optimization is achieved on Android.

ByteDance SE Lab
ByteDance SE Lab
ByteDance SE Lab
Douyin’s Dynamic Performance Framework: Design, Perception, and Optimization Practices

Background and Challenges

Douyin’s Android client now supports short‑video, live streaming, e‑commerce and local services, which increases user interactions, memory peaks and concurrent task counts. Traditional resource scheduling cannot keep up with the high‑performance rendering, low‑latency streaming and multi‑threaded pre‑loading requirements.

DDPF Framework Design and Evolution

Evolution Path

The framework progressed through three stages: (1) static decoupling, (2) a dynamic signal chain, and (3) a “thousand‑person‑one‑face” model that moves logic from hard‑coded to cloud‑configurable, multi‑dimensional filtering.

Framework Structure

Core concepts include a global signal bus, session‑based rule loading from an internal experiment platform (JSON), and a three‑layer filter program (signal, state, rule) that decides whether a decision passes.

Core Chain

Signal generation and distribution – When a user event (e.g., a swipe) occurs, the corresponding scenario captures the event and posts a signal object with parameters to the global bus.

Rule loading and subscription – At app start, the session fetches the latest JSON governance rules, parses them, and subscribes to the relevant signals.

Multi‑dimensional composite filtering

Signal filter – Checks whether signal parameters satisfy preset thresholds (e.g., swipe speed > threshold).

State filter – Verifies global device state such as battery level > 50%.

Rule filter – Executes a dynamic expression that may reference signal parameters, global state or server‑provided predictions.

Decision and action submission – If all three filters pass, the session creates one or more Action objects and submits them to the core scheduler; otherwise the flow stops.

Asynchronous safe execution – The scheduler queues actions in a low‑priority background thread pool, preventing blockage of the main or critical business threads.

Beyond the Framework

Standardized signal transmission, state management and action execution are provided, but achieving user‑perceptible experience gains requires deeper perception capabilities and richer scheduling abilities.

Perception and Decision

Complex Perception Capability

Low‑Interaction Scenario Construction

Short‑video usage shows frequent swipes, while long‑video viewing is immersive with minimal interaction. The system scores stay time and interaction frequency; when the cumulative score exceeds a threshold, the app enters low‑interaction mode, enabling pre‑loading and cleanup optimizations without causing jank.

Low‑Interaction Scenario
Low‑Interaction Scenario

Performance Load Grading

Core metrics are sampled periodically, smoothed with an Exponential Weighted Moving Average (EWMA) to reduce spikes, and mapped to four standardized levels: Low, Medium, High, Extreme. Memory load is the primary metric, collected lightweight from JavaHeap via the Runtime API and from NativeHeap via mallinfo. AB testing can adjust thresholds per device model, and the graded signal drives downstream strategies (e.g., memory‑related optimizations) without requiring a new app version.

Performance Load Grading
Performance Load Grading

End‑Side Intelligence Application

Static rule‑based filters become unwieldy as scenarios multiply and cannot predict future trends. End‑side models run on the device, ingest real‑time features (e.g., memory allocation rate) and produce second‑level predictions that trigger proactive adjustments.

Low‑latency decision – models run on‑device to predict issues seconds ahead.

Privacy protection – all feature extraction and inference stay local.

Edge‑cloud collaboration – the model outputs a label, confidence and extended parameters that DDPF translates into concrete actions.

End‑Side Large Model

A large on‑device model can understand complex, long‑term performance contexts. For example, when high CPU, high memory and continuous jank are detected, the model outputs a structured JSON containing multi‑step actions such as pausing pre‑fetch, raising render‑thread priority and changing GC type, together with a natural‑language explanation.

Output format stability – large models often produce malformed JSON; prompt engineering and validation are required.

Inference latency – hundreds of milliseconds to seconds, suitable for sustained degradation rather than instant spikes.

Context length and cost – token budget on mobile devices necessitates efficient summarization.

Model capability and deployment – vendor‑provided models affect integration cost and feasibility.

VM Tuning Specialization

Data Collection

A comprehensive data‑point system is built for VM modules, enabling fine‑grained analysis of memory management, GC, code execution and compilation.

VM Data Collection
VM Data Collection

Memory Management and GC

GC is divided into pre‑, mid‑ and post‑phases, each exposing adjustable parameters. Dynamic tuning of these parameters is guided by the graded memory‑load signals.

GC Tuning
GC Tuning

Code Execution and Compilation

The VM also handles Java/Kotlin execution, hotspot detection and JIT compilation. Adjustable levers include JIT thresholds, ProfileSaver behavior and AOT profile generation. Controlling ProfileSaver writes (AddMethod filter, profile translation, options) allows fine‑tuned hotspot recording and diffing.

JIT and ProfileSaver
JIT and ProfileSaver

Dynamic Tuning Cases

Leveraging DDPF, data insights and the newly built tunable capabilities, several large‑scale strategies have been deployed, delivering measurable performance gains across the user base. Representative cases include:

Memory‑load‑driven pre‑fetch throttling.

GC priority elevation during predicted stalls.

Multi‑action plans generated by the end‑side large model (e.g., pause pre‑fetch, raise render thread priority, switch GC type).

Dynamic Tuning Cases
Dynamic Tuning Cases

Summary and Outlook

Beyond perception and decision, two core directions remain critical:

Dynamic diagnosis – integrating trace capture and memory‑snapshot restoration with DDPF to provide online diagnostic capabilities.

Data mining – extracting high‑value strategies from hundreds of signals and tunable actions, enabling a closed‑loop system where precise perception, intelligent decision and flexible scheduling jointly support diverse Douyin scenarios and offer a reusable paradigm for industry‑wide dynamic performance governance.

Future Vision
Future Vision
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.

Performance OptimizationMachine LearningAndroidDouyinDynamic PerformanceSignal Framework
ByteDance SE Lab
Written by

ByteDance SE Lab

Official account of ByteDance SE Lab, sharing research and practical experience in software engineering. Our lab unites researchers and engineers from various domains to accelerate the fusion of software engineering and AI, driving technological progress in every phase of software development.

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.