13 December 2021 Reading time: 3 min

Android Studio – what to do not to lose RAM memory

Bartłomiej Szmajda

AS (Android Studio) is not recognized by the general public as the fastest working tool. It is too heavy and also takes up more memory than Chrome. Therefore, it is important not to hit your AS even more by adding more tasks to it than it can handle.

In two of our biggest projects, we had the idea to add a file called logic.dart. His role was to deal with all of our imports so that we would not have to think about them. We threw into it all the `import` and` part` files that related to our resources, both external and internal.

In theory, it worked fine – we didn’t have to worry about importing, we had everything available from the screen, we just imported one file – logic.dart, the files were smaller and without unnecessary lines.

It turned out, that opening each file containing the app logic took a few seconds. Oftentimes, you had to reset the entire Android Studio using the popular `invalidate caches / restart` button, and AS itself started to download gruesome amounts of system memory, reaching up to 9 GB ?

It even seemed to want more memory over and over again until waiting for a coding hint proved to be taking longer than writing all the code without program support.

Enlightenment came to us when we change our architecture to the new one that we use until now. It required a greater division of logic on our part. So we couldn’t afford to keep everything in one place. Our new projects have become incomparably lighter and after a whole day, the difference in the comfort of work was really visible.

It was not an obvious reason for such a resource-consuming operation of the application. Only after completing a few next projects in the new architecture did we conclude that it must have been our ill-fated logic.dart file. It seems that if the AS has too many code segmentation marks (or rather, the number of lines that a given file has access to), it starts to run much slower. Probably Android Studio tried to keep all these files in memory. Additionally, code issues don’t make things any easier because the dart analyzer also seems to run slower the more code issues we have.

The solution for this problem is to limit the amount of file segmentation. It shouldn’t be a problem to have one `bloc`,` state`, and `event` as segmented items and it is definitely not worth throwing in things that do not require it!

We are also aware that it is not something worth maintaining. Code should be segmented only if there is a good reason for it. But after this change, the amount of resources used in our Task manager dropped by over 6 GB of RAM!

This allowed us to hit on another problem. Many developers are probably familiar with a package called moor. For those who are not familiar with it, it is a library that is used to manage the database and its ORM. The problem we faced in one of our projects was to provide the ability to use the application offline and to synchronize it with the server.

The files that serve as tables for our database (there are 20 of them) have to be defined in the same file where our database is defined. This requires for us to import all the generated code and table definitions along with each object.

However, this results in generating a huge 13,500 line code-monster (not counting the database files themselves and their tables!) that eats up our memory.

Adding the generated file as ignored to analysis_options.yaml does not help, because the code has to interpret the attached files anyway. The only workaround for this is to segment the files so that they are logically the same thing.

Currently, at the time of writing this article, work is underway to resolve this problem. However, they may take quite some time. It is worth keeping this in mind when you are thinking about choosing a library for your database. This may not be a flaw that completely disqualifies moor, as a great package (it has already fixed what bothered me the most – the generation of json serialization), but it is good to know what contributes to the way our AS works. There could be more libraries like this one.

More inspiring knowledge

Main base

Konarskiego 18C
44-100 Gliwice

Contact us


VAT EU: PL6312680249
+48 725 733 380

Privacy Policy
© Copyright 2021 by appvinio.