What a platform view actually costs you

#Two renderers, one screen

Flutter composites its own scene on a GPU surface. A platform view asks the host to draw a separate surface, then asks the compositor to interleave the two. Both are drawing at sixty frames per second, and neither is waiting for the other.

On Android in 2019 there were two mechanisms for this, and they had very different costs. The virtual display approach rendered the native view into an off-screen texture, which composited correctly but added a copy per frame and broke certain input paths. The hybrid composition approach put the native view in the real view hierarchy, which was cheaper for the native side and forced Flutter to move some of its own rendering onto the platform thread.

#What I measured

On a mid-range device from that period, running a modest Unity scene at 60 fps inside a Flutter app:

• Memory climbed by roughly the resident size of the Unity player plus the scene assets. The engine does not share an allocator with Dart, so nothing is pooled between them.
• Startup gained around a second and a half, most of it Unity initialising rather than the platform view being created.
• Scrolling a Flutter list that contained the engine view was visibly worse than scrolling the same list without it, because the compositor now had two surfaces to keep in step.

None of those are defects. They are what a second renderer costs, and the useful thing is to know the number before you design a screen around it.

#Design consequences

The measurements pushed the design in three directions.

Keep the engine view large and stationary. A full-screen or near-full-screen surface that does not move avoids the worst compositing cases. Putting an engine view inside a scrolling list works, and it looks bad.

Do not create and destroy the engine repeatedly. Initialisation dominates, so a screen the user enters and leaves several times should keep the player alive and paused rather than tearing it down.

Move the interface into Flutter. Anything that can be a native control should be one. Text rendered in Unity looks wrong next to text rendered by Flutter, it does not respond to accessibility settings, and it costs engine frames to draw.

#What I would tell someone starting now

The integration is worth it when the 3D content is the point of the screen. It is not worth it for a decorative element, because the fixed cost does not scale down. A spinning logo does not need a game engine, and putting one behind a spinning logo will show up in the memory profile of every user's device.

The repository documents the current mechanism for each platform [1]. Read that before designing the screen rather than after.