I have a bit of a problem with a game I am working on. The game runs very well on most devices, except Samsung Tab and Galaxy S (it could be more, but I have reports about those two).
What happens on those devices is that the app appear extremely sluggish for 15s-120s then speeds up dramatically (from 5fs to 30fps, which is the normal performance elsewhere). This seems to happen only when the game is installed (or reinstalled).
What could cause that problem?
On the first run, we create a couple of files on the SD card to store settings, but I doubt that could have a lasting effect?
The JIT takes a whiles to kick in? But it runs perfectly fine on other platform with and without the JIT. Admitedly, by disabling the JIT, it appears that the slowdown will last longer on the Tab, so there may be an effect.
Could it be that the device tries to rearrange out the objects are laid out in memory? The game does take quite a bit of space in memory.
Is there any known problem with Samsung devices? (It appears to be a problem on those only)
Any help is welcome.
You could try to call dalvik.system.VMRuntime.getRuntime().setMinimumHeapSize() early in your app with about the size of the heap while your game runs. This will allocate the target heap size at once and avoid reallocs.
I know it is deprecated but who cares if it helps.
Related
I have been playing with optimizing my app, and I see that there are some general ideas on how much memory it should use... I'm running between 70-80Mb right now, is that a crazy number or just a little on the heavy side?
My second question is about the memory I am using. About 42Mb is taken up by graphics, whether I run the app with the layout graphics or run it without setting any views... any ideas on where to look? I feel like it is the theme, but I am not sure how to test that.
I've been searching for days to figure out why it uses so much and cannot figure it out. It remains constant regardless of which activity I am on, any ideas are welcome!
UPDATE:
I ended up running it on an emulator and got about 26Mb, more what I was expecting, but it runs at 70Mb with the 42Mb of graphics on the actual device.
The emulator allows for a 384Mb app after getting memoryclass information, while the device only allows 256Mb... the emulator has more storage and runs more efficiently.
The emulator is Android 8.1 27api while the device is Android 7.0 24api.
Tried on an older Android 5.1.1 api 22 below also.
Any ideas?
I have another question with about why the emulators have a such a difference in performance here if you know the answer on that, but I wanted to keep these questions separate: Other Question
Android Studio has an awesome tool called Memory Profiler. It helps you analyze possible memory leaks and see which calls are using up the most memory. You can even pause the processor and 'zoom in' to deep dive on the call stack.
You can use LeakCanary A memory leak detection library for Android and Java. Maintain by Square. This is one of the best developer's Tool for memory optimization and detecting leaks.here
Its an old post, but still in most of the places i found out that an android app gets around 16-32 MB memory
But when i check android Profiler, it says that my app is currently using around 350 MB memory on Samsung Galaxy S7.
I get OutOfMemoryException on my app a couple of times, I was curious why its happening. When i dig down a little i found out about 16-32 MB limit, but in actual my app is using 350 MB
I want to know how much memory a normal android phone gives to each app, or is it a variable number, and if no app is running android will not give outOfMemoryException, and if so many apps are in stack then there is a higher chance of OutOfMemoryException
But again there will be some limits.
Android devices vary significantly now that the OS is getting older. You should definitely aim for under 32mb limit if you want your app to work on lower end devices to be safe. Unless you are loading some very large images it sounds like your code is leaking memory.
Start by removing any image (or other asset) loading from your app to see if you still have problems.
If you do, check out LeakCanary, and when you find the leaks learn about them and why they are happening because it will help you immeasurably to become a better Android programmer. One of the chief ways apps leak memory is by passing an Activity context to a long running task :)
my first android game it's almost done, and I'm on the way to publish it on the play store.
Today I tested it on some friends phone and it worked on all except for a samung a5. On this phone the meshes flicker, apper and disapper and look deformed. This when playing game where I use a lot of frame buffer, in the main menu where there is a simpler animation everything look right.
The game is developed with libGdx and use some custom shader. I've tested it on 8 other different device without no issue (excepect for low frame rate on samsung galaxy tab s4).
I ask yours advise:
1) what should I start to check to find the problem with a5?
2) do you think I should delay the publication until the bug it's solved ora I should publish it excluding A5 ( or maybe all devices with similar GPU) from compatibility list?
My big problem is that at the moment I don't have the device with me (it's the personal phone of a friend of mine...) and probably I will have it for only a limited amount of time, so I want to be preparated to avoid to lock the device for too much time to my friend.
Thanks to all!
First, I'd make sure you don't have any OpenGL errors - add calls to glGetError and validate frame buffers and shader programs, you can do this without the device and adding extra asserts like this is always worthwhile (assuming you don't already have them). Next, try using the tools provided by the GPU manufacturer. In your case the snapdragon profiler. To minimize the time you'll be using your friends device, get the tools installed ahead of time and if you have access to another Qualcomm device, then use that to familiarize yourself with the software. With luck the cause of problem might become immediately obvious. If not, then it's just a binary search of disabling parts of your code until you narrow it down to a particular shader/draw call, then examine/tweak that to figure out what bit is going wrong.
That's a tough call. If it's a driver bug, then it might only occur on particular revisions. Some A5 devices might work if they're on different versions of Android from your friends device. That said, the A5 is relatively recent and Samsung/Qualcomm drivers tend to be pretty solid IME, so it's more likely an error in your code that happens to only be exposed on certain devices. Personally I would delay release unless your release strategy is timing sensitive, from the limited data you have, your game doesn't work on >10% of devices.
I am developing a game application under Android built for SDKs >= 8. I always tested it under an Android 2.2 phone and never had a problem. When I moved to a Nexus phone with ICS mounted on I started having problems with the heap memory allocation. I tried to remove everything in the app to see where I was having memory leak problems or strange allocations (using both DDMS and MAT under Eclipse) until I decided to just start an empty activity and to do nothing more.
Under Android 2.2 the heap size at startup is about 2.0MB, while under Android 4.1 is about 11MB. Why is there such a great difference?
More, when I play my app the heap size on ICS, the garbage collector quickly starts freeing memory and the whole application becomes slow and with a very low FPS. Under Android 2.2 everything is really smooth and clean, without any single problem.
Does anyone can suggest me where's the difference between these two systems? I don't want to talk about my app implementation (I already spent 2 weeks optimizing code, memory allocation and retention and everything else. Can't do much more), but I want to understand where all that memory goes just at app startup. Also, ICS seems to require much more memory to load and retain bitmaps and drawables.
Okay, I may be late to the party, but I figured out the root of your (and my) problem.
Before Android 3.0 (not sure if this was in the entire 1.x/2.x series) all bitmap related memory was not stored on the heap. So with 3.0 they started locating everything on the heap. I am not sure why an empty application takes up 11MB, I can only guess it is related to the default Android bitmaps used in applications.
Now there is another problem: in earlier versions of Android, there was only a 'drawable' folder, not a 'drawable-hdpi', 'drawable-mdpi' etc... folder. For some reason, when loading in a image from the 'drawable' folder, it takes up HUGE amounts of space. The solution is to add different resolution variants of your images to all the drawable-Xdpi (where X is l,m,h or xh) folders. It reduced my starting heap size from around 26MB to a good 16MB. Even if you don't resize them, and just copy-paste them into the folders, it will still result in quite a significant change in Bitmap sizes.
I hope I help some people by posting this.
-Z
Developed a application of size 40MB. I need to test it for all screen support but the android emulator really a bad choice(I feel... ). It gives Insufficient memory error almost every time). How developer test their application?
One more Question
I have designed app for four different layout(normal,small,large and xlarge). Will every device(In future) satisfy these layout params?
And i faced a real problem that i tested my app in Sony xperia minpro(Small screen 240*320 2.4inch) and in Samsung galaxy 5(smallscreen 240*320, 2.8inch) but the layout is overlapping in samsung device. This can be a serious problem , actually we cant check our app in every device.. that is impossible too.
TIA
40MB is way too big for an Android application. Many users will have problems installing the app on their devices. You should consider moving some resources out of the application and downloading them either on demand or on first app run.
The list of layout types (normal, small, large, xlarge) is definitely not final, for there quite possibly will be even larger screens (xxlarge) or tiny ones (xsmall?).
Developed a application of size 40MB. I need to test it for all screen
support but the android emulator really a bad choice(I feel... ). It
gives Insufficient memory error almost every time). How developer test
their application?
You can configure the emulator with any amount of memory you wish, including an emulated SD card so memory shouldn't be a problem. However, 40MB is quite big so you may be hitting the package size limit.
One more Question I have designed app for four different
layout(normal,small,large and xlarge). Will every device(In future)
satisfy these layout params?
You're asking us to predict the future - there's no way we can know what Google are planning if they haven't already announced it though I would suggest that there will never be a commitment to keep screen sizes or resolutions static - technology constantly evolves and specs that are OK for today, will not be OK for tomorrow.
I have seen dictionaries weighing in at 40Mb, best practise is to download the database as a separate file. Some graphically intensive games approach that size. If you want to emulate many Android devices make sure your PC is up to snuff and you have the latest SDK.
How developer test their application?
You do not have so many choices: you have to use as many (and different) physical devices as you can, from different vendors and technical specifications (screen, etc), to try to detect as many specific bugs as possible.
This is difficult, as you are often limiten to a few physical devices.
To give you examples, I recently struggled with the Camera, for a bug happening with Motorola Defy only. I am currently struggling with the Camera, but only for Samsung Galaxy this time.
When you find a specific bug, try to fix it "the general way": instead of detecting the vendor/version of the device to write specific code for it, try to enhance your code in a way it will work for all tested phones. So far, I never had to write anything specific to a given device. The bugs I encountered were always tied to a permissivities or particular cases that could be handled by making the common code more complete or resiliant. Let's say by "making as less assumptions as possible" knowing that we tend to make assumptions without meaning it.
On top of testing on as many physical devices as possible, create emulators. You can parameter them to have different screen layouts, different embedded hardware, memory, etc. And on top of the default emulator that comes with the Android distribution, you also have emulators provided by the devices vendors and that reproduce the specificity of these devices. For example, Samsung released a Galaxy Tab emulator. Sony Ericsson released a EDK Cellphone emulator. You can get them thru the regular android distribution update workflow.
Will every device(In future) satisfy these layout params (normal,small,large and xlarge)?
Yes, as Android distributions are backward compatible. Any of these layout will still be supported in the future, but may become 'deprecated' (so not recommended, but still working), and new layout types will certainly be created.