I'm going to be talking about V8 in the real world, or more specifically in the native

script framework.

I'm Stanimira Vlaeva, I'm a software engineer and work on this cool open source project,

NativeScript.

And I'm with web technologies, and find me on Twitter, the best place.

Or in the karaoke after.

So, NativeScript.

Our main topic today after V8, of course.

What is it?

What is it?

How many people here have heard about NativeScript?

Awesome.

Okay.

NativeScript is a framework for building native mobile applications for Android and iOS using

web technologies.

Like Angular, Vue, or just plain JavaScript.

In short, it is a way to execute JavaScript in the mobile world.

And build mobile applications with it.

We will take a short overview of the architecture of the framework.

At the bottom, of course, we have Android and iOS.

Operating systems.

On top of that we have the NativeScript run times for Android and for iOS which provide

the 100% native API access.

But if you have had to build a native application for Android or iOS, you may have noticed the

way to do that is quite different.

The APIs are different and the way to build your user interface is different.

Everything is completely different because they are two different worlds.

That's why NativeScript provides a common abstraction for these APIs.

It is part of the framework and the NativeScript developer cans use that in order to build

layouts or build user interface or even style their applications with CSS and this layer

is written in JavaScript and you can use that so that you can have a single codebase and

have different applications for Android and iOS.

NativeScript also has a very light application framework which provides us with native bindings,

navigations and some other cool things.

And if you need something a bit more sophisticated while building your applications, NativeScript

also supports Angular and Vue JS.

Today we're gonna talk about the bottom most levels.

The deep stuff.

And more specifically, we're gonna talk about the Android runtime.

The two runtimes are quite similar.

And the biggest difference between them is that the Android runtime uses V8 under the

hood whereas the iOS run time uses another JavaScript engine.

JavaScript Core.

But the principle of how they work is quite similar.

We're gonna start by explaining how the native API access works.

As you make have guessed from the name ""NativeScript,"" this is kind of what we mostly brag about

because we have 100% API access.

And this is why you should be using NativeScript instead of whatever  anything else you choose.

The main advantage.

How it works.

We'll start with the look at the application package of our NativeScript application.

So, we have Android, some phone or some device that is running the Android operating system.

And the NativeScript application is just a regular Android application and which has

some NativeScript magic inside it.

And the first part of the magic is, of course, the JavaScript code that the NativeScript

developer wrote and shipped inside that application.

The JavaScript code is not cross compiled or converted or anything like that, it stays

JavaScript during the whole life cycle while the application is running.

We also have the NativeScript run time, both in the Java part.

We're going to talk about them shipped together inside the application.

And the last part, almost, is V8.

Why do we need to ship V8 inside an Android application?

Well, to execute JavaScript.

V8 is a JavaScript engine.

It executes JavaScript.

It is embedded in Chrome, Note, even Microsoft nowadays and of course in NativeScript.

It was developed by Google.

It was created from the Chrome browser and it's one of the fastest JavaScript engines

out there.

Another reason why we chose V8 is because it has a cool API that we can use and plug

into the runtime.

If you want to read a bit more about V8 and how it works, I highly recommend these two

resources.

The first one is a really amazing popup series which is a crash course just in time compilers.

And the other one is a video which is very recent.

It's called why the script?

And describes the optimizations under the hood while it executes your JavaScript code.

It's from the V8 team.

If you want to learn about modern JavaScript engines, these are two great resources to

get started.

The next part of the NativeScript magic.

The metadata generator.

This is one of the very, very valid JavaScript code inside of NativeScript.

But we have something that is not usually in the JavaScript language, right?

Android.

Where does this come from?

Well, let's imagine that when your computer, you have some native library.

For example, Android SDK.

And you use that inside your NativeScript application.

While your application is being built, NativeScript runs a special tool called the metadata generator

which traverses that native library and gets information about the APIs.

It gets information about all the global packages, about every single class, about how these

classes can be instantiated, about every method in these classes and what are the meta signatures.

Basically, it gets information how every single method and API can be used.

That is saved inside a compact runtime binary which is, again, shipped inside the application.

So, we have information about how we can create stuff in Java inside the metadata.

And the metadata of course is shipped together with the whole application as well?

And what happens at launch time?

We initialize V8 which can execute the JavaScript code.

We load the metadata from the files saved inside the application and we attach source

and callbacks.

And the callbacks are the most important part about embedding V8.

They are our way to plug into the JavaScript code and do all sorts of stuff.

Let's start by explaining some stuff about these callbacks and how they actually work

together with the metadata to provide access with the native APIs.

Okay, we have this expression, Android media recorder.

We are trying to execute that JavaScript code.

The NativeScript runtime has read the metadata and found out that there is an Android global

package.

That's why it has created a global object inside the running V8 instance for Android.

It also has attached some callbacks to that object.

Like the package getter callback so that when we query for Android.media, the NativeScript

runtime plugs in with that callback.

The callback will be executed.

And inside the callback the NativeScript runtime will try to find Android.media inside the

metadata.

It returns something, some information, for example, some information that Android.media

has some media recorder.

And it also has a package getter callback attached.

So, when that callback is called, we find the media recorder inside the Android media

package in the metadata.

And this time we return a constructer function because this is actually a class.

And why is this constructer function so important?

Well, because when it's invoked with new, it actually contains a constructer callback.

Again, attached by the NativeScript runtime.

And this is where the actual magic happens.

Because the NativeScript runtime creates a native Java object.

But how does that happen?

Well, we use JNA, Java native interface, and this is a bridge between V8 and the running

Android runtime.

So, we can save functions back and forth between the two.

So, we create a native object.

Then we create the JavaScript proxy object that we're going to discuss a bit later and

we return the proxy object to the JavaScript world.

If it's right to access something inside that proxy, well, actually this proxy object is

not very simple.

It's not a plain object.

It creates some callbacks.

Contains some callbacks as well.

So, when we try to access this random field, we know that this field exists in the Java

world so that we have attached a field getter callback.

And the field getter callback actually queries the original Java object.

But there is a slight complication here.

Okay, we can get the result from the Java world.

But the data type is different from the JavaScript data type, right?

So, Java run string is not something we can assign to a JavaScript variable.

And that is why there is a marshaling service.

To convert it from Java so to JavaScript and vice versa.

At this point, you would say, wouldn't that be terribly slow to convert everything?

Obviously, it will be, if it's to convert object, it's not a good idea.

This is another reason why proxies are quite useful.

So, for objects, we just create a plain JavaScript object which has the same methods with the

same signatures.

And the same members as well.

And inside that we have callbacks.

So, that when you call some method with the same name on the JavaScript object, the callback

will be called and the NativeScript runtime will call the original Java method for JNA.

And this is a very cheap operation.

Creating new JavaScript objects.

Instead of converting data.

If you call a method, same story.

A method callback is triggered.

We call the original Java method.

The result is marshallized again and returned back to the JavaScript world.

If we have arguments in that method, the arguments will be converted to Java data format.

And then they will be  the Java method will be called with deconverted arguments.

Okay.

Let's see just a quick overview of all these callbacks, if they are confused you so far.

We try to instantiate new object and assign that to a JavaScript variable.

We call the constructer callback.

If you want to create a new instance of the class through JNA.

The instance is returned.

And because it's an object, the NativeScript runtime creates a JavaScript proxy object.

Then we try to call some methods on that proxy.

We call actually the method callback without knowing that we are calling it.

Everything is hidden.

It happens behind the scenes.

But the method callback then calls the original Java method.

The result that we can get is returned through JNA and marshallized and returned back to

the JavaScript world.

That's all the communication magic that happens.

What you may be wondering at this point what happens with these objects.

Like we create JavaScript objects.

We also create Java objects.

They are collected in some way.

So, we actually have to take care of their life cycle.

And in JavaScript we don't have to manually manage the memory.

There is a garbage collector that runs.

And it's always to retrieve the memory of the unused objects.

It also has a nondeterministic nature.

We can't be sure when the garbage collector will run.

And the other kind of complication is that, well, the Android runtime also has a garbage

collector.

It's pretty funny.

So, we have two garbage collectors running.

We have objects in both worlds.

And that's one of the biggest challenges of the NativeScript runtime.

We have to kind of try to synchronize that.

We have to ensure that no object is collected if there is a living counterpart.

For example, if you create some Java object through JavaScript, and then try to access

it, if the Android garbage collector collected the native Java object, that sounds really

cool because you will try to access something is that doesn't exist, and the application

will crash.

Like, it will crash.

Yeah.

You're running a mobile application and it's not really cool user experience.

Okay.

In order to plugin into the life cycle, we use finalizer callbacks so that when the garbage

collector of V8 marks something that  for collecting, says that some object doesn't

have living instances anywhere and it should be collected, the finalize of the callback

will be called.

And this is the place where the script runtime is plugged into.

We have strong and weak references.

Let's see how these actually look like.

We have the same example as before.

First, we create the native object.

Then we create the JavaScript proxy.

And then the NativeScript runtime has two collections.

One for strong references and one for weak references.

When the objects are first created, we create a strong reference or a link, if you would

like to call that, between the two objects.