Java – Android heap 1-byte array type is very large
So, I'm studying games in Android. I'm checking the heap and allocation to see if there's any problem with memory and what's not When I get to the heap, it tells me that it has allocated 33 MB for my game and 31 MB for the 1-byte array type I experienced trying to figure out why it was so big, but I had no luck and didn't know what to look for Does anyone have any ideas? Thank you in advance! If you need more information, please let me know
take
Edit:
I'm not very clear about what happened. Sorry, it was very late when I released it
Basically, I made a simple multi touch checker. The following code, when I ran it, I decided to check the heap As I said above, it's very big for what I'm doing, just draw a point and stick a circle on it
public void onDraw(Canvas c) { c.drawColor(Color.BLACK); Point[] touchPlacesHolder = touchPlaces; for(int i = 0; i < touchPlacesHolder.length; i++) { c.drawCircle(touchPlacesHolder[i].x,touchPlacesHolder[i].y,100,paint); } } public boolean onTouchEvent(MotionEvent event){ touchPlaces = new Point[event.getPointerCount()]; for (int i = 0; i < event.getPointerCount(); i++) { touchPlaces[i] = new Point((int) event.getX(i),(int) event.getY(i)); } return true; }
I'm running this activity and linking it to another button through intent. The code is as follows I'm not sure if it's related to the way I link 2. Maybe I caused a memory leak there
public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); final Window win = getWindow(); win.setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,WindowManager.LayoutParams.FLAG_FULLSCREEN); requestWindowFeature(Window.FEATURE_NO_TITLE); setContentView(R.layout.main); final Button newGame = (Button) findViewById(R.id.new_game_button); newGame.setOnClickListener(new OnClickListener() { public void onClick(View v) { // Perform action on clicks Intent intent = new Intent(v.getContext(),Platformer.class); startActivity(intent); } }); final Button levelEditor = (Button) findViewById(R.id.level_editor); levelEditor.setOnClickListener(new OnClickListener() { public void onClick(View v) { Intent intent = new Intent(v.getContext(),LevelEditor.class); startActivity(intent); } }); }
As you can see, in the second code I show, I have another activity attached to the button, but I think I'll ask a simpler example because they all use the same amount of memory, even if one uses a bitmap and the other is not
So, basically, my question is, why does a simple thing like this need such a large pile, and why does it use so many things, such as cutting a rope that is only half the size thank you!
Edit again:
I just changed the list to start with the simplest list, then left the main menu and another activity exited The 13 MB stack of the multi touch tester uses about 12 MBS I did the same thing for the menu. It allocated about 25 MB and used most, while other classes I didn't display also used about 25
So, I guess the extra memory to save the menu in memory is using it, but I don't know why it uses so much memory on the menu first Do you know how to fix it or how to save it in memory?
Solution
Possible optimizations of speed and memory:
1. How to use a fixed size maximum touch event array and update it instead of creating a new event at a time? It's a single thread that handles both, so you shouldn't worry about it
2. Verify only the areas that should be updated This increases speed
3. Update touch events only before you know you want to update
4. Not sure what the game is, but you can use a fixed size bitmap and write it instead of saving touch events
5. Because this is a game, most of the memory may be used for images, sound and video Try to check if this is a problem Because the class you are checking is a 1 - byte array, it may be an image For more information about loading large resources, check: @ h_ 502_ 52@http ://developer. android. com/training/displaying-bitmaps/index. html
Having a large heap size may indicate that you have created many small objects or some large objects in a short time, because GC takes some time to perform some operations