How Kuaishou Evolved Its Special‑Effects Tool from QWidget to Dynamic QML & Lua

Background

In the software industry, dynamic resource distribution and hot‑update of apps are hot topics. Updating app resources and functionality without a new release improves user experience and retention. Kuaishou's effects tool, which offers makeup, beautification, and visual effects, has continuously explored related technical solutions.

Development Stages

Stage 1: QWidget Layout

Initially, developers used Qt Designer with basic QWidget controls for UI layout and wrote C++ code to handle parameter set/get methods and ValueChanged events, notifying the rendering engine for real‑time updates. This approach allowed rapid addition of new effects but required significant code per effect.

Advantages and disadvantages were illustrated in the diagram below:

Encapsulating common components (file import, group folding, percentage adjustment, sliders with labels) greatly improved development efficiency for new effects.

Stage 2: QML Layout

With QWidget, each new effect required a set of .ui/.h/.cpp files (200‑1000 lines). As the number of effects grew, development speed lagged. QML offers a more concise way to build Qt UI, so common components were re‑implemented in QML. Adding a new effect now only needs a QML file, keeping code under 200 lines and improving readability.

Stage 3: JSON Config / Lua Scripts

Rapid growth created a bottleneck: new effects could not be delivered quickly, and the project became bloated. Inspired by game‑industry practices, Kuaishou adopted Lua for configuration and hot‑update. A template engine parses effect assets; designers create new resources on a management platform, which are fetched by the client at runtime.

This decoupled the effect tool from its assets, allowing designers to add or modify effects without developer involvement. Code per effect shrank from nearly a thousand lines to under a hundred.

JSON configuration files now replace most QML files; a few dozen lines suffice to define a new effect's parameters.

Stage 4: Dynamic QML Configuration

While JSON/Lua covered most cases, complex UI layouts and custom components still required QML. The solution added support for dynamically delivering custom QML files alongside JSON. The engine first checks for a custom QML description; if absent, it falls back to the generic JSON config.

However, delivering raw QML source to the client raises security concerns, requiring encryption or obfuscation.

Conclusion

The UI configuration workflow evolved through several stages, abstracting resource configuration, distribution, loading, and management into independent modules. This decoupling reduced coupling between assets and the main tool, enabled reuse of the asset parsing engine, and satisfied most operational requirements while allowing rapid customization for special cases.

From a technical perspective, the code required for a new effect decreased from nearly a thousand lines to under a hundred, simplifying maintenance.

A comparative chart of the four stages is shown below:

Ultimately, the evolving technical solutions enabled developers to focus on tool development, product teams to meet designer needs, and operations to manage effects on demand. Future work includes extracting the UI component library and parsing engine into a standalone module and implementing encryption for custom QML files to protect source code.