I'm running my project build on React-Native on android device and as I scroll down the list the app memory continuously increases. Even after navigating to other screen, the memory is not freed up in case of android while a lot of memory is freed in case of ios device. The investigation for the android was done on the android activity monitor and the video for same is available here
How can the memory be freed up in case of android ?
That's the standard behavior of the Android library Fresco used by React Native under the hood. Fresco caches all images in memory to the max authorized by the system. It's a cache, so images stay in memory even if they are removed from the screen, just in case, for later use.
When the app needs memory space, the GC is able to "scrap" this cache. That's what happen at 0'24'' in your screen recording (you can see a small "drop" of the allocated memory).
This article explains the memory management in details.
In conclusion, a React Native app using images will always use almost all the memory allowed by the system. The memory is gradually freed for the needs of the app.
At the moment there are known issues with react native ListView, check the issues related to listview here https://react-native.canny.io/feature-requests/p/fix-various-listview-issues. In the interim check this repo that tries to optimise listview for performance https://github.com/sghiassy/react-native-sglistview
Related
I want to optimize my Xamarin.Forms app, so I am starting to use Xamarin Profiler, and I can see that the initial memory allocated in my Android app is always around 50MB.
The allocated memory is 50MB when the app starts, and it starts to increase around +1.6MB when I do push and around +0.2MB when I pull a page.
Of course, the more I navigate, the app goes slower and slower.
But I don't know if this amount is OK or if the app is consuming too much memory.
Guys, could you orient me a bit more about this? I am using MVVMCross (as MVVM framework) and I am not showing images in the MainPage.
Allocating +1.6MB when navigate to page is normal. But it should be released after navigating back and GC calling.
If you are not caching the pages all memory should be released and you should not see 0.2MB added after pulling a page, so I think you do have a memory leaks. Making memory snapshots and comparing between them can help you to detect memory leaks.
To check where memory leaks could be do the next steps:
Because Profiler manual snapshot is not working in latest (0.32) version set Auto Snapshot in Tools -> Options -> SnapShots. I recommend to set it to GC option.
Make snapshot (call GC if you set autosnapshot to GC option)
Navigate to Page you want to check memory leak.
Navigate back
Make snapshot again,
Compare between two snapshots and check what wasn't released
Try this link for more info.
I hope this post is helpful for you.
I have a problem. My App's memory is taken away by system when in background. So, I try to release some resource, like bitmap, to avoid this. But from the memory tool in Android Studio, I found that there are two kinds of data about memory. One is "Free" and the other is "Allocated". After recycling bitmap, the Allocated part get down while the Free part get higher. On other hand, I check the cellphone's setting->application management->running, it shows that my APP hold nearly the same memory as the one before I recycled bitmap and the memory usage just equal to the Free part+Allocated part.
I'm confused. Is the freed memory by recycling bitmap still occupied by my APP in view of system? If so, my app is still facing the risk of being killed. How can I save my APP in background?
Good day,
I am developing an adventure game in AIR for Android. I am instantiating levels from the library (movie clips), each containing at least one HD resolution bitmap.
When the game starts, it occupies about 150MB of memory, including the AIR runtime and the SWF. Out of this 150MB the SWF is about 12MB at this time.
As the game progresses the memory consumption of the AIR runtime increases, while the memory used by the SWF remains at around 15-20MB. When the total memory consumption reaches about 350(!)MB, the OS intervenes and kills the app.
I was careful to reuse objects whenever I could, and nullify any unused objects to make them eligible for GC. GC seems to be working as it should, as the memory used by the SWF remains steady around 15-20MB. I can see it drop from 20 to 12 from time to time when GC kicks in.
Things I've tried:
Removed all cacheAsBitmap and cacheAsBitmapMatrix properties.
Exported each level into a separate SWF and loaded them from there instead of the library.
Forced the GC hack just to see if it has any effect.
Fiddled with System.pauseForGCIfCollectionImminent(n) with different values for n.
Tried different acceleration modes (direct and auto) thinking maybe the GPU is at fault.
All failed, memory consumption just runs away.
This happens only on Android. On a PC everything is fine, the whole thing takes up about 250-300MB, and this number remains steady, no matter how many levels I load one after another. Didn't have the chance to test on iOS yet.
I would really appreciate any ideas or insights into how to make this problem go away.
Thanks.
1) Easiest way to find memory leak is to use Adobe Flash Builder. Just run profiling.
2) Also good way to exclude leaks in future: create function which will be used for "cleaning". E.g. it will null all local variables of instance and so on. Something like usual c++ destructors. Then, before nulling your object, just call this method.
iOS apps (for the most part) is written in Objective-C, which is a subset of C, and is therefore a data managed language, unlike Android/Java.
In Android, you have the ability to increase heap size by simply adding this one line in the XML android manifest:
<application android:largeHeap="true"/>
Is there an iOS version to doing something like this?
Well in iOS you don't have any control over the memory.
It is all managed by the kernel. So you cannot increase the heap size.
As pointed out in the comments, memory management has a different notion in iOS.
You get as many memory as available but if the app uses to much memory it will be killed by the system.
Now that you explained your goal, you shouldn't download large files into memory, this will cause trouble. Instead you should save it directly to the disk as you get the response.
Take a look at Apple's "Memory Usage Performance Guidelines" for an explanation of how iOS doesn't manage swap space.
Although OS X supports a backing store, iOS does not. In iPhone applications, read-only data that is already on the disk (such as code pages) is simply removed from memory and reloaded from disk as needed. Writable data is never removed from memory by the operating system. Instead, if the amount of free memory drops below a certain threshold, the system asks the running applications to free up memory voluntarily to make room for new data. Applications that fail to free up enough memory are terminated.
iOS attempts to provide each application with as much of the device's memory as the OS can spare. However each application is limited to the device's physical memory. There is no option to allocated larger blocks and expect them to be swapped to disk as needed.
Manipulating the heap size in iOS is therefore not a meaningful concept. Each app already has the largest heap the OS can provide. Instead apps must attempt to minimize their memory footprint to remain within the available space on the host device. This means purging in-memory caches in response to memory warnings, streaming access to resources on disk (as #CouchDeveloper suggested in a comment), and minimizing the amount of memory used overall.
As an additional complication iOS attempts to keep memory in use. Unused memory is wasted capacity and users may be better served by the OS keeping more applications suspended and in memory rather than terminated. As a result attempting to measure available free memory does not give a meaningful result. As the device runs low on free memory other applications will reduce their use in response to memory warnings or by being terminated completely.
Is there anyway to find the peak memory consumed by the application while running.Normally an application will take some memory and While the application is running it will consume somemore memory and again will release after the operations were done.I want to note that peak memory consumed by my apllication while running(Graphical representation).
In DDMS the heap Tab shows the heap size totally used by the application.But I want how much the app consumed and then released the memory each time while running.Is there any tool or eclipse plugin to track this?Kindly suggest a solution.Thanks.
https://developer.android.com/tools/debugging/debugging-memory.html - you should take a look at this and use the hprof tools to discover your memory issues.