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
build(android): include common bundle in snapshot #11054
Conversation
|
android/titanium/src/java/org/appcelerator/titanium/TiLaunchActivity.java
Outdated
Show resolved
Hide resolved
How does this affect build times? Tweaking performance is probably only relevant for production builds, but still interesting to test. |
android/titanium/src/java/org/appcelerator/titanium/TiLaunchActivity.java
Outdated
Show resolved
Hide resolved
We don't currently create snapshots for What we're currently doing for 8.1.0 is creating an empty snapshot. This has made V8 "cold startup" time about 2-3x faster. It's pretty significant. You've likely noticed it. With Gary's change, we're taking a snapshot of our rolled-up common "ti.main.js" code, which has gotten heftier since we're babel transpile/polyfilling it now. This improves the cold startup time and relaunch time. Gary's other PR #11058 further improves the startup time as well. Note that the newest Android OS versions have a much more aggressive battery optimizers, causing apps to be force quit more often while backgrounded. This makes improving our app cold startup time a high priority. |
@@ -133,6 +134,8 @@ public static void updateActivityTransitionState(boolean state) | |||
} | |||
} | |||
|
|||
public static long START_TIME_MS = 0; |
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.
NOTE: I'm putting this here so we can easily access the start time elsewhere in our SDK.
@sgtcoolguy @jquick-axway Updated PR |
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 think this general approach can be useful in that each platform would get only the set of polyfills/shims it needed. I'd tweak the SDK build logic to not have to produce the ios/android data and then just wipe it out of the object if it's a different platform.
Also, this presumably means we'd need to tweak the windows CLI code to point at common/Resources/windows like you do for Android/IOS here (Unless it's just all smart enough to pick up the platform-specific subfolder magically)
@garymathews Also, just a note that the work you've done on Android startup is awesome. Those timing numbers above are insane. I think the community is in for a real surprise between our app build time improvements and then app startup improvements on Android in 8.1 - 8.3 timeframe! |
@sgtcoolguy Thanks for the feedback, updated PR |
android/titanium/src/java/org/appcelerator/titanium/TiLaunchActivity.java
Show resolved
Hide resolved
android/titanium/src/java/org/appcelerator/titanium/TiApplication.java
Outdated
Show resolved
Hide resolved
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.
LGTM
ba45e34
to
47a7ad4
Compare
47a7ad4
to
e65e9b6
Compare
chore(android): log launch time fix(android,ios): generate platform specific bundles fix(android): amend launch time as debug statistic fix(android): rename snapshot method build: refactor babel transpilation options fix(build): bump build script ecma version fix(build): address lint warnings fix(android): use SystemClock.uptimeMillis() fix(android): validate snapshot header size fix(android): remove unused import fix(ios): use minIosVersion
e65e9b6
to
600c042
Compare
@@ -28,6 +34,21 @@ function thisOS() { | |||
return osName; | |||
} | |||
|
|||
function determineBabelOptions(babelOptions) { | |||
const options = { | |||
...babelOptions, |
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.
⚠️ build/lib/builder.js line 39 – Rest/spread properties are not supported until Node.js 8.3.0. The configured version range is '>=8'. (node/no-unsupported-features/es-syntax)
Building an app with artifact from this PR errors with:
This does not happen with master SDK from jenkins. |
The exception @lokeshchdhry ran into might be because we are doing a |
@lokeshchdhry I've fixed the |
@garymathews, that shouldn't have been needed, this works fine on master, it looks like the rollup configuration to ignore the semantic colors require when rollup does it stuff was just removed in this PR master, this PR |
@lokeshchdhry, regarding that exception, I assume the app didn't crash. The exception was simply logged right? I'm asking because I see a try/catch block around the |
@jquick-axway , yes the app does not crash but a runtime error is thrown. It says at the splash screen though. |
That would suggest our try/catch handling isn't working here. And yet the try/catch block we have in "ti.main.js" does work when attempting to require-in the ACA module that isn't there. Hmm... |
@jquick-axway Rollup pulled the |
FR passed. Checked it with default app & KS. Improvement in launch time is seen. Studio Ver: 5.1.4.201909061933 |
We just tried this change and it didn't really improve launch times (~3s) compared to before (~3.5s), tested on a Mi A2. You can test our app internally to reproduce the issue. Possible performance reasons:
|
Well if it reduced your launch time by 0.5 seconds, then I would say that is still an improvement. Every bit counts. And there are a couple other pending PRs that will improve launch times as well. One removes our usage of the Java |
common
bundle in V8 snapshot for improved launch timesJIRA Ticket