Split develop, deploy and profile builds for both iOS and Android in flutter tool

[eseidelGoogle]

• android flutter build/run --debug (JIT)
• android flutter build/run --profile (AOT)
• android flutter build/run --release (AOT)
• android, ensure that --profile and --release are not available for emulators (fail better when running --profile or --release against android emulators #4197)
• ios flutter build/run --debug (interpreter) (Need a development workflow for iOS Devices #2042)
• ios flutter build/run --profile (AOT)
• ios flutter build/run --release (AOT)
• ios, ensure that --profile and --release are not available for simulators (ensure that --profile and --release are not available for ios simulators #4200)
• modes accessible from atom (can choose which mode to run in) (How to configure release mode with Atom plugin? #4042)
• it's possible to take a screenshot from a simulator/emulator w/o the slow mode banner

more docs on the modes are here: https://github.com/flutter/flutter/wiki/Flutter's-modes

---

develop:

• very fast edit/refresh
• Checked mode is possible
• Interpreted or JITed (device vs. simulator, possible we'll want to use interpreter in both places when possible)
• Observatory enabled.

profile:

• Checked mode code removed
• Ahead of time compiled (AOTC) when possible
• Observatory enabled.

deploy:

• checked mode removed
• ATOC
• Observatory removed.

We don't have to actually make the configs different to begin with, but we do need to expose this difference in the flutter tool in order to make space for the backend work (like wiring in the Interpreter mode on iOS develop on devices).

@chinmaygarde @devoncarew

[sethladd]

This may be implied but develop mode enables fast edit/refresh cycles.

On Thu, Mar 3, 2016, 9:00 AM Eric Seidel notifications@github.com wrote:

develop:

• Checked mode is possible
• Interpreted or JITed (device vs. simulator, possible we'll want to
  use interpreter in both places when possible)
• Observatory enabled.

profile:

• Checked mode code removed
• Ahead of time compiled (AOTC) when possible
• Observatory enabled.

deploy:

• checked mode removed
• ATOC
• Observatory removed.

We don't have to actually make the configs different to begin with, but we
do need to expose this difference in the flutter tool in order to make
space for the backend work (like wiring in the Interpreter mode on iOS
develop on devices).

@chinmaygarde https://github.com/chinmaygarde @devoncarew
https://github.com/devoncarew

—
Reply to this email directly or view it on GitHub
#2366.

[devoncarew]

Is the profile build configuration necessary? deploy would work for profiling modulo the removal of the observatory.

This would mean we don't pass things like --checked into run (or build), we pass --deploy or --dev.

I'm going to assume that dev mode and deploy mode would likely load their assets (images and code) in different ways. Dev mode may be a shell we build with any native code, but where the dart code is sideloaded (and re-loaded). The deploy mode would AOT it all into one binary, deployable artifact.

[abarth]

Is the profile build configuration necessary?

The difference is whether to include observatory (binary size) and whether to have the sampling profiler running (battery). If you don't have a profiling build, you either need to pay the costs of the devtools/profiler in production or not be able to profile the production configuration.

[eseidelGoogle]

#2042 tracks the iOS build support necessary for this tooling.

[devoncarew]

The current names are develop, profile, and deploy. Do people have preferences re: renaming the modes, to either:

• debug, profile, deploy
• debug, profile, release

[devoncarew]

I'm working on a PR which would rename to debug, profile, deploy.

[Hixie]

Searching google for [debug release] and [debug deploy] suggests the first pair is more widely used.

[sethladd]

How close are we to closing this? Do we have a checklist of remaining items?

Two related items:

#3269 (build and upload gen_snapshot to darwin-x64)

#3827 (document the various modes)