Deep Dive into NativeScript 3.1 Performance Improvements

Next, run your app again and pipe the output through the timeline-view tool:

 

Run the app, perform the actions you want to test, and then click Ctrl + C in the terminal to break the CLI execution. The timeline-view tool will collect the traces before exit and generate the report. It will print the location of the report in the terminal so you can open it easily in a browser.

Let’s look at how we can use this tooling to help improve the performance of a real app.

Practice Buddy

Practice Buddy is a NativeScript + Angular app that helps music teachers work with their students. Music students use the app to record practice sessions that their teachers can listen to and provide feedback. Kudos to Jen Looper.

The app makes a great example of the timeline and performance improvements for 3.1. Here is the breakdown:

Android

Timeline: tns run android

Here are the numbers you get by updating PracticeBuddy’s app/package.json file to enable tracing and running the app with:

Android vanilla run HTML times report.

• 2100ms in extracting assets
• 2200ms in initializing the runtime
• 1350ms in requiring modules - tns-code-modules, angular etc.
• 750ms in MarkReachableObjects (GC)
• ~2000ms in making NativeScript views

All of this adds up to a total of about 9 seconds.

Timeline: npm run start-android-bundle --uglify

The vanilla tns run doesn't incorporate the webpack and the Angular tooling. To see the difference adding these optimization steps makes, let’s run the app again with webpack using:

Android bundle and uglify HTML times report.

• 180ms in extracting assets
• 180ms in initializing the runtime
• 750ms in executing the vendor.js file
• 320ms in executing the bundle.js file
• 390ms in MarkReachableObjects (GC)
• ~1000mx in making NativeScript views

Timeline: npm run start-android-bundle --uglify --snapshot

To keep these optimizations going, let’s next add the shiny new local V8 snapshot android feature:

The “extracting assets” portion of the profiling is the time it takes to read JavaScript, XML, and CSS files. But why do we need assets extraction when webpack can pack them all as JavaScript strings and they can actually get in the snapshot? These assets are extracted only once on the very first app launch. Subsequent launches won't include that time. So this is something we may consider handling better in distant future but at the moment is a task with low priority.

MarkReachableObjects?

This is the bad guy we have on our roadmap to deal with in the near future. Basically, when you create a function and enclose some objects in JavaScript, and pass this as implementation for a Java interface, the NativeScript framework has to keep the Java objects alive while the function is alive in JavaScript. This happens upon garbage collection, NativeScript will walk up the JavaScript function’s object graph and reference potential Java objects so they survive the Java garbage collection. This hasn’t been an issue in vanilla NativeScript applications nor the Android Runtime unit tests as the object graphs there are relatively small. Now with the snapshot we try to put all the JavaScript up front in the vendor.js and feed the heap as early as possible, making larger heap and affecting negatively the MarkReachableObjects.

What was the V8 Snapshot Again?

There is an extensive blog of what snapshots are and how to enable them by Ivan Buhov.

What the snapshot does is to run a command line tool on your Mac. (The snapshot generation feature is limited to macOS and Linux currently, see the link above for details.) The tool executes all the JavaScript from your vendor.js in a V8 instance, and then captures the in-memory objects into a big (increases app size) blob. When the app starts, instead of parsing and executing your JavaScript, the app just loads the blog into memory and continues.

Every time the app starts on a device it feels like a gamer is resuming a saved game—the app doesn't have to replay the loading, parsing and execution of the JS.

So How to Maximize the Benefit of it?

There are two quick things you can do to maximize the start-up performance of your app.

• First, minimize the amount of JavaScript your app requires.
• Second, move as much JavaScript as possible to your vendor.js file so it makes its way to the snapshot.

Running the timeline-view shows slow require paths. You will be surprised the amount of unused JavaScript your average NativeScript app might be in. Here are a few examples we’ve found.

• Alexziskind1's looptidoo that depends on a library called faker, and faker requires 30+ small locale files. (Your app will rarely need more than one.)
• The nativescript-marketplace-demo has a page that displays source code that uses highlight.js. Highlight JS has support for many languages (and the app requires them), but the app itself only needs highlighting for XML and JS sources.
• Practice Buddy requires the root of Rx.js, while in general when working with Rx.js you can require just use a handful of operators.

To further optimize the startup time for the Android version of Practice Buddy we added the following lines to that app’s vendor.ts file:

This saves another 200 ms during startup, as those files are now included in the webpack bundling, and therefore also the heap snapshot.

Webpack Bundle Analyzer

Finding chunks that should be moved from the bundle.js to vendor.js is easily done using the webpack-bundle-analyzer and has been covered in the 'Using Webpack to Bundle Your Code' NativeScript article.

In general you should move everything from node_modules to the vendor. This is done by requiring the modules in the vendor.js. However some plugins that use native Android APIs will have to be refactored as the native APIs are not exposed during the snapshot generation. You can check the PR for the nativescript-plugin-firebase made by Stanimira Vlaeva, as it provides a good example of wrapping access to Android Java classes in functions and delaying their execution until runtime. When it is merged, a require("nativescript-plugin-firebase") should be added to the vendor.ts file of any apps that use that plugin.

Now this is the webpacked and uglified Android version of the app in 3.0.0, with explanations of the main times and what is expected to happen by adding the 3.1.0 snapshot feature:

Now that we’ve thoroughly broke down the Android loading process, let’s shift our attention over to iOS.

iOS

Timeline: tns run ios

Here are the stats on running a vanilla NativeScript iOS build and piping the data to the timeline-view tool.

iOS vanilla run HTML times report.

• 400ms in preparing for live-sync
• 500ms in waiting for debugger
• 900ms in require nativescript-angular/platform
• 850ms in require app.module.js
  • 500ms in require rxjs/Rx.js (this time is already included as part of the app.module.js)
• ~1000ms in making views

This improves the app loading speed by about 3 seconds.

Why only 3 seconds? The first 900 ms in the stats above are debug-only steps. The waiting for debug time is removed in release and also live-sync is not available in release. So release builds will take almost 3 seconds.

Timeline: npm run start-ios-bundle --uglify

Next let’s add webpack as well as uglify minification so we get the the best possible performance out of this Angular app.

iOS bundle and uglify HTML times report.

• 500ms in waiting for debugger
• 400ms in vendor.js
• ~500ms in making views

That is a little under a sec if you subtract the debug-only “waiting for debugger” step.

Bundling packs all files in a single file, reducing file I/O, and uglification has much higher impact since JavaScriptCore on iOS doesn’t perform JIT compilation. The bundle extraction happens again but it is fast, in the previous case it was slow because of the number of files.

Sweet Awesomeness

Icons and Launch Screens

No Startup Keyboards

Release Party at Last

Remove the "profiling": "timeline" from app/package.json before release. When building in release both the iOS and Android platforms will skip some debug stuff and hurry up a little.

Android

Subsequent hot runs get under 2 seconds for android:

iOS

What if I told you it gets even better with the built-in iOS icon to launch screen grow transition and the launch screen to app fade transition? Especially when the native framework uses ref counting instead of GC.

 

I am not sure how to precisely measure the time in the release build, but here is how it looks:

What is Next

The tool makes use of some NativeScript internal knowledge and may be too verbose in some cases, but leave gaps at others. We will try to polish the position of these manually placed traces. If this turns useful enough we may try to merge the data with the timeline profiling utilities in the Web Inspector and the Chrome DevTools.