perf(android): enable JavaScript Int32Array to be used when calling a Java method

[DzzD]

Originale discussion

• JavaScript have special arrays "Int32Array" which are by the nature of there implementations a way faster than standard arrays.

• Int32Array are stored in a single memory block and provide faster direct access.

• This is the format that best matches native int[] arrays.

• Actual version of Titanium SDK does not support their usage. Calling a Java method using Int32Array as a parameter will fail with Invalid value, expected type Array.

• Int32Array arrays should be used when ever a native method require a native int array as they are stored in memory similary.

• The performance gain by using Int32Array instead of Array is about 20 times faster.

This fix enable to call a Java module method with Int32Array parameters and will auto-detect Int32Array in other parameters like Object, Hasmap, etc...

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays

[DzzD]

I set it to draft, as I think it is probably better to make a full package of optimisation, including at least Float32Array.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays

[DzzD]

The way i have implemented this will change the jsIntArrayToJavaIntArray signature from jsIntArrayToJavaIntArray(Array) to jsIntArrayToJavaIntArray(Value)

This is a method call embeded in module while compiled. So this will make module compiled with new SDK not compatible with Application build with older SDK. because new module will try to call jsIntArrayToJavaIntArray(Value) and it wont find it in old SDK because old SDK will only provide a jsIntArrayToJavaIntArray(Array)

Do you think it is a problem ?

If it is, we could create a new java type Int32Array/Float32Array that will be requiered to know/force the use of real native int[]/float[]. So a module class myMethod(int[] arr) will use the old way while a method myMethod(Int32Array arr); will use new method. This will ensure fully back and forward compatibilities between old/new modules and old/new SDK.

But if a user dont knwow about the new types and use int[] as parameter of a java module method it will still use the old way and be as slow than before.

IMO : I would prefer to use the first solution in[] => Int32Array, rather then a workaround even if it break a little compatibilities with old/new SDK modules.

What is your opinions ?

[m1ga]

you can always set the minsdk value in a module: https://github.com/m1ga/ti.animation/blob/master/android/manifest#L18 so that won't be an issue if the person who builds the module is aware of it and builds the module with the correct value.

As long as the otherway round works: old/existing module works with the new SDK. Otherwise: there is a waiting PR with some color changes. That is a breaking SDK change and modules have to recompiled for it in order to work. So there will be a SDK in the future where you have to rebuild modules