uni-app x Steam Mode Performance Benchmark Report [Android Edition]

Background

uni-app x Steam Mode is a new version of the cross-platform development framework launched by DCloud in 2026.

Its defining characteristic is: faster than native.

• The HarmonyOS platform version of uni-app x Steam Mode was released earlier on May 1st. See the evaluation report here: uni-app x Steam Mode Performance Benchmark Report [HarmonyOS Edition]
• The iOS platform version was released on May 11th. See the evaluation report here: uni-app x Steam Mode Performance Benchmark Report [iOS Edition]

The Android platform version was released on May 21st and graduated to stable on May 23rd.

This report is the performance evaluation for the Android platform, completing the final evaluation report for all three mobile platforms. It uses data to quantify the leading advantage of uni-app x Steam Mode across the three App platforms.

• Can a cross-platform framework be faster than native?
• Can a JS-driven cross-platform framework be faster than Kotlin/Java?

This information contradicts common understanding. Therefore, when something counterintuitive appears, a rigorous and objective benchmark is especially important.

The goal of this benchmark test is to truthfully present key performance indicators and ensure that developers can independently reproduce this benchmark and arrive at similar conclusions.

A brief introduction to uni-app x and Steam Mode:

• uni-app x uses Vue syntax and removes the virtual DOM in Steam Mode.
• Steam Mode activates a brand-new rendering engine. Templates and styles in pages are compiled into bytecode/machine code. script supports js/ts/uts, and strong typing is no longer mandatory.
• uni-app x is based on the native rendering pipeline, can integrate with the native component ecosystem, and occupies less memory.
• Steam Mode provides a large number of self-developed high-performance components, such as view, text, image, list, rich-text, swiper, canvas, picker, etc.

Test Metrics

The core performance metrics of a UI system are: rendering speed, frame rate, and memory usage.

Faster rendering speed means less waiting; fewer dropped frames mean smoother performance; lower memory usage means the phone runs more smoothly overall.

Human perception can be recorded on video, but test metrics must be precisely measurable, requiring an accurate measurement scheme.

Environment Declaration

Due to the high degree of freedom on the Android platform, it is easy to create unfair evaluation reports through various black-hat techniques. Therefore, the Android platform evaluation report will be much longer than those for HarmonyOS and iOS, to describe how to fairly set up the test environment in the experiment.

This Benchmark uses two Xiaomi Fold4 devices. Specific information is as follows:

• Device Model: Xiaomi Fold4

  Device Processor: Snapdragon 8 Gen 3. Total 8 cores:

  This device is a 2024 flagship, but Android's power-saving strategy is quite aggressive, making the prime core difficult to activate. When test code runs on the performance cores, the speed is no different from an ordinary mid-range phone.

  • Prime Core: 3.30 GHz × 1
  • Performance Cores: 3.15 GHz × 3 + 2.96 GHz × 2
  • Efficiency Cores: 2.27 GHz × 2

• OS Version: Android 16

• Battery level above 90%, power-saving mode and performance mode not enabled.

• Screen refresh rate set to High, i.e., 120Hz.

• Auto-start disabled for all apps, including WeChat. All devices restarted before testing and left idle for 2 minutes. All other app processes killed during testing.

• Device temperature monitored throughout; testing stopped if the device heats up to avoid system frequency throttling.

• Devices were not rooted.

Besides a clean test device, the application itself must not use cheating methods.

• All APKs run in release mode.

• App package names are ordinary package names, not impersonating major companies or professional performance testing app package names, and do not contain the word "benchmark".

• No application-level methods are used to force promotion to the prime core. Perfetto CPU scheduling is observed during the experiment to ensure code runs on the performance cores. If the system schedules code to other cores, that round of experimental data is discarded.

• Since Compose UI includes framework-level baseline optimization by default, which aligns with the actual scenario for most users, the framework part of uni-app x also includes baseline optimization. However, whether for Compose UI or uni-app x, only the framework undergoes baseline optimization; application code does not enable baseline optimization.

• No preloading, no pre-triggering of JIT.

• Test data is divided into two batches for independent comparison: first-time APK installation and idle-time optimization.

  The idle-time optimized state is the usage scenario for most Android users. After an app is installed and the phone is charging and idle, the Android system silently performs machine code compilation optimization in the background.

• When testing dropped frames, simultaneously enable the screen refresh rate display in developer options and turn on the bar chart for HWUI rendering profile analysis.

View and Text Rendering Speed Test

view and text are the core foundations of the rendering engine; a large number of components are built based on these two basic components. The rendering speed of these two basic components is the most core performance indicator of a rendering engine.

A reliable way to verify whether the creation speed of view and text is fast enough is to create a large number of view and text components on the same screen and calculate the time consumed.

Test Method

After clicking a button, create 2000 view components on the screen. Each view has a background color, and each view contains a text component.

The 2000 views must be displayed in the same screen area, not off-screen, and without using a scrollable area, to avoid the influence of batched loading optimization.

Views have no set width or height, and the text font is small. The views are divided into 50 rows, with 40 views per row, and each row is wrapped in an outer view.

That is, a total of 4050 elements, including 2050 views and 2000 texts.

Comparison of creation speed is conducted between uni-app x Steam Mode, Android Native View, and Compose UI.

Download the hello uni-app x and the native 4050 sample applications on a computer beforehand.

• hello uni-app x download address: http://hellouniappx.dcloud.net.cn
• Native 4050 sample application download address: https://gitcode.com/dcloud/test4050-android. The nativeApp-release.apk in this git repository is the compiled APK.

hello uni-app x includes data for both flattened and non-flattened layouts. The native sample includes two rendering approaches: View and Compose UI.

Video Experience

First, an intuitive comparison through video.

1. Left side is Android Native View, right side is uni-app x Steam Mode.

Watch the high-definition video on Bilibili, 4050 - Android View VS uni-app x Steam Flattened

The time consumed is displayed at the top of the interface, in ms. Android Native View is 505ms, uni-app x Steam Mode is 273ms.

Timing explanation:

• Start time is the trigger time of the button's click event.
• End time is the time when all main thread rendering instructions have been delivered to the OS rendering process. At this point, the main thread has completed the work required for this rendering and is in an idle state.

1. Left side is Android Native View, right side is uni-app x Steam Mode non-flattened.

Watch the high-definition video on Bilibili, 4050 - Android View VS uni-app x Steam Non-flattened

Some developers worry that uni-app x might be slower than native when not flattened. The video above shows Android Native View at 508ms and uni-app x Steam Mode non-flattened at 360ms. In developer options, you can set "Show layout bounds" as a shortcut in the notification drawer. The video shows that after displaying layout bounds, 4050 real elements were indeed created, without flattening.

1. Left side is Compose UI, right side is uni-app x Steam Mode.

Watch the high-definition video on Bilibili, 4050 - Compose UI VS uni-app x Steam Flattened

Compose UI and uni-app x are both declarative in style, but Compose UI ranks last in creation and rendering speed. The video above shows Compose UI at 706ms and uni-app x Steam Mode at 287ms.

After the video comparison, detailed test data is provided below. Due to Android's idle-time optimization strategy, the execution speed of an application differs between first-time installation and subsequent use. They need to be listed separately.

First-Time Installation Performance Test Data

After restarting the device, without launching any software, first install hello uni-app x onto the phone via ADB.

Launch hello uni-app x, enter the Template tab -> view and text performance test.

1. First, test the flattened time consumption data. Click the display button and observe the rendering time.

This experiment is repeated 5 times. Each time, the app process is killed before re-entering. Killing the process and retesting is to avoid interference caused by JIT optimization. If a button is repeatedly clicked within an app's lifecycle, it may hit JIT optimization. Since the timing of this hit is uncontrollable, the app process must be killed and re-entered each time. Compilation optimization will be tested separately later.

5 times consumed: 287 273 276 276 280. Average: 278.4ms.

1. Then, test the non-flattened data. This experiment is repeated 5 times. Each time, the app process is killed before re-entering.

5 times consumed: 316 325 320 324 360. Average: 329ms.

1. Then restart the phone, without launching any software, install the native 4050 sample onto the phone via ADB.

Launch the native 4050 sample, first test the View time consumption. This experiment is repeated 5 times. Each time, the app process is killed before re-entering.

5 times consumed: 460 480 466 505 508. Average: 483.8ms.

Then launch the native 4050 sample, test the Compose UI time consumption. This experiment is repeated 5 times. Each time, the app process is killed before re-entering.

5 times consumed: 706 628 639 616 631. Average: 644ms.

Reiterate, during the above testing process:

• If the battery level drops below 90%, stop testing and resume after recharging.
• If the phone becomes hot, stop testing and resume after it returns to normal temperature.
• Observe Perfetto data; any data that becomes faster due to occasional OS scheduling onto the prime core is discarded.

The following is a screenshot from Google Perfetto. CPU7 is the prime core. It can be seen that the prime core is basically not working; only such data can be used.

Once the prime core is invoked, uni-app x data would be in the tens of ms, and native would be in the 100+ ms range. But this situation is unstable and unsuitable for a rigorous benchmark comparison.

Summary, first-time installation performance comparison table:

Technical Solution	5-Run Average Time (ms)	Memory Increase (KB)
uni-app x	278.4	48,868
uni-app x Non-flat	329	59,588
Native View	483.8	78,676
Native Compose	644	123,693

The unit for the above data is ms for time and KB for memory.

Memory increase refers to the difference between the application memory displayed by ADB after rendering the 4050 views+texts and the application memory displayed by ADB before rendering. It represents how much the application memory increased after rendering these elements.

Performance Comparison After Idle-Time Optimization

On Android phones, after an app is installed and used, the system tracks hot code, generates profile files, and performs pre-compilation machine code optimization based on the profile files.

Generally, AOT pre-compilation optimization is performed on apps when the phone is charging at night. Therefore, many apps feel slightly faster when used the next day.

This is the normal usage scenario for phone users, so performance comparison under these conditions must be tested.

However, during testing, there is no need to wait until the next day. For precise testing, and without relying on profile files, AOT pre-compilation can be manually triggered using the following commands:

adb shell cmd package compile -m speed -f io.dcloud.hellouniappx
adb shell cmd package compile -m speed -f io.dcloud.test4050

The above ADB commands optimize uni-app x Steam Mode and the native application respectively. Then restart the phone and test again. The test precautions are the same as the previous step, including monitoring battery level, heat, and Perfetto data.

Summary, performance comparison table after idle-time optimization:

Technical Solution	5-Run Average Time (ms)	Memory Increase (KB)
uni-app x	229.2	41,642
uni-app x Non-flat	276.2	55,494
Android View	461.8	78,760.8
Compose UI	625.8	124,145

Test Conclusion

The above data has multiple dimensions: first-time installation, idle-time optimization; uni-app x Steam Mode also has flattened and non-flattened modes. But regardless of the dimension, uni-app x Steam Mode is faster than both Android Native View and Compose UI.

Normal uni-app x development should use flattened mode, and daily phone users use the idle-time optimized version. If calculated based on this more universal dimension:

• uni-app x is 2 times faster than Android Native View (461.8/229.2)
• uni-app x is 2.73 times faster than Android Compose UI (625.8/229.2)

Reproduction Project Source Code and Experience Method

Source code for the above two examples:

• Android native example source code: https://gitcode.com/dcloud/test4050-android
• uni-app x source code: https://gitcode.com/dcloud/hello-uni-app-x/blob/alpha/pages/template/4050/4050.uvue

uni-app x Steam Mode can be compiled and run in HBuilderX version 5.23 or above (note: choose release mode to run, or publish as a formal package for installation).

You can also directly install the hello uni-app x example.

After installing hello uni-app x, click the Template tab at the bottom right -> view and text performance test at the top.

As a general-purpose engine, uni-app x has not made any custom optimizations for this example, and there are no behaviors such as preloading, pre-measurement, or forced invocation of large cores that would affect the fairness of the experiment.

Long List Frame Drop Test

The status of the list component in a rendering engine is second only to view and text.

Modern rendering engines all use recycling technology to implement long lists, ensuring that memory does not continuously grow after sustained scrolling of a long list.

Long lists using recycling technology enter quickly because only a portion of the data is loaded. However, the difficulty lies in not dropping frames during fast scrolling. When continuously loading data and reusing existing views, if the list is complex, it is difficult to complete rendering within one frame, which causes frame drops or white screens.

Test Method

Design a very complex "deadly long list":

• Load 4000 rows of data, 7.4M JSON
• Each row has over 40+ elements, including text, images, videos, and custom Vue components
• Each row has a nesting depth of 10+ layers
• The list renders a total of 20,000 elements, occupying approximately 1333 screens on an ordinary phone
• The list also contains a large number of complex rendering styles such as shadows, rounded corners, and borders

On the Android platform, frame drops can be visually observed by opening the HWUI rendering profile bar chart in developer tools. The frame rate can also be obtained via ADB commands.

The code for the deadly long list also needs to be implemented using the same logic in Android View and Compose UI. Android View uses RecyclerView. Compose UI uses Lazy series components.

Ensure the phone has 120Hz high refresh rate enabled. On two devices, enter the long list respectively, hold the slider on the right and drag up and down, quickly reaching the bottom of the list and then returning to the top.

Screen Recording Comparison

First, look at the screen recording comparison.

1. Left side is Native Android RecyclerView, right side is uni-app x Steam Mode

Watch the high-definition video on Bilibili, Deadly Long List - Android View VS uni-app x Steam Mode

1. Left side is Native Compose UI, right side is uni-app x Steam Mode

Watch the high-definition video on Bilibili, Deadly Long List - Compose UI VS uni-app x Steam Mode

In the above two videos, it can be clearly seen that:

1. For Native View and Compose UI, the bar chart during scrolling is so high it occupies most of the screen, with significant frame drops almost every frame. Meanwhile, the long list of uni-app x Steam Mode is stable, with very few dropped frames.
2. For Native View and Compose UI, there are many gray blocks during scrolling, and images and videos cannot all be displayed. The long list of uni-app x Steam Mode can display images and video covers normally.

Although the gap is already visible to the naked eye, data is still needed to measure how many times the gap is.

When testing data, close the HWUI rendering profile bar chart and extract the average frame rate data during scrolling via ADB, avoiding the beginning and end.

After each test, kill the process and restart the App before the next round of testing.

Take an average after 5 tests.

We also distinguish between two sets of data: first-time installation and idle-time optimization.

First-Time Installation Data

Technical Solution	Average Frame Rate (5-run averages in parentheses)
Native View	42.148 (43.1 41.93 41.29 42.58 41.84)
Compose UI	50.674 (48.89 53.91 52.71 50.4 47.46)
uni-app x Steam	101.7 (102.37 107.71 102.67 93.46 102.61)

Idle-Time Optimized Data

The AOT optimization command for the native deadly long list is: adb shell cmd package compile -m speed -f com.example.androiddeadlylist

Technical Solution	Average Frame Rate (5-run averages in parentheses)
Native View AOT	45.35 (44.97 44.31 45.53 44.51 43.9)
Compose UI AOT	51.094 (49.96 52.2 48.93 51.68 52.7)
uni-app x Steam AOT	109 (112.33 110.89 106.7 108.69 106.43)

In this scenario, the effect of idle-time optimization is not obvious. The main reason is the Android system's JIT optimization. Within a few hundred milliseconds after dragging starts, the system has already identified this code as hot code and performed JIT compilation optimization.

Test Conclusion

Conclusion: In the long list frame rate test, the average frame rate of uni-app x Steam Mode is 2.4 times that of Native View (109/45.35), and 2.13 times that of Compose UI (109/51.094).

Reproduction Project Source Code and Experience Method

Source code for the above two examples:

• Native version deadly long list source code: https://gitcode.com/dcloud/AndroidDeadlyList
• uni-app x version source code: https://gitcode.com/dcloud/hello-uni-app-x/blob/alpha/pages/template/long-list-perf/long-list-perf.uvue

The native version project directory contains a compiled APK, which can be directly installed for experience, or you can compile the source code yourself.

uni-app x Steam Mode can be compiled and run in HBuilderX version 5.23+ or above (note: publish as a formal package for installation testing, do not use real-machine debugging to test performance). You can also scan the QR code below to get the compiled hello uni-app x sample application:

After installing hello uni-app x, click the Template tab at the bottom right -> Deadly Long List at the top.

As a general-purpose engine, uni-app x has not made any custom optimizations for this example, and there are no behaviors such as preloading, pre-measurement, or forced binding to large cores that would affect the experimental results.

Other Components

A rendering engine, besides view, text, and list, also needs more high-performance components.

uni-app x has conducted extreme performance tests for various components, but due to limited effort, test cases for iOS native components were not developed for performance comparison.

Therefore, the following components have no native comparison data, only data for uni-app x Steam Mode.

Developers can experience the performance tests of various components in hello uni-app x. Almost every component example separately provides a component performance test.

• rich-text component: The rich-text component is very important, whether for news, UGC content, or AI-outputted markdown rich text, including tables and code highlighting. There has been no good solution for these on the App platform in the past. Most developers could only endure the slow initialization, high memory usage, and white screen during fast scrolling of webviews. uni-app x Steam Mode provides what is likely the industry's current best rich-text component.

  The following test loads a 50,000-character long article with one rich-text component, including 59 illustrations. It can be seen that:

  1. Enter the page with no waiting.
  2. Fast scrolling up and down has no frame drops or white screens; everything is rendered instantly.
  3. The speed of loading images over the network for the first time is affected by network speed. Upon re-entry, local cache is used, making it faster.

  Watch the high-definition video on Bilibili, uni-app x High-Performance Demo - rich-text 50k-word long article [Android Platform]

• swiper component: The image preview interface opened by clicking an image in the above 50,000-character long article is implemented using the swiper component. It can be seen that the swiper presents 59 images without waiting, and switching images left and right has no delay. Many single-metric improvements can be achieved by sacrificing other metrics. For example, lazy loading at startup makes startup fast, but immediate switching will still be slow. Being fast at both startup and switching, without preloading, is truly good performance.

• canvas component: The canvas performance of uni-app x Steam Mode is significantly improved. There are 20,000 small balls on the screen simultaneously performing edge collision without dropping frames.

  Watch the high-definition video on Bilibili, uni-app x High-Performance Demo - canvas [Android Platform]

  Native does not have a canvas component that conforms to web standards, so we compared the performance of browsers, mini-programs, and React Native on the same phone, Xiaomi Fold4.

• Browser, Edge 150, running the web version of the same page. First, the browser can only run at a maximum of 60 frames on this device, and with 20,000 balls, it was already in the 50+ fps range.

• WeChat Mini Program, running the WeChat Mini Program version of the same page, can only run at a maximum of 60 frames. At 2,000 balls, it started to drop to 50+ fps.

• React Native Skia OpenGL backend, running the same example, dropped below 120fps at 900 balls, and below 60fps at 2,000 balls. The Vulkan backend showed a black screen on the Xiaomi Fold4.

To supplement the React Native Skia Vulkan data, we found another device for testing.

Test Device - iQOO Z3 Android 13

Technology	<120fps Ball Count	<60fps Ball Count
System Browser (Chrome 130)	2.6k	9.7k
RN Skia OpenGL	0.97k	1.4k
RN Skia Vulkan	1.5k	5.6k
uni-app x Steam	16.6k	31.6k

It can be seen that the canvas component of uni-app x Steam Mode has a fault-level leading advantage.

• picker component: Loads 4000 rows of province/city/district data. The component pops up without waiting; there is no preloading, and data is loaded and rendered only when the picker is clicked.

• loading component:

  The loading component of uni-app x on the Android platform does not occupy the main thread at all. No matter how intensive the computation on the main thread is, the loading spinner can still rotate smoothly without lag.

  The following video shows 100 loadings rotating simultaneously on the screen while text on the main thread continuously updates without dropping frames.

  Watch the high-definition video on Bilibili, uni-app x High-Performance Demo - loading component [Android Platform]

• The hello uni-app x template also provides performance test examples such as a calendar, vertical swipe video, long list with swipe-to-delete, and AI chat streaming typewriter.

  Watch high-definition videos on Bilibili:

  • uni-app x High-Performance Demo - Calendar Component [Android Platform]
  • uni-app x High-Performance Demo - Vertical Swipe Video [Android Platform]
  • uni-app x High-Performance Demo - Long List Swipe-to-Delete [Android Platform]
  • uni-app x High-Performance Demo - AI Chat Streaming Typewriter [Android Platform]

In the AI era, many Apps need to embed an open-source AI dialogue chat library that can stream-parse markdown without dropping frames during parsing. For this purpose, DCloud launched the open-source uni-ai x, see https://ext.dcloud.net.cn/plugin?id=23902

No user likes waiting, and no user likes lag and frame drops.

Since the iPhone's release in 2007, for decades, mobile phone users have had to wait 300ms for every page transition daily. uni-app x will support significantly shortening this time. In the Steam Mode of hello uni-app x, it has been changed to 150ms by default, with this 150ms mostly reserved for the network.

If developers use emerging network technologies like h3 and optimize server speed well, the waiting time can be shortened even further.

FAQ

Is the App platform of uni-app x self-rendering or native rendering?

It is native rendering. To be precise, it builds almost all components itself on the native rendering pipeline.

If self-rendering were used, the coexistence of two rendering pipelines would consume additional hardware resources. Initialization would be slow, and memory usage would be high.

Moreover, the native ecosystem has developed over many years, with many third-party component SDKs, such as maps, live streaming, and ads. Self-rendering solutions encounter many problems when integrating with the native ecosystem. Fusing two rendering pipelines within the same page, scroll synchronization, and resource consumption all indicate that this route is not the best solution.

From a macro perspective, optimizing within the native rendering pipeline, providing faster core components, and being compatible with all native components is more meaningful for the industry than establishing a separate rendering system.

Why is uni-app x Steam Mode faster than native rendering when both are native rendering?

This involves thousands of engineering optimizations. Some examples:

1. Android's Compose UI is also based on the native rendering pipeline, but it does not use Android's built-in View or TextView; instead, it implements its own component system.

   This path is viable, but Compose UI has not become a good benchmark; its actual rendering speed is slower than the View system.

   uni-app x Steam Mode also barely uses the system's built-in components, whether TextView, RecyclerView, ViewPager... basically none are used. The newly developed components achieve higher performance.

2. The code in Vue's template and style is directly compiled into highly optimized machine code/bytecode. Its running speed is much faster than Java or Kotlin.

In the AI era, is cross-platform still significant?

Improving production efficiency is an unchanging trend in social development. Both AI and cross-platform are important means to promote production efficiency.

However, if AI is used to generate multi-platform code, then AI is not a stable public abstraction. If you practice it, you will find that except for the first sentence sent to AI, which can be reused across platforms, every subsequent problem needs to be handled per platform. It is difficult to create a commercial-grade application without professional platform knowledge.

Improving performance is an unchanging trend in user experience development. Page transitions changing from 300ms waiting to 150ms, and every interaction being silky smooth without frame drops, are important reasons for users to choose one App or abandon another. Using uni-app x, you can achieve higher performance than native. This statement used to be the opposite, but times have changed.

Additionally, welcome to follow uni-agent. It understands uni-app series products better than any AI Coding tool and can help developers better use AI to generate code for uni-app x, uniCloud, and other products.

Being both cross-platform and having higher performance than native was once considered a fantasy.

DCloud has always treated this fantasy as a dream and persistently pursued it, launching uni-app x in 2023 and Steam Mode in 2026. Years of unremitting pursuit of this dream have turned what others saw as fantasy into reality.

In the future, uni-app x will have more important updates, including App hot updates (a dynamic solution with better performance than native), a higher-performance cross-language communication mechanism, UASM assembly capabilities available on all platforms, and cooler built-in special effects.

Keep moving forward!