-
Notifications
You must be signed in to change notification settings - Fork 68
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
Comments
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:
|
@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. About Valhalla i will try and compile my own once you ve added the support for registerLicense on custom builds! |
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. |
@mtehver it seems like it is still possible to get clang version close to gcc ones as seen here. |
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. |
@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. 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. |
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? |
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 |
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?
The text was updated successfully, but these errors were encountered: