长话短说,我想针对该类测试我的 android.os.Bundle 类的克隆实现,看看哪个更好。我已经知道我的版本可能会更糟,但我想知道会更糟。是否有任何适用于 Android 的基准测试工具可用于查看哪个对象在内存中更大和/或需要更多处理时间来存储/检索值?
TL;博士:
我查看了 android.os.Bundle 类的源代码,我不喜欢它如何存储和返回对象。它只是将它们存储在 a 中HashMap<String, Object>
,然后使用 ClassLoader转换为所请求对象的类(如getString()
或)。getInt()
我觉得这或任何与此相关的类转换都违反了类型安全并在编程级别引入了歧义,这是静态类型旨在防止的,不是吗?
我想创建一个类似的数据容器类,它不会违反类型安全并且不会引入歧义。逻辑上简单但显然效率低下的方法是为我要存储的每个类都有一个 Map 。
我决定的是一个单一HashMap<String, Integer>
的,其中包含我要存储的每个类的各种列表的键索引映射。例如,调用getString(String key)
将从映射中获取与该键关联的整数索引(如果存在),然后尝试获取关联中该索引处的对象ArrayList<String>
。
这里唯一的歧义是返回null
(该类的列表中不存在索引)或正确类的错误对象(存在映射索引但使用该键存储的原始对象在另一个列表中) ,这确实是程序员的责任去检查。
此类对象只是临时容器,用于以标准化方式将数据从一个地方传送到另一个地方。他们不打算留下来。它们的使用方式也与 Bundle 不同,尽管我想要一个像这样的统一数据容器的部分原因是能够轻松地转换为 a Bundle
、JSONObject
、ContentValues
orCursor
和返回。
或许真正的问题是:选角真的有那么糟糕吗,还是我会竭尽全力避免它?我想好的编程确实是在这两种情况下避免歧义的唯一方法。
更新:
看起来 Bundle 仅在从 Parcel 中解包时才使用 Classloader,但它会在每次 put() 调用时调用 unparcel()。检索时,它只是转换为方法返回的类型,在 try-catch 块中为ClassCastException
. 这可能是最简单的方法。