Running some native code for the first time results in application lag

[edusperoni]

Environment Provide version numbers for the following components (information can be retrieved by running tns info in your project folder or by inspecting the package.json of the project):

• CLI: 5.3.0
• Cross-platform modules: 5.3.1
• Android Runtime: 5.2.x and 5.3.0 tested

Describe the bug When using trying to use some android variables or instantiate some instances, the first call will have a heavy delay (500-600ms on a Galaxy S8).

Using the playground, reading android.R.integer.config_shortAnimTime, android.R.attr.state_pressed and android.R.attr.state_enabled all caused a delay, which froze the UI.

Downloading the project and using NS 5.3, calling nativeView.getContext().getResources().getInteger also called a delay and freeze. Edit: Running with --bundle shortens this delay for some reason (takes something like 30-40ms)

This freeze happens only on the first time the code is run, after that it takes less than 10ms.

To Reproduce Measure how long it takes to call:

const t = android.R.integer.config_shortAnimTime; // should take long on first time
nativeView.getContext().getResources().getInteger(t); // should take long on first time in 5.3

Expected behavior These calls should behave on the first time as they do on the second and onward.

Sample project https://play.nativescript.org/?template=play-ng&id=28zxPb&v=6

Additional context We discovered it by https://github.com/JoshDSommer/nativescript-ngx-shadow/issues/16

[farfromrefug]

i actually discovered that issue too yesterday working on nativescript-material-components the reason is that you are accessing android.R. And the issue is the materializing of the android.R namespace which in my case takes 1s. That s also the reason why you are not seeing it the second time: the runtime is initialized and the android.Ris already materialized. So the real issue is materialize time, can it be made faster? if not it should be documented that it is a bad idea to access android.R.

is there a method I tns to query an android.R attr without materializing it ?( native)

[edusperoni]

Furthermore, if you create an abstraction for android.R, the issue vanishes:

package com.example;

public class TestClass {
    public static int test() {
        return android.R.integer.config_shortAnimTime;
    }
}

Calling com.example.TestClass.test() returns instantly. This is most likely an issue with NativeScript marshalling (or looking up) android.R to javascript.

[edusperoni]

@farfromrefug Here you go:

    getAndroidR(rtype: string, field: string): number {
        return +java.lang.Class.forName("android.R$" + rtype).getDeclaredField(field).get(null);
    }

Example:

https://play.nativescript.org/?template=play-ng&id=Raa1Ru&v=3

I've found a way to query android.R with minimal lag (should take 0-1ms). I'll probably switch to this method while this issue still exists. I imagine a few plugins are affected by this.

Edit

Updated example (it was returning Object)

[vahidvdn]

I have the same error while accessing android.R. This doesn't happen with accessing to android.

Here is the demo from the playground:

[Vahid]: js access: 0.00ms
[Vahid]: native access: 901.00ms

After first access, it becomes normal:

[Vahid]: js access: 0.00ms
[Vahid]: native access: 0.00ms

[vmutafov]

Hey guys! Accessing android.R is slower because of the current way the runtime works. At runtime, when accessing some package or class we return a special JS proxy object for the native symbol. If the native symbol (class or package) has lots of properties the marshaling is quite slow. We're researching some other ways to marshal native symbols but for now, the workaround is to use reflection as @edusperoni did in those cases.

[edusperoni]

If you must use the full androidR, I made an androidR hack using JS Proxy: https://play.nativescript.org/?template=play-ng&id=em2l8m&v=1

if you copy fast-android-r.ts to your project you should be able to use androidR.integer.whatever in a relatively fast way (everything is cached).