谷歌地图Android V2 - 调试时的空白屏幕(Google Maps Android V2 - Blank Screen When Debug)

 tl; dr：您似乎在Groovy的运行时参数重载评估中发现了一个错误。 
 
 回答： 
 
 map[gString]在运行时通过Groovy的运算符重载机制直接计算为map.getAt(gString) 。 到目前为止，这么好，但现在一切都开始出错了。 Java LinkedHashMap类在其类型层次结构中的任何位置都没有getAt方法，因此Groovy必须使用动态关联的mixin方法（实际上该语句有点颠倒。在类层次结构中使用声明的方法之前， Groovy使用mixin方法。） 
 
 因此，长话短说，Groovy解析map.getAt(gString)以使用类别方法DefaultGroovyMethods.getAt() 。 轻松，对吧？ 除了这个方法有大量不同的参数重载，其中有几个可能适用，特别是考虑到Groovy的默认参数强制。 
 
 不幸的是，Groovy选择DefaultGroovyMethods.getAt(Object,String)而不是选择DefaultGroovyMethods.getAt(Map<K,V>,K) ，这似乎是一个完美的匹配，它将GString键参数强制转换为String 。 由于实际的键实际上是GString ，因此该方法最终无法找到该值。 
 
 对我来说真正的杀手是，如果参数重载决策是直接从代码执行的（而不是在运算符解析和类别方法选择之后），那么Groovy会做出正确的重载选择！ 也就是说，如果替换此表达式： 
 
map[gString]
 
 用这个表达式： 
 
DefaultGroovyMethods.getAt(map,gString)
 
 然后正确解析参数重载，找到并返回正确的值。 

tl;dr: You seem to have discovered a bug in Groovy's runtime argument overloading evaluation.
 
Answer:
 
map[gString] is evaluated as map.getAt(gString) at runtime straightforwardly via Groovy's operator overloading mechanism. So far, so good, but now is where everything starts to go awry. The Java LinkedHashMap class does not have a getAt method anywhere in it's type hierarchy, so Groovy must use dynamically associated mixin methods instead (Actually that statement is sort of reversed. Groovy uses mixin methods before using the declared methods in the class hierarchy.)
 
So, to make a long story short, Groovy resolves map.getAt(gString) to use the category method DefaultGroovyMethods.getAt(). Easy-peasy, right? Except that this method has a large number of different argument overloads, several of which might apply, especially when you take Groovy's default argument coercion into account.
 
Unfortunately, instead of choosing DefaultGroovyMethods.getAt(Map<K,V>,K), which would seem to be a perfect match, Groovy chooses DefaultGroovyMethods.getAt(Object,String), which coerces the GString key argument into a String. Since the actual key is in fact a GString, the method ultimately fails to find the value.
 
To me the real killer is that if the argument overload resolution is performed directly from code (instead of after the operator resolution and the category method selection), then Groovy makes the right overload choice! That is to say, if you replace this expression:
 
map[gString]
 
with this expression:
 
DefaultGroovyMethods.getAt(map,gString)
 
then the argument overloading is resolved correctly, and the correct value is found and returned.