By applying different tolerance indexes, we tried to achieve that the simplified figure looked the less polygonal and closer to the original one.
With these improvements we really did a good job with the RAM consumption and loading speed of shapes, this is a summary of how many vertexes we put away with the geometries used to test it:
Take into account that if the shape has a higher quantity of vertices close to each other, more vertices are discarded by the simplify tool.
On the next table, these are some examples on Android of how many RAM we saved when trying to load some of these geometries thanks to these improvements:
Android Manifest largeHeap parameter
We discovered the existence of an Android Manifest parameter called largeHeap=”true” which overwrites the default maximum heap size to “more”, making the app process to surpass the limit from 512MB on the Alcatel device.
Imho, this parameter sounded like… instead of diving on which are the causes of the app low performance on some flows and fixing them, you can use this quick patch 😕, and the official doc confirmed this feeling:
android:largeHeapWhether your application's processes should be created with a large Dalvik heap. This applies to all processes created for the application. It only applies to the first application loaded into a process; if you're using a shared user ID to allow multiple applications to use a process, they all must use this option consistently or they will have unpredictable results.
Most apps should not need this and should instead focus on reducing their overall memory usage for improved performance. Enabling this also does not guarantee a fixed increase in available memory, because some devices are constrained by their total available memory.To query the available memory size at runtime, use the methods getMemoryClass() or getLargeMemoryClass().
Nevertheless, I think this parameter could be interesting to use on apps that make a heavy use of image or video processing tasks.
Next possible improvements to take into account
We achieved great results with simplify, but this isn’t enough, we need to continue improving it 💪
On the case of geometries with more than 17K to 50K vertices, the devices are not able to load the data of these objects on memory (saving the data sent from backend to the mobx stores) and end crashing while reaching the top RAM limit, the OS provides the app:
The next proposals to improve and, expectedly, get ridden of this problem are:
- Let the backend take care of creating the simplified shape instead of creating it from the app. This way, the app receives and saves on memory the data with the optimised shape avoiding wasting the device RAM from the very first moment.
- On the app, instead of saving the shapes data on memory, save them to the database and load to memory only the shapes the app is currently using.
Conclusions and considerations
In order to apply new improvements related with react-native-maps polygons perfomance, they all need to be related with lowering the RAM use of the app, either by reducing the shapes number of vertices or/and by reducing the data we save into the stores and moreover, saving that data on the databases and query and load what we need to the memory.
The use of profiling tools helps developers check if the new improvements actually did work out or if they didn’t.
Performance has always been an underestimated topic. It doesn’t mind the programming sector, either videogames development, web or apps: Most developers and project managers don’t give a fuck about performance.
Some of them tend to think just on the happy path of the users devices (the last iPhone or Samsung Galaxy model) while not taking into account the real number of their users using a 🐢 device or, on the other side, not profiling how many RAM the project is sucking from the devices, driving to overheating problems and “unexpected” crashes.
Others, tend to trust on the magic that the framework, libraries or engine used does, but on most projects that isn’t enough.
Luckily, each time there are more and more projects and people that really worry about performance and overall, about offering the best experience to their users from the moment a new set of features is published. I hope you, reader, become one of them, in case you still aren’t 💪