flutter/flutter
Tool data flow: argv -> executable.main -> FlutterCommandRunner (args package) -> FlutterCommand.verifyThenRun -> runCommand; all services resolve through an AppContext DI layer fed by globals.dart and the overrides map in executable.main. Runtime data flow: `flutter run` compiles Dart to kernel via ResidentCompiler, syncs sources+assets to the on-device DevFS over HTTP, and talks to the Dart VM service (vm_service package) for reload/attach; hot restart alternates a `.swap` dill name to dodge memory-mapped files. Framework data flow: runApp mounts the widget tree, drawFrame pumps build->layout->paint->composite into a Scene sent to the engine; MethodChannel calls serialize via codecs over BinaryMessenger into dart:ui's PlatformDispatcher.sendPlatformMessage, then through the engine's platform message handler to the embedder.
- Argument parsing is two-stage: findCommandName() in executable.dart does a throwaway parse to locate the command (handling -h/-? //? help idioms), then FlutterCommandRunner's real ArgParser (allowTrailingOptions: false) dispatches to the FlutterCommand.
- FlutterDevice.create() wires the per-device compile pipeline: a DevelopmentShaderCompiler wrapping ShaderCompiler for Impeller shaders, and a ResidentCompiler (via residentCompilerFactory) for incremental Dart kernel generation targeting device.targetPlatform.
- DevFS (devfs.dart) is the transport for hot development: it uploads compiled kernel files and asset diffs to a per-app filesystem served by the VM service on the device.
- HotRunner._reloadSources() orchestrates reload: projectFileInvalidator computes changed files, ResidentCompiler.recompile emits a partial dill, devFS pushes it, _reloadSourcesService calls VM reloadSources, then _reassembleHelper triggers WidgetsBinding reassemble in the app.
- Hot restart rewrites main.dart.dill into the device DevFS under alternating names (with/without .swap) because the previous dill may still be memory-mapped by the Windows embedder.
- The BuildSystem executes a Target DAG where each Target declares Source-pattern inputs/outputs; FileStore hashes file contents (md5/timestamp) and stamp files record inputs+outputs per run so unchanged targets are skipped; work is pooled at kMaxOpenFiles=64 concurrent file ops.
- App startup in the framework: runApp(app) -> WidgetsFlutterBinding.ensureInitialized() -> binding.wrapWithDefaultView(app) -> scheduleAttachRootWidget -> scheduleWarmUpFrame; frames then flow through handleBeginFrame/handleDrawFrame (documented 10-phase pipeline) -> drawFrame -> scene handed to the engine.
- Platform channel flow: MethodChannel._invokeMethod encodes calls with a MethodCodec, sends through binaryMessenger -> dart:ui PlatformDispatcher.sendPlatformMessage -> engine.cc's platform message handling -> the embedder's registered channel handler; built-in channels are named in engine.cc (flutter/assets, flutter/lifecycle, flutter/navigation, flutter/localization, flutter/settings, flutter/isolate).
- Tool persistent state lives in bin/cache plus user config: Config (flutter config settings), PersistentToolState, and unified_analytics telemetry gated by --disable-analytics/--enable-analytics/--suppress-analytics handled in runner.run before dispatch.
- Crash path: unhandled errors in the zone go to _handleToolErrorImpl -> CrashReportSender.sendReport (skipped when running on a bot or with --local-engine) and a local flutter_*.log file is written to the cwd (falling back to system temp) containing command, exception, stack, and `flutter doctor` output.
- The daemon protocol multiplexes IDE traffic: DaemonConnection parses [json] envelopes and optional binary streams, dispatches to Domain handlers registered with registerDomain() (app, device, emulator, devtools), and emits events back over stdout.