Performance Optimization Strategies for Interactive Front-End Engine in the 2024 Douyin "Laughing China Year"

Startup Speed Optimization

In interactive scenes, the first‑screen performance is affected by engine initialization and resource loading. The team modularized the engine, removed global auto‑exec logic, and optimized the rendering pipeline. For the Spring Festival activity, the engine is instantiated inside the interactive container before the business page loads, enabling earlier engine warm‑up.

Game assets have many types, sizes, and dependencies. The following optimizations were applied:

Prefetch

Resources are requested as early as possible by configuring a manifest file that issues ordered requests after container startup. Prefetch limits on quantity and size are respected to avoid network contention and memory pressure.

UI assets required for the first screen are prioritized and kept within container limits.

Asset Splitting and Merging

Assets are serialized using AssetBundle. Files are reorganized so that small files are merged up to ~300 KB and large files are split into ~300 KB chunks, improving network concurrency.

Resulting file counts before and after optimization are shown in the table below.

Game

Before

After

Shenlong Treasure Hunt

180+

40

Shenlong Search

25

19

Guard Cash

12

8

Lucky Draw

20

4

Combined with Douyin's static resource distribution platform and cross‑platform rendering queue optimizations, the FMP (90th percentile) improved significantly compared with last year.

Platform

FMP (ms) 2024

Change vs. 2023

Android (Douyin Lite)

2232.79

-25.49%

iOS (Douyin Lite)

994.73

-4.95%

Runtime Performance Optimization

The engine’s core rendering module works in three stages per frame: CPU preparation, CPU‑to‑GPU upload, and GPU drawing.

CPU Stage : prepares animation data, material updates, etc.

CPU → GPU Stage : uploads data and issues draw calls; memory cost mainly from models and textures.

GPU Stage : performs rasterization and presents the final image.

Optimizations focus on reducing computation and memory usage in these stages.

CPU / GPU Optimization

Dynamic FPS

Default FPS is 30. High‑end devices use 60‑120 FPS, while low‑end devices stay at 30 FPS. The configuration object below controls the dynamic FPS logic.

GAME_MAX_FPS: {
  enable: false, // global switch
  useEverySecond: true,
  i32Forbidden: true,
  blackList: [],
  deviceScoreHigh: 10,
  deviceScoreMid: 8,
  deviceLevel: ['high'],
  frameSkipThreshold: 90 // enable frame skipping when real FPS exceeds this value
};

When the real FPS measured over 3 seconds exceeds 30 and the dynamic FPS switch is on, the engine raises the FPS limit; a value of 0 means uncapped.

Batch Merging

Many 2D sprites cause frequent draw calls. By ensuring sprites share the same texture (packed via TexturePacker), the engine can automatically batch them, reducing draw calls from 34 to 14 in a sample scene.

Without batch merging

With batch merging

Spine Optimization

For the "Guard Cash" game, Spine animations caused overheating and stutter on low‑end devices. Three measures were taken:

Reduce bone count to lower CPU/GPU calculations.

Disable Spine clipping attachments and replace them with engine Mask components to avoid heavy real‑time clipping.

Force single‑sided rendering to cut shader switches and CPU load.

const spineComponent = spine.getComponent(Spine);
spineComponent.materialSide = Sides.Front;

Memory Optimization

Profile Tool

The editor provides a memory profiling tool that lists geometry and texture objects with their memory consumption, helping developers identify oversized assets before release.

Texture Asset Optimization

Two strategies are integrated:

Compressed Textures : GPU‑friendly formats (ETC, ASTC) that keep textures compressed in memory.

Texture Downgrade : Serve lower‑resolution textures on low‑performance devices without affecting layout.

Developers can disable "Enable Write" and "Generate Mipmaps" for static UI textures to release CPU memory after GPU upload.

Future Outlook

The interactive engine has supported two consecutive Spring Festival events across Douyin, Douyin Lite, Toutiao, and Xigua. To meet growing complexity, the team plans "Interactive Engine 2.0" built on a native ECS and dual‑threaded runtime, delivering smaller packages, faster startup, and stronger performance.

Heavy third‑party modules like Spine will be reimplemented in C++ and compiled to WebAssembly, with additional caching strategies to reduce runtime computation.

Engine 2.0 is expected to ship mid‑2024 and support the 2025 Spring Festival activity.

Team Introduction

The Douyin Front‑End Architecture – Interactive Experience Technology Team provides interactive technology solutions for ByteDance products, including SAR Creator, Simple Engine, and the AnnieX interactive container.

Past Articles

Links to previous technical deep‑dives are provided for reference.