Every now and then we receive feedback on the performance and APK size of some NativeScript Android application, especially built with Angular 2. In this post I will try to elaborate a bit more on the technical challenges behind the Android Runtime, Core Modules and Angular 2 integration projects as well as to share some easy steps that would boost the performance several times.
There are several tasks that happen while a NativeScript Android application loads:
Note: File extraction happens only upon the first application run after fresh installation. On next runs the files are read directly from the file system.
The first two steps are constant in term of execution time and are of no interest for optimization. Steps 3 and 4, however, are the main suspects for increased loading time. How do we optimize these? Meet the android-snapshot plugin.
What this snapshot plugin optimizes is:
The only trade-off is that, due to snapshot files being CPU-dependent, application package size is increased with additional 5MB. Still, we have plans how to further improve this (read more in the Package Size section).
If you take a look at the Readme file on the snapshot repo you will see the approximate numbers of our tests. With snapshot enabled a blank Anular 2 application’s loading time is improved nearly twice - 4 seconds vs. 2 seconds.!
All of this sounds like a perfect solution but unfortunately it leads to some performance issues when V8’s GC is unconditionally forced because it is a blocking operation running on the main UI thread. We are trying to call V8’s gc only upon main application loop idle but it seems this heuristic is not working as expected during navigation.
As I explained in this blog post some time ago, the NativeScript Android Runtime ships with three separate builds for the three major CPU architectures available nowadays. This makes a blank Hello World application some 12MB big. If APK size is something that is critical for your clients then you may produce separate APKs for each CPU architecture your application needs to run on. For more information you may refer to the ABI splits section in the Publishing for Android help article.
Here is what you can do to improve the performance of your NativeScript Android application:
We have plans to further improve all of the above three major aspects of the overall performance in a NativeScript Android application:
Although NativeScript applications are 100% native and run fast and fluid in most of the cases, sometimes an application may need additional fine tuning, to become even faster. The NativeScript engineering team is actively working towards making all the above mentioned improvements enabled by default. As always, feedback is most welcome and much appreciated - please share it within the GitHub NativeScript and Android Runtime repositories.