跪拜 Guibai
← All articles
Flutter · Performance Optimization · Android

Flutter 3.44's HCPP Eliminates the Performance Tax on Android Platform Views

By GitLqr ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

For any Flutter app that embeds maps, video players, or WebViews on Android, HCPP removes the long-standing choice between janky scrolling and broken text selection. It makes a single, high-quality platform view implementation viable for the first time, provided the device runs Android 14 or newer.

Summary

Embedding native views like Google Maps or WebView in Flutter has always forced a trade-off: Virtual Display runs fast but breaks interaction, while Hybrid Composition fixes interaction at a steep frame-rate cost. HCPP sidesteps the old pixel-merging bottleneck entirely. Instead of copying GPU textures between Flutter's render thread and the Android main thread, it hands two independent Surfaces to the OS compositor, SurfaceFlinger, which layers them in hardware.

The result is a single approach that delivers both high rendering performance and full native interaction. The catch is a hard dependency on Android 14 or later, Vulkan graphics support, and Flutter's Impeller engine. On older devices, the engine silently falls back to the existing TLHC mode, so a single code path covers both new and old hardware.

Enabling HCPP requires a manifest flag, using PlatformViewLink with AndroidViewSurface on the Dart side, and running with the --enable-hcpp flag in profile mode. The feature is still opt-in but marks a significant step toward making Flutter's Android embedding feel truly native.

Takeaways
Virtual Display renders fast but breaks keyboard focus, text selection, and accessibility because the OS does not know the native view exists.
Hybrid Composition fixes interaction but forces expensive thread synchronization and pixel copying between Flutter's render thread and the Android main thread, causing frame drops.
TLHC, the previous compromise, uses SurfaceTexture to reduce the overhead but still stutters and tears during fast scrolling.
HCPP avoids pixel merging entirely by submitting separate Flutter and native Surfaces to SurfaceFlinger for hardware-level composition.
The hard requirements are Android 14 (API 34) or higher, Vulkan support, and Flutter's Impeller rendering engine.
Enabling HCPP requires an io.flutter.embedding.android.EnableHcpp meta-data flag in AndroidManifest.xml and using PlatformViewLink with AndroidViewSurface in Dart.
Running a profile build with the --enable-hcpp flag is necessary to test the feature on a real device.
On unsupported devices, the engine automatically falls back to TLHC, so developers write one code path.
Conclusions

The fallback to TLHC is the feature's most practical design choice: it removes the risk of fragmentation that would otherwise make developers hesitant to adopt a mode tied to Android 14.

HCPP's reliance on SurfaceFlinger means the performance win is not a Flutter optimization but a delegation to a system service that has been maturing since Android 10. Flutter is finally exploiting a capability the platform already had.

The requirement for Impeller and Vulkan ties HCPP's future to Flutter's broader rendering migration. Teams still on Skia or OpenGL get nothing from this, which may accelerate Impeller adoption on Android.

Concepts & terms
SurfaceFlinger
Android's system-level compositor that takes multiple graphics buffers (Surfaces) from different processes and combines them into a single frame for the display, operating at the hardware level.
Impeller
Flutter's next-generation rendering engine that uses Vulkan on Android to precompile shaders and avoid the runtime shader compilation jank common with the older Skia engine.
Rendering Tax
The performance overhead incurred when Hybrid Composition forces Flutter's raster thread and Android's main thread to synchronize and copy pixel data between GPU textures for every frame.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗