Flutter vs React Native vs Weex vs H5: Architecture, Performance, and Optimization

Introduction

The article analyzes common cross‑platform technologies—Flutter, React Native, Weex, and H5—by comparing their technical characteristics, basic architecture, compilation principles, and rendering processes, then discusses typical performance problems and how to optimize them, and finally provides a logical framework for technology selection during business development.

Background

With the proliferation of platforms such as Android, iOS, macOS, Windows, Web, Fuchsia OS, and HarmonyOS, businesses face increasing demands for multi‑platform support. Developers often encounter issues like UI inconsistencies across devices and duplicated effort when implementing the same feature on multiple platforms.

Four Technology Stack Characteristics

Figure 1 (not shown) summarizes each stack’s performance, programming language, rendering engine, package size, community support, and target platforms, raising questions about why native and Flutter perform better, why React Native and Weex are slower, and why H5 pages load slowly.

Flutter Architecture

Flutter consists of a Dart‑based Framework layer (widgets, animation, gesture handling, etc.) and a C++/C‑based Engine layer that includes the Skia rendering engine, Dart runtime, and text rendering. The Engine provides a unified Skia renderer for all platforms, enabling high performance without a bridge. Flutter also supports macOS, Windows, Linux, and Web, and its code is AOT‑compiled to native binaries.

React Native Architecture

React Native (open‑sourced by Facebook in 2015) runs JavaScript code on a JS engine, uses a virtual DOM, and communicates with native UI via a bridge. The native side renders UI, handles network requests, and performs animations. Recent versions improve the threading model, introduce asynchronous rendering, and simplify the JS bridge.

Weex Architecture

Weex (released by Alibaba in 2016) compiles source code to a JavaScript bundle that can be deployed on a server. At runtime, a V8‑based JS engine creates a virtual DOM, which is bridged to native controls for rendering. Weex is built on Vue and supports Android, iOS, and Web.

WebView (H5) Architecture

WebView uses the Chromium/WebKit stack: a bridge layer for JS‑Native communication, WebCore for parsing HTML/CSS and layout, JavaScriptCore/V8 for script execution, and platform‑specific ports for networking, fonts, media, and hardware acceleration. The OS provides the underlying support.

Compilation Principles

Flutter supports Release (AOT‑compiled native code), Profile (AOT with performance tooling), and Debug (JIT with hot‑reload). Release mode generates App.framework and Flutter.framework for iOS and libapp.so / libflutter.so for Android. Profile mode adds DevTools support, while Debug mode enables JIT, hot‑reload, and extensive debugging utilities.

Basic Rendering Process Comparison

Figure 6 (not shown) compares rendering pipelines:

Native Android/iOS: UI logic → layout → system rendering engine.

Flutter: UI logic → Skia rendering engine (no native bridge).

React Native / Weex: JS bundle → virtual DOM → bridge → native controls → native rendering.

Hybrid (WebView): HTML/JS/CSS → WebView initialization → resource loading → layout → rendering engine.

Common Performance Issues and Optimizations

4.1 Optimizing Flutter Performance

Key metrics: page exception rate, FPS, and load time. Use runZoned and FlutterError to count exceptions, register onReportTimings on window to calculate FPS, and capture visible time via WidgetsBinding.addPostFrameCallback and initState. Upload metrics to monitoring platforms (e.g., mPaaS, ZhuLong) and use DevTools, Flutter Inspector, lazy loading, and partial refresh for further gains.

4.2 Optimizing React Native Load Time

Pre‑download or pre‑bundle JS bundles to reduce startup latency, and upgrade to the latest React Native version, which introduces an improved threading model, asynchronous rendering, and a faster JS bridge.

4.3 Optimizing H5 Load Time

Accelerate WebView initialization and resource loading by using offline packages or pre‑loading HTML, JS, CSS, and images, thereby cutting network latency and achieving near‑instant page display.

Conclusion and Technology Selection Guidance

When choosing a stack, prioritize development efficiency and user experience. Evaluate factors such as architectural soundness, future‑proofing, team maturity, community support, code reuse potential, UI consistency across devices, dynamic update capability, and end‑user environment constraints. For large‑scale consumer apps, the goal is to reduce cost while maximizing user satisfaction; for internal tools, the balance may shift toward rapid iteration.