Android-runtime: Optimize default apk size

[blagoev]

PLAYED WITH THE APK SIZE AND HERE ARE THE RESULTS
The result apk size for 3 platforms armv7, armx64, x86 is now 9MB (down from 12)
If we bundle only x86 and armv7 apk size is now 6.2 MB (down from 8.5MB)
Further optimizations are possible if we are willing to sacrifice some startup performance:
For 3 platforms size can be around 6.6MB
For 2 platforms size can be around 4.7MB
Note: By default we can package only 2 platforms which will result of working applications on 32bit and 64bit devices. Only when the user wants (which is rarely needed) a true x64 app we can package the 64bit libs.
Packaging android apps with only 32bit native binaries is one liner.
BTW: we are not doing the most C++ optimizations possible when building the runtime now we are doing -O0. If we switch the -O3 flag we get somewhat bigger native libraries results in about 500KB apk increase on all variants

There is a pull request for these changes here: https://github.com/NativeScript/android-runtime/pull/522

[blagoev]

This also means that the current support for native extensions will not be possible by these optimizations. I think we can think of a way to include the bigger native libraries when such plugin is needed (which is again very rare and such plugins do not exists currently or are at very experimental/poc stage)

[blagoev]

The PR fails because of a test we have of a hardcoded test for supporting a basic native extensions

[blagoev]

ping @NativeScript/android-runtime

[NathanaelA]

@blagoev nice job.

Is it that the native android .so plugins require something to be exported? If so; what about just making all .so plugins follow a standard ns interface; you always pass into the plugin a pointer to the v8 context then the plugin would use that context to decode the parameters sent to it; it does it "native stuff" and then return whatever structure needs to be returned... It requires a .so plugin author to understand a bit more about v8; but it I'm writing at that low of a level anyways; it is only a small amount of additional work...

[slavchev]

I don't think that these optimizations will affect native *.so extensions.

[blagoev]

@NathanaelA It works the way you described it. Native extensions get a v8 context and use v8 API to do its work. It requires big V8 knoledge and NativeScript android runtime internals knoledge and is prone to be broken from version to version. (the same way NodeJS native extensions are)

@slavchev It is totally affecting native extensions since these optimizations hide all not exported functions from the symbol table of the libNativeScript.so file. When loading the native extension library at runtime it fails to find the v8 symbols that the native extension requires and fails miserably.

[petekanev]

@NathanaelA PR #588 made it into the master branch.

That means that beginning with 2.4.0 if you wish to extend v8 functionality through the use of a native plugin, you will have to declare an additional flag in the module's package.json -> useV8symbols

The optimizations come mostly from stripping the V8 symbol table, and account for about 3MB reduction in package size, combined, when all 3 supported android architectures are packed. 11MB vs 14MB unoptimized, blank template application with all 3 supported architectures.

If necessary, you can further reduce package size by making a separate package for each architecture -> https://docs.nativescript.org/publishing/publishing-android-apps#apks-with-abi-splits