i’ve got some issues with the memory usage of my app on mobile devices.
On android it uses about 150-200 MB, what i think is already to much (apk size 20 mb). And on iOS the RAM explodes, because the app is loading 500+ MB in it before the app crashes.
I think it’s caused by the way I use Sprites and Textures in Unity. I’ve got a lot of Sprite Sheets (2k square, true color) in my project and use many sprites for displaying them on Unity GUI. For that i convert them into Texture2D’s at runtime (pixel per pixel operation for each sprite to texture2d at the start of the scene). Is this that bad for the performance and ram usage? Should i use individual texture files instead of Sprite Sheets for GUI?
I would be very happy if someone could tell me a better way do this. And other optimization tips would be also appreciated (especially for iOS).
It sounds like it’s your initial conversion process that is shooting up your ram usage which we could probably improve, though I am not certain as to why it is required in the first place, perhaps you could elaborate. If you are using the Unity GUI and that require textures, why not simply use textures directly in the format you require instead of doing the conversion?
If you are using the sprite sheets in other parts of your game, perhaps it might be better to look at constructing your GUI through the sprite system and sharing the resources.
Let’s ignore that for now though and try fix the initial load up. It’s difficult to figure out where your issue lies without seeing the code responsible, but I am going to make an assumption that your massive usage buildup is from inefficiently loading/unloading resources during the conversion process.
It may be best to store the sprites in resources and load them one at a time for conversion.
Before I start, I know nothing about Unity’s GUI. I use NGUI exclusively. But besides that…
How are you creating Texture2Ds? Can’t you use the texture attached to the sprite without having to recreate it?
Is there some reason you need to recreate them? (Unity’s GUI can handle packed atlases, right?)
Do you need all the sprite atlases at once? You can split your game into separate scenes which makes it easier to load only the textures you need now and unload any that are no longer being used.
EDIT:
I get the impression it’s difficult and hacky to get packed atlases working with Unity’s GUI. Which shocks me. Individual textures would load faster and use less RAM, but your draw calls go up and slows down your frame rate. Otherwise what Kalekin suggests is good, release the texture after your done with each one.
Also, might be worth moving away from Unity’s GUI, though I’ve been hearing for over a year now that they’re completely overhauling the GUI…
The problem is that I’m using the sprites and the textures in the same scene.
It’s actually for a character customization where you have a scrollview (using textures) at the bottom and the character in the middle of the screen (using sprites).
At the beginning of this character customization scene i’m loading about 100 sprites into textures (256 x 256 px loop for each, because unity has no own spirte to texture method).
Some of the Sprites could be in textures directly in the format, but not those I also use for the character.
So i put all the GUI on the sprite sheets too to make the app build smaller.
@Kalekin
Thanks for the advice with the resources thing.
@GarthSmith
My game is already splitted into scenes (Logo/Startup, Main Menu, Character Customization, Intro, Game… etc).
Edit: I’ve read your edit now. Yea, it’s kinda tricky to get sprites on GUI. Im waiting for the unity 5 release and the new gui system. At the moment i can’t afford nGUI
@DennG , in your case it sounds like the best thing to do may be to move away from the Unity GUI. If you already have the resources being used as sprites, it seems silly to duplicate their footprint to just to use them somewhere else. My personal approach, short of getting some 3rd party plugin, would be to build the UI elements using Unity’s sprites and merely share the resource between your world and ui view. It’s going to be a bit of a pain building your own scroll functionality and the like though, not sure what else to advise short of having a much more in depth view of your current method…
The only one I have experience with is NGUI, and it isn’t fantastic. Just about every 3rd party plugin I’ve ever used has some painful pitfalls once you start getting into production code. I would setup my own rudimentary form of UI management, which may or may not be feasible depending on the feature set you are looking to create. Otherwise it may mean needing to do some clever resource juggling and simply sticking with your current method. I can’t give advise on the resource juggling without having hands on experience with your requirements though. Good luck!