Android Heb's 1-byte array type is extremely large

Question

So, I am working on a game in android, and I looked through the heap and allocations to see that something is wrong with the memory and what is not. When I got to the heap, they told me that he allocated 33 mb for my game, and 31 mb was allocated for 1-byte array types. I tried to understand why it was so great, but I was not lucky, and I do not know what to look for. Does anyone have any ideas? Thank you in advance! Let me know if you need more information.

Will

Edit:

I did not quite understand what was happening, sorry, it was too late when I posted this.

Basically, I made a simple multitouch checker, the code is below, and when I ran it, I decided to check a bunch. As I said above, this was very great for what I was doing, just getting points and holding a circle on it using draw

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 run this action by associating it with a button on another using intent, the code below. I'm not sure if it has anything to do with how I linked 2 or not, maybe I caused a memory leak.

 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, I have one more activity related to buttons in the second bit of code that I showed, but I decided that I would ask for a simpler example, because they both use the same amount of memory, although one of they use raster images, but the other is not.

So basically, my question is: why is it just as simple as it requires such a large heap, and why use it so much when something much more complicated, like cutting a rope, is about half the size. Thanks!

Change again:

I just changed the manifest to start with the simplest, and left the main menu and another action. The multitouch tester had about 12 mb, used in a heap of 13 mb. I did the same for the menu, and it had about 25 mb, and he used most of it, and the other class, which I did not show, used about 25.

So, I assume that the extra memory is used from it, keeping the menu in memory, but I'm not sure why it uses so much memory for the menu in the first place. Any idea how to fix this or fix the way it is stored in memory?

Answer 1

possible optimizations for speed and memory:

1. How about using a fixed-size array for max touch events and updating it, rather than creating a new one each time? it is the only thread that handles both, so there should be no problem to worry about it.

2. Check only those areas that need updating. it can increase speed.

3. Update touch events only before you know that you want to update.

4. Not sure what a game is, but you can use a bitmap with a fixed size and write for it, rather than save touch events.

5. Since this is a game, most of the memory is probably used for images, sounds, and videos. try checking if this is a problem. since the classes you tested are 1-byte arrays, this might be the case of images. for more information on loading heavy resources check: http://developer.android.com/training/displaying-bitmaps/index.html

having a large heap size may indicate that you are creating many small objects or several large objects in a short time, since gc takes some time until it does something.