Xiaomi HyperOS 4 Bets on Flutter + Rust: Performance Gains vs. Maintenance Risks

The author examines Xiaomi's decision to adopt Flutter + Rust in HyperOS 4 for performance and memory optimization. The core argument centers on trade-offs between potential gains and long-term maintenance costs.

UI Layer: Flutter vs. Android Native

Android's native UI framework uses Kotlin/Java compiled to bytecode running on ART VM. After years of optimization, ART performs well except in corner cases: Java heap memory leaks, frequent GC under memory pressure, JIT overhead, and interpreter execution for some code paths.

Flutter uses Dart with AOT compilation but still requires Dart VM and GC-based memory management, introducing similar GC-related issues. The author highlights that ART VM receives continuous mainline optimization from Google, while Dart VM maintenance becomes Xiaomi's burden. Diverging from Android's architecture and system optimization mainline raises questions about whether the performance benefits justify the maintenance cost.

Additionally, the author notes binary compatibility and fragile base class problems make this approach impractical for the broader ecosystem, limiting benefits to Xiaomi's own apps.

Non-UI Layer: Rust for Safety and Stability

Using Rust for non-UI components (services, data processing) is more defensible. Compared to C++, Rust prevents memory safety issues. Android itself is rewriting many components in Rust, and Rust libraries are already present in system images without extra ROM cost.

Performance Gains Likely from Rewriting, Not Language Alone

The author argues Xiaomi's performance improvements stem primarily from rewriting legacy code and eliminating technical debt, not merely from language choice. As an example, the author's former gallery team achieved hundreds of megabytes of memory savings and startup time reductions through architecture and code optimization alone.

Trade-off Assessment

Any technology choice involves trade-offs. The upfront investment and ongoing maintenance costs for Flutter + Rust are substantial. The author, drawing on Ark Compiler experience, would not have chosen this path but acknowledges that exploration is necessary to discover real benefits and pitfalls.

UI Evolution and Language Requirements

The article traces UI development: from C on feature phones, to XML+interpreter (poor performance), to Android's XML+Java/Kotlin (better efficiency but layout-code separation), to modern declarative UI (Compose, SwiftUI, ArkUI, Flutter, React) with reactive, data-binding, immutable UI trees.

These UI paradigms require language support — mostly managed languages with VMs and GC (Java/Kotlin, Dart, JavaScript/TypeScript). Swift uses static compilation + reference counting, offering performance advantages but imposing constraints on language design, libraries, and developers, slightly reducing development velocity.

Android Optimization Directions

Google's recent Android performance work focuses on lock priority inversion fixes, key data structure optimization, VM GC (with side effects), and lower-level memory management. Vendors can prioritize technical debt cleanup, and AI-assisted rewriting lowers the cost of adopting Rust for selected components.