title: How to get the in-memory size of an object in Android, or performance benchmarks?
body: <p>Long story short, I want to test my clone implementation of the android.os.Bundle class 
  against that class to see which is better. I already know my version is likely going to be worse but I want to know <em>how much</em> worse. Are there any benchmarking tools out there for Android that I can use to see which object is bigger in memory and/or takes more processing time to store/retrieve values?</p>
  
  <p>TL;DR:</p>
  
  <p>I looked at the source code for the android.os.Bundle class, and I don't like how it stores and returns objects. It just stores them in a <code>HashMap&lt;String, Object&gt;</code> and then casts to the requested object's class (like <code>getString()</code> or <code>getInt()</code>) using a ClassLoader. I feel that this, or any class casting for that matter, violates type-safety and introduces ambiguity at the programming level, which is what static typing aims to prevent, is it not?</p>
  
  <p>I want to create a similar data container class that doesn't violate type-safety and doesn't introduce ambiguity. The logically simple yet obviously inefficient way would be to have a Map for each class I want to store.</p>
  
  <p>What I decided on was a single <code>HashMap&lt;String, Integer&gt;</code> that contains key-index mappings for an assortment of Lists for each class I want to store. For example a call to <code>getString(String key)</code> will get the integer index associated with that key from the map if it exists and then try to get the object at that index in the associated <code>ArrayList&lt;String&gt;</code>.</p>
  
  <p>The only ambiguity here would be returning either <code>null</code> (where the index doesn't exist in the List for that class) or the wrong object of the right class (where the mapped index exists but the original object stored with that key is in another List), which is really the programmer's responsibility to check for. </p>
  
  <p>Objects of this class are only temporary containers, used to ship data from one place to another in a standardized fashion. They're not meant to stick around. They're also not used in the same manner as Bundles, although part of the reason I want a unified data container like this is to be able to easily convert to a <code>Bundle</code>, <code>JSONObject</code>, <code>ContentValues</code> or <code>Cursor</code> and back.</p>
  
  <p>Or maybe the real question is: is casting really all that bad, or am I just going to extreme efforts to avoid it? I guess good programming is really the only way to avoid ambiguity in either case.</p>
  
  <p>Update:</p>
  
  <p>It looks like Bundle only uses the Classloader when it's unpacking itself from a Parcel, but it makes a call to unparcel() with every put() call. When retrieving it simply casts to the type that the method returns, inside a try-catch block for <code>ClassCastException</code>. That's probably the simplest way to do it.</p>