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

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 JoshDSommer/nativescript-ngx-shadow#16

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)

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.

@farfromrefug

@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)

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

@edusperoni

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.

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).

Navigation Menu

Repository navigation

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

Edit

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

farfromrefug commented on Apr 1, 2019

edusperoni commented on Apr 2, 2019

edusperoni commented on Apr 6, 2019

Edit

vahidvdn commented on May 27, 2019

vmutafov commented on May 27, 2019

edusperoni commented on May 27, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions