-
Notifications
You must be signed in to change notification settings - Fork 28.9k
Improve performance of build APK (~50%) by running gen_snapshot concurrently #44534
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
packages/flutter_tools/lib/src/build_system/file_hash_store.dart
Outdated
Show resolved
Hide resolved
extraFrontEndOptions extraFrontEndOptionsValue | ||
extraGenSnapshotOptions extraGenSnapshotOptionsValue | ||
} | ||
String taskName = toCammelCase(["compile", FLUTTER_BUILD_PREFIX, variant.name]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of creating a task per ABI, I create a single task which builds all of the requested ABIs. This allows assemble to run concurrent gen_snapshots
@@ -729,23 +733,15 @@ abstract class BaseFlutterTask extends DefaultTask { | |||
args "--depfile", "${intermediateDir}/flutter_build.d" | |||
args "--output", "${intermediateDir}" | |||
args "-dTargetFile=${targetPath}" | |||
args "-dTargetPlatform=${targetPlatform}" | |||
args "-dTargetPlatform=TargetPlatform.android" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the target platform is extracted from the target name, then why is this needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
KernelSnapshot requires a target platform per your fuchsia changes. We could loosen that restriction a bit by making a missing platform default to non-fuchsia
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'd also still need it if we wanted to do platform specific assets at some point
if (buildMode == "debug") { | ||
ruleNames = ["debug_android_application"] | ||
} else { | ||
ruleNames = targetPlatformValues.collect({ targetPlatform -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit:
ruleNames = targetPlatformValues.collect { "android_aot_bundle_${buildMode}_$it" }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
include "app.so" | ||
targetPlatformValues.each { | ||
String abi = PLATFORM_ARCH_MAP[targetArch] | ||
include "${abi}/app.so" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit:
include "${PLATFORM_ARCH_MAP[targetArch]}/app.so"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
@@ -306,6 +307,7 @@ String getNameForHostPlatform(HostPlatform platform) { | |||
} | |||
|
|||
enum TargetPlatform { | |||
android, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe add comment about what the difference is between android
, android_arm
and so on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should probably just have android
right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a comment on the usage of android vs android w/ arch. Refactoring this is similar to the iOS refactoring
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sg
|
||
@override | ||
List<Source> get inputs => <Source>[ | ||
const Source.pattern('{FLUTTER_ROOT}/packages/flutter_tools/lib/src/build_system/targets/dart.dart'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
q: why is this one part of the inputs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sort of a work around to allow running from source to handle source file changes to the tool. It doesn't add much/any overhead to the build so it is okay to leave in.
@@ -216,12 +216,12 @@ Future<void> main() async { | |||
} | |||
|
|||
final String analyticsOutput = analyticsOutputFile.readAsStringSync(); | |||
if (!analyticsOutput.contains('cd24: android-arm64') | |||
if (!analyticsOutput.contains('cd24: TargetPlatform.android') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the real target architecture communicated in some other way to analytics?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If not, we should figure out a way to retain that so we can understand our analytics across this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be part of the build apk/appbundle/aar commands:
@blasten can you provide some additional context on why we send this second analytics call? Its for the add2app tracking, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is critical, but cc'ing @xster to confirm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ultranit: not having the enum 'outer class' name in there would be nice as a bonus.
https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/commands/build_apk.dart#L58 that you're linking to is orthogonal to this right? This is to detect top level calls to flutter build bundles
from add-to-app scripts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the dashboard to monitor is https://dashboards.corp.google.com/_8211ecd6_e372_4f1c_b4f8_a1f4f0411822#xhaf6f3g0
The post update APK size is 43.5MB whereas it used to be 53.5MB. Do you know why it decreased in size? |
I get 53.6MB building flutter gallery locally. Which app were you building? |
Followed up offline: the logs were from a version that still had a bug in the app.so include logic. The latest commits build correctly |
YOLO |
This introduced #46163 |
Description
Support concurrent build via flutter assemble. Compared to current master, a release build of an APK for target platforms android-arm, android-arm64, and android-x64 takes ~60 seconds, down from ~140 seconds tested on my local macOS laptop.
Adds TargetPlatform.android enum. Longer-term, usage of TargetPlatform should be updated to remove arch specific flavors, these can be expressed with AndroidArch
Updated logs: https://gist.github.com/jonahwilliams/24aa5cf2544fd46e36a9b69a78d26ff4