I writing a image compositing app where it should be possible to arrange images on different layers. So what I currently do is to merge (draw one bitmap after another) on a canvas.
The user should be able to remove any of the layers at any time (also undo).
My problem is related to memory management: I fear OutOfMemoryExceptions when keeping every layer as bitmap object in memory. But merging is a problem: As soon as I merge all bitmaps, there is no way to separate them again (obviously).
I was wondering about saveLayer, it seems you can save and restore data, but I don't really understand whether it could be helpful for me.
I thought about reducing the resolution of the images on the layers, but then the question "which resolution is the right one?" pops up. After all the resolution would depend on the (dynamic) amount of layers and the available system memory.
Anyone has a proposal on how to handle this requirement?
For the merging problem, what if you instead had multiple canvases, perhaps as part of a custom ImageView, which you dynamically add as layers in a FrameLayout? The compositing part would then be simply handled by the layout, and you could your make your draggable images appear/disappear without redrawing the unaffected images simply by adding/removing views from FrameLayout.
For the memory issue, I can't think of many ideas except to a) set the max res of each layer to something sensible given the devices screen size, b) experiment with using compressed bitmaps like Bitmap.Config.RGB_565 (with a perhaps unacceptable compromise in color fidelity), c) query the usable heap size and limit the number of layers accordingly.
Related
I am creating a dress up game, and this involves putting lots of images on top of each other. The application by itself can work fast with no lags, but if a slide animation is added to the item to be dressed when the character is fully dressed (10 images or more on top of each other), a bad lag happens. I believe this happens because the OS invalidates all the ImageViews and draws them all again. The images are of png type and they mostly are around 10 kilobytes.
Would using graphics and drawing on the layout make it faster? Or would it be the same thing as setting images from resources?
I can't actually try it right now because it involves a major re-writing of the code.
If you implement the app using OpenGL, it should be more faster than now. Before doing that, you might want to double check that you have all the image resources scaled correctly for the target devices (mdpi, hdpi, xhdpi, and xxhdpi). Scaling up drawables in runtime can cause a significant performance penalty on some devices, especially for animations.
I want to figure out the main effectivity issues of the Android layouts and views. I'm doing a research now but maybe somebody has answers already.
I have a RelativeLayout that is populated with views dynamically. Basically, the application loads a forum thread in XML and then renders the discussion tree so each message is displayed in its own group of views. I've decided not to use WebView because I want to implement some client-side functions that should be easier to do on custom views than on HTML page.
However this approach has a major flaw: it's heavy.
The first problem (which I've solved) was nesting of views. This is not an issue now, my layout is almost flat so the maximum depth is 10-12 (counting from the very top PhoneWindow$DecorView, the actual depth depends on data).
Now I've reached the next limit that is somehow connected to (or caused by) resource consumption of the views. After loading the data, the application hangs for a while to build the layout (creates the views and populates them with the data), and the hang time seems to grow linear with the data size; and if the data is large enough, the view will never appear (eventually the system suggests closing the application because it isn't responding).
Now the questions:
Does memory consumption depend significantly on the view class? In other words, is there any major difference between a Button and a TextView, or an ImageView? I can attach a click handler to any view so they don't differ much in usage.
Do background images affect the performance? If the same image is set in N views, will it make the layout N times heavier? (I understand that this question may look silly but anyway.)
Are nine-patch images significantly heavier than regular ones? What is better: to create N views where each has some background images, or to make one view that is N times wider and has a repeating background?
Given some layouts, what should be optimized first: overall number of views, nesting levels, or something else?
The most interesting. Is that possible to measure or at least estimate the resources consumed by the activity and its views? If I make some change, how could I see that I'm going the right way?
UPDATE
Thanks to User117, some questions that I asked above are now answered. I've used the Hierarchy Viewer and optimized my layout: compared to what I had before, the overall number of views is now reduced almost twice, and the nesting is also reduced.
However the application still hangs on a large forum thread.
UPDATE 2
I've connected the debugger to my device and found that the application gets out of memory.
But what is very unexpected for me is that the error occurs after I populate the layout. The sequence is as follows:
All my views are added. I can see a slight slow down as they are being added.
Almost nothing happens for a couple of seconds. During that time, a few info messages are spawned in the log, they are identical: [global] Loaded time zone names for en_US in XXXXms, the only difference is number of milliseconds.
The out of memory error message is spawned: [dalvikvm-heap] Out of memory on a N-byte allocation (the actual size varies). The long error reporting starts.
What does this mean? Looks like the rendering have its own demands that may be considerable.
UPDATE 3
At last I've found the core issue. Here is a screenshot from my application, see an explanation below the image.
Each message consists of a round button that shows or hides the replies and a red content frame to the right of the button. This is very simple and requires only 6 views including the layouts.
The problem is the indentation with these connection lines that show which message is related to which.
In my current implementation, the indentation is built of small ImageView's, each containing a square image that shows either empty space, or a vertical line, or a T-like connector, or a L-like corner. All these views are aligned to each other within the large RelativeLayout that holds the whole discussion tree.
This works fine for small and medium trees (up to few hundreds of messages), but when I try to load a large tree (2K+ messages), I get the result explained in UPDATE 2 above.
Obviously, I have two problems here. I spawn large number of views that all consume memory, and these views are ImageView's that require more memory for rendering because they render a bitmap and therefore create graphics caches (according to explanation given by User117 in the comments).
I tried disabling loading the images into the indentation views but got no effect. It seems like adding that huge number of views is quite enough to eat all available memory.
My other idea was to create an indentation image for each message that would contain all pipes and corners, so each message would have the only indentation view instead of 10 or 20. But this is even more consuming: I've got out of memory in the middle of populating the layout. (I cached the images in a map so two bitmaps with identical sequence of images weren't created, that didn't help.)
So I'm coming to conclusion that I'm in a dead end. Is it ever possible to draw all these lines at once?
Different View's are different kinds of Object. Some only draw() light weight stuff, some can hold large Bitmap Objects, and handler Objects and so on. So, yes different View's will consume different amount of RAM.
If same Bitmap object is shared among views, There's only one Object in RAM, each View will have a reference variable pointing to that object. But, not so when View draws: Drawing same Bitmap n times at n places on screen will consume n times CPU and generate n different bitmap_cache for each View.
Each side of a 9-patch image is actually bigger by 2 pixels from the original image. They are not much different as a file. When they are drawn, both can be scaled and will take almost equal space. The only difference is that 9-Patch are scaled differently.
Setting the background of the larger, parent view is better when the child views are transparent, and background will show through.
You can save a small image and set a tiled background so that it can fill a large area.
Nesting is to be optimized first, because all of the views might not be visible at a given time, let's say only a few views are visible in scrolling layout. Then you can cut down on total number of views used. Take cues from ListView: Given that user will be only seeing a sub set of total data at a time, it re-cycles the views. and saves a lot of resources.
SDK provides Hierarchy Viewer tool for this purpose. It shows a full tree structure of a running Layout, also places red flags for the sluggish parts of the layout.
A good layout is that which:
Easy to be measured (avoid complex weighted widths, heights and alignments). For
example instead of doing layout_gravity="left" for each each child, parent can have gravity="left".
Has less depth, each overlapping view adds another layer to be composited while screen is drawn. Each nested View Structure, asks for a chained layout call.
Is smart and re-cycles Views rather than create all of them.
Reuses its parts: tags like <merge> and <include>.
Update:
Answers to this question, show many approaches for a tree view in android.
I am developing a 2d android strategy game, it runs on SurfaceView, so I can't(or can I?) use LibGdx's particle system. And I would like to make a raining effect, I am aiming for something like this( http://ridingwiththeriver.files.wordpress.com/2010/09/rain-fall-animation.gif ), I don't need the splash effect in the end (although that would be superb, but probably would take up a lot of system resources). How could I achieve that raining effect? Any ideas?
There's one similar code from JakeWharton called DroidFlake. It seem like snowfall effect but worthy to check DroidFlake
The easiest would be to put the rain drops in a PNG with alpha and display that at the end. You would only need a few frames to make it smooth, but it would eat up a bit of resources if this were a full screen image.
If you cannot afford this, you could put each distinct raindrop in a smaller PNG file with alpha, then display this (these) single PNG(s) multiple times. This would reduce the memory used a lot, although your rendering code will get a bit more complex, and depending on how many drops you have, it might affect performance.
A trade-off between the two would be to have a PNG file that contains more drops, but not for the full screen, and display that a few times.
You could have another frame (or frames) where the raindrop splashed, which you could display before ending the animation of each drop, or you could have the final frame in the large PNG contain the splashes.
There are many ways of doing this. You could create a sprite sheet like:
In that spritesheet, you could simply have a drop of water advance in each frame until it reaches the bottom and you create the splash effect. You then need to be able to animate it (very easy). You can then create multiple instances of the image, or draw the one image multiple times to create the rain storm.
I am developing a 2D game for android using lots of sprites. I am drawing on the screen using OpenGL ES. I separeted the sprites into several pictures (around 7). I read, that loading a picture into memory takes most of the time. Every picture contains a diffrent category of images: for example - background elements, enemy units, etc, etc. I load them in a defined order: background picture first, so background elements are drawn at the bottom, then the enemy units, etc. But what should I do, if I want to draw elements of the background at the top of the canvas. Should I load the picture with background elements twice? Or store that special element in both pictures - the background picture and the picture containg top elements. Or there is a better way? Thanks!
Loading has nothing to do with rendering. As long as you render something after you've loaded it, then you're fine. The order that things get rendered in is not affected by the order you loaded them in.
Now, if it's an issue of memory (ie: you can't load everything at once), then the steps you need to take depend greatly on exactly what you're doing. We can't really give you anything more than general advice, because we don't know everything about what you're doing.
In general, you need to break down your rendered world into chunks that fit in memory. This will put constraints on your design: you can't use stuff (be it backgrounds, enemy units, whatever) from outside of that chunk. Since you're developing on limited platforms, you're just going to have to put up with those constraints.
I'm entirely new to Android development, and I'm interested in making a live wallpaper. I was thinking about looping a set of pictures instead of drawing the animation. Is this a possible approach? If possible is this a suitable or ideal way of doing it, does it eat up memory and would i need images with different resolutions because of the fragmentation?(hundreds of different devices)
Thanks in advance :)
Sure, it should be fairly simple.
The main part of the Wallpaper engine is the Drawing of course. You need to handle the drawing manually, there is no easy way to loop through images... you need to code it. You will have to continuously monitor the time which has passed and adjust the displayed image based on that. You are given a Canvas object to draw to and it is all done during run-time in code.
The Wallpaper engine class has a event called onSurfaceChanged which gives you the width and height of the Surface which you will be drawing to. It will be called everytime the screen dimensions change (like if the phone is put into Landscape mode for instance). You need to have code that will handle any combination of width or height for all the device types out there. You will need to decide if you are going to stretch, center, tile or crop (Or a combination of those) the source images to fit any particular screen size. I would recommend scale to fit so that the image is either taller or wider than the screen and center the image either vertically or horizontally (cropping the extra bits) once that is done. I personally just use one source size and resize it to fit. You can opt to use several source files if you want which is the recommended approach I believe, but it's a little confusing.
I would start by creating a Live Wallpaper which just draws something basic like a shape to the screen. Then work out how to display an custom image and take it from there.
Good luck
You will need to be very careful about memory if taking a frame approach to animation--probably will not be possible to animate full frames--much more practical to move sprites on a background. See, fr'instance: http://davidjhinson.wordpress.com/2010/05/19/scarce-commodities-google-android-memory-and-bitmaps/
what if you have a png frame animation that is set at a certain x and y position that sits in a spot on the background image, both would have to be rescaled