Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

android generated libs size #273

Closed
farfromrefug opened this issue Mar 27, 2019 · 9 comments
Closed

android generated libs size #273

farfromrefug opened this issue Mar 27, 2019 · 9 comments

Comments

@farfromrefug
Copy link
Contributor

looking to compare mapbox to carto , one thing I realized is that carto so libs are almost twice as big as mapbox ones(carto SDK 4.1.6). so I decided to look at the android toolchain to see the compilation flags. I don't see any. Are all optimisations set to make the libs as small as possible?

@mtehver
Copy link
Contributor

mtehver commented Mar 28, 2019

About optimizations, we have experimented with compilation options quite a bit and current settings (look at scripts/build/CMakeLists.txt) seem to be optimal. Main reasons why SDK binary is large:

  1. We include styles in the SDK. Styles descriptions itself are really small but unicode fonts are roughly 1.5MB after compression.
  2. Valhalla routing library makes approximately the SDK about 25% larger. If you compile your own binary, you can exclude it. In fact, we are currently discussing droping the library from 4.2 release.

@farfromrefug
Copy link
Contributor Author

@mtehver thanks for the explanation. Makes sense. About the fonts you added Noto Sans recently which is 2.7mo which is huge. Also it does not seem to be used as Montserra is used first in the style.mss.
Couldn't we make this smaller? Or maybe extract the style as an asset, and not included in the SDK. An iOS framework as an android aar can have assets.

About Valhalla i will try and compile my own once you ve added the support for registerLicense on custom builds!

@mtehver
Copy link
Contributor

mtehver commented Mar 28, 2019

Noto Sans is used as a fallback font for non-latin scripts (Arabic, Russian, some eastern). It is a balance between size and the number of scripts supported (it does not contain Chinese nor Japanese). If your app only needs latin, then you can simply delete this from the style asset and everything should work.

Regarding SDK 4.2. We will be moving to newer NDKs and will use clang instead of gcc for compiling the SDK (gcc is removed from the latest NDKs). Unfortunately clang generates 20-30% larger binaries than gcc, so dropping the fonts or Valhalla does not help much.

@farfromrefug
Copy link
Contributor Author

@mtehver it seems like it is still possible to get clang version close to gcc ones as seen here.
Now about the font. Might be dump but couldn't Carto default style use default system fonts? This would reduce the style size to almost none.
As soon as you push changes for the latest NDK i will try and optimize it as much as possible.

@jaakla
Copy link
Contributor

jaakla commented Mar 28, 2019

In NDK level Android does not have really default system font. There are some fonts, but names and content of them (like which unicode sets are included) is impossible to estimate. It depends on firmware, manufacturer, user selected language(s) and Android version. Maybe even moon phase.

It may make sense to do some optimization - load fonts (or needed parts of the fonts) on demand with first online map view and/or include them to downloadable offline map packages, but this is quite complicated service by itself and it has been low priority. This is how Mapbox does it, and it has downsides: their offline packages are much bigger due to this, I've seen +100MB just for these assets. There may be a hack - remove styles and fonts from SDK package, put some placeholder and lower version number of it, then our style asset automatic updater should download current version during SDK startup. It reduces APK size, but by time of viewing map the total download is still the same, as user needs style and fonts anyway to show maps. So I'm not sure if it make sense to reduce user experience with this. App APKs are nowadays 100+MB anyway.

@farfromrefug
Copy link
Contributor Author

@jaakla sorry but I totally disagree with you on apk size. not all apps are more thant 100mo, far from it.I dont even have even one over 60mo.
Also I feel obliged to say that you should always try to keep apps as small as possible: shorter build time, less computing -> less energy. also smaller apps requires less bandwidth -> less energy. There is no going around it. Finally smaller platforms like watches or embedded connected devices are restricted in memory and disk size.

all that being said I get your point on fonts. maybe the best solution then would be to put the style outside of the lib as assets. that way it some easy for any dev to replace the style.

@jaakla
Copy link
Contributor

jaakla commented Apr 8, 2019

Thank you for feedback. We are considering how to reduce the library size. One option would be to create a light build for next version without the assets included, so you can load them lazily, using a downloaded style (including fonts) or using device-included fonts. Would this help you?

@farfromrefug
Copy link
Contributor Author

@jaakla for sure it would. I might also help in native lib loading time #241
As soon as 4.2 is in alpha (licensing lib) i will help a lot more with PRs too to improve size and speed.

@farfromrefug
Copy link
Contributor Author

I think i can close this for now. Right now the android version is 6.5mo compared to the 4.9mo of mapbox. Close enough. Thanks for all the great work

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants