¿Cómo renderiza Flutter la UI sin un bridge, y en qué se compila realmente el árbol de widgets?

Esta pregunta busca ver si el candidato entiende de verdad el modelo de renderizado de Flutter o si sólo sabe que "se ve igual en ambas plataformas". La respuesta honesta y diferenciadora es que Flutter no usa widgets de UI nativos en absoluto — nada de UIView, nada de android.view.View para la UI de tu app — y esa decisión es la razón por la que Flutter no necesita ningún bridge para empezar. No hay nada a lo cual hacerle de puente, porque Flutter dibuja cada píxel por sí mismo.

#Dart compila a código nativo, y el engine es dueño del canvas

En modo release, Dart se compila ahead-of-time (AOT) directamente a código máquina ARM/x64 — no se interpreta en runtime como el viejo modelo de bridge necesitaba que JS lo fuera. En modo debug corre en cambio just-in-time (JIT), y eso es lo que hace posible el hot reload: la Dart VM en ejecución puede reemplazar código compilado nuevo sin reiniciar la app. En cualquiera de los dos casos, tu código de widgets corre como código nativo que llama directamente al engine de Flutter, un runtime en C++ embebido en la app. El engine, a su vez, entrega comandos de dibujo a un backend gráfico — Skia históricamente, y cada vez más Impeller, el backend de renderizado más nuevo de Flutter que precompila shaders de antemano para evitar el jank por compilación de shaders en runtime al que Skia era propenso en el primer paint. Cualquiera de los dos backends habla directamente con la GPU. El código nativo de la plataforma sólo entra en escena para cosas que Flutter no dibuja por sí mismo: acceso a la cámara, Bluetooth, SDKs nativos — cualquier cosa que necesite un platform channel.

#Tres árboles, no uno

La parte que casi todos olvidan mencionar: lo que escribís no es directamente lo que se dibuja. Flutter mantiene tres árboles paralelos. El árbol de widgets es lo que devuelven tus métodos build() — inmutable, barato, y completamente reconstruido en cada frame que lo toca. El árbol de elementos es la estructura persistente que en realidad maneja el estado y hace la reconciliación: en cada reconstrucción, Flutter compara el widget nuevo contra el widget del elemento anterior (por tipo en runtime y por key) y actualiza el elemento existente en el lugar o lo destruye y crea uno nuevo. El árbol de RenderObjects es el que realmente ejecuta el layout (en general una sola pasada, calculando tamaño y posición) y el paint (convirtiendo los resultados del layout en una lista de comandos que se entrega al engine).

Por eso los constructores const importan para el rendimiento, no sólo por estilo: un widget const es una constante en tiempo de compilación, así que al reconstruir Flutter puede saltarse hasta el diff — es demostrablemente la misma instancia. También es la razón por la que las keys importan al reordenar una lista de widgets con estado: sin una key que coincida, el diffing de elementos de Flutter empareja por posición y tipo, y puede reutilizar incorrectamente un elemento (y su estado) para lo que conceptualmente es un ítem distinto.

class ProductCard extends StatelessWidget {
  const ProductCard({super.key, required this.title, required this.price});

  final String title;
  final double price;

  @override
  Widget build(BuildContext context) {
    return Card(
      child: Padding(
        padding: const EdgeInsets.all(12),
        child: Column(
          crossAxisAlignment: CrossAxisAlignment.start,
          children: [
            Text(title, style: Theme.of(context).textTheme.titleMedium),
            const SizedBox(height: 4),
            Text('\$${price.toStringAsFixed(2)}'),
          ],
        ),
      ),
    );
  }
}

#Las reconstrucciones tienen alcance acotado, no global

Llamar a setState en un objeto State programa una reconstrucción sólo del subárbol de ese widget — no de toda la app. Flutter recorre hacia abajo desde el elemento marcado como sucio, reconstruye widgets, compara cada uno contra su elemento existente, y sólo los RenderObjects cuyo layout o paint realmente cambiaron hacen trabajo nuevo. Esto es conceptualmente cercano a la reconciliación de React (una descripción inmutable comparada contra un árbol persistente), pero no hay un paso separado de "confirmar al DOM" con sus propias rarezas de programación asíncrona — los árboles de Elements y RenderObjects ya son las estructuras retenidas y mutables desde las que el engine pinta.

class Counter extends StatefulWidget {
  const Counter({super.key});

  @override
  State<Counter> createState() => _CounterState();
}

class _CounterState extends State<Counter> {
  int _count = 0;

  void _increment() => setState(() => _count++);

  @override
  Widget build(BuildContext context) {
    return Row(
      children: [
        Text('$_count'),
        IconButton(onPressed: _increment, icon: const Icon(Icons.add)),
      ],
    );
  }
}

#Dónde sigue apareciendo el código nativo: platform channels

Para todo lo que Flutter no puede o no debería reimplementar por su cuenta — nivel de batería, SDKs nativos, diálogos de permisos específicos de la plataforma — Dart le habla al código nativo a través de un MethodChannel, un límite de paso de mensajes explícito y con nombre, que se usa con moderación, no en cada frame:

class BatteryService {
  static const _channel = MethodChannel('com.example.app/battery');

  Future<int> getBatteryLevel() async {
    final level = await _channel.invokeMethod<int>('getBatteryLevel');
    return level ?? -1;
  }
}