NativeScript file size and boot time


#1

Hi All,

If you’ve read my last (and first) post here, I’m developing cross-platform apps with Titanium for a long time and starting out with TypeScript.

I’ve been doing some testing (after I have finished tutorials). I’ve create a vanilla Hello World project and an Angular HelloWorld project. My testing is done on those 2 project, blank, out-of-the-box, without any controllers on the page.

First - file size. I’ve compiled for android. The vanilla app takes 13mb and the Angular app takes 21mb. Blank app. No resources or anything.
Second - boot time. I’ve installed on my phone (LG G4). Vanilla app around 2 seconds. Angular app 3-4 seconds. Again, no controls on the page.

As I mentioned I’m coming from Titanium development and I really like the development options that TypeScript has to offer. But I’ve created the Titanium default Hello World project. The default contains a Tab View with 2 tabs with a label on each tab. The boot time in the Titanium app (with controls on page) was around 1-1.5 seconds.

I really want to move to NativeScript - but no to compromise on performance. So what do I do here?


#2

Hey @developer82,

First of all, thanks for checking out NativeScript, and also for providing this feedback on our forum :smile:

Those numbers look about right for the out-of-the-box experience, but there are two things you can do to optimize that app fairly significantly.

  1. webpack: Our webpack plugin greatly reduces startup time by bundling your app’s files together, which means there’s a whole lot less file I/O going on when your app starts up. Make sure to use the --uglify flag as that’ll add some tree-shaking optimizations that will take your app size down a bit too.

  2. Snapshot builds: With 3.1 we shipped an Android feature that lets you create heap snapshots of your JavaScript code, which reduces the amount of time it takes V8 to interpret your code when your app starts up.

With these two optimizations your startup times should be under well under two seconds for simple applications on decent devices.

The reason we don’t have these optimizations on by default is because they slow down your build times fairly considerably, so we recommend only using these workflows for benchmarking and release builds. That being said, I do think we need to be better about telling our users that these optimizations are available… somehow.

I’m actually working on a documentation articled tentatively called “How to Build NativeScript Apps That Start Up Fast”, which will theoretically put all of these tips into a single easy-to-follow guide. But even once that exists we still have to come up with ways to help people find that article when they’re looking for these sorts of benchmarks. Any suggestion you have would be great.

And also feel free to follow up here if you have any other questions or thoughts. Since I’m actively writing documentation on this topic I’m especially curious about what you think here.

Thanks!
TJ


#3

@tjvantoll
Thanks for the answer. I will definitely give this a shoot. I haven’t tried running on iOS yet - but I’m guessing that I will find similar results on it as well. Will this also improve iOS apps?

You said “should be under well under two seconds for simple applications” - what do you consider “simple applications”, and is the platform ready for an application let say like the facebook app?

Thanks


#4

Will this also improve iOS apps?

Webpack will definitely help with the iOS times. And in general {N} apps startup noticeably faster on iOS than Android—should be under a second for the default app once you turn webpack on.

You said “should be under well under two seconds for simple applications” - what do you consider “simple applications”

By simple apps I mean apps that have ~5–10 screens. For example we did some benchmarking on a NativeScript+Angular app called PracticeBuddy (http://www.practicebuddyapp.com/) and we got it loading in under a second on iOS and under two seconds on Android. (Those optimizations aren’t in the app stores quite yet but we have a preliminary write up at https://panayotcankov.github.io/nativescript-3.1.0-timeline/.)

It is true that the more JavaScript you have in your app the more time it’ll take to start up, but you can mitigate that cost by lazy loading your code. I’m working on documenting best practices here as part of my performance write ups, but this blog post can give you an idea of how you could do this in Angular apps https://www.nativescript.org/blog/optimizing-app-loading-time-with-angular-2-lazy-loading.

is the platform ready for an application let say like the facebook app?

Well… I wouldn’t recommend using any cross-platform tool to build something as huge as the Facebook app. I think once you get that custom it’s really worth your time to ditch tools like NativeScript and Appecelerator and build native from the ground up.

That being said most apps aren’t Facebook, and you can definitely build some fairly complex things using NativeScript. I’d say check out https://www.nativescript.org/nativescript-example-application for an app we built, https://blogs.sap.com/2017/05/24/sap-enterprise-app-modeler/ for a tool others are building on top of NativeScript, and https://www.nativescript.org/showcases for some apps our community has built to give you an idea.