我是ORMLite的主要作者,它使用类上的Java注释来构建数据库模式。我们的程序包最大的启动性能问题是在Android
1.6下调用注释方法。直到3.0我都看到了相同的行为。
我们看到以下简单的注释代码 难以置信地
占用大量GC,这是一个实际的性能问题。在快速的Android设备上,对注释方法的1000次调用几乎耗时一秒。Macbook
Pro上运行的相同代码可以同时进行2800万次(原文如此)调用。我们有一个包含25种方法的注释,并且我们希望每秒进行50种以上的注释。
有谁知道为什么会这样,是否有任何解决方法?在缓存此信息方面,ORMLite当然可以做一些事情,但是我们可以做些什么来在Android下“修复”注释吗?谢谢。
public void testAndroidAnnotations() throws Exception {
Field field = Foo.class.getDeclaredField("field");
MyAnnotation myAnnotation = field.getAnnotation(MyAnnotation.class);
long before = System.currentTimeMillis();
for (int i = 0; i < 1000; i++)
myAnnotation.foo();
Log.i("test", "in " + (System.currentTimeMillis() - before) + "ms");
}
@Target(FIELD) @Retention(RUNTIME)
private static @interface MyAnnotation {
String foo();
}
private static class Foo {
@MyAnnotation(foo = "bar")
String field;
}
这将导致以下日志输出:
I/TestRunner( 895): started: testAndroidAnnotations
D/dalvikvm( 895): GC freed 6567 objects / 476320 bytes in 85ms
D/dalvikvm( 895): GC freed 8951 objects / 599944 bytes in 71ms
D/dalvikvm( 895): GC freed 7721 objects / 524576 bytes in 68ms
D/dalvikvm( 895): GC freed 7709 objects / 523448 bytes in 73ms
I/test ( 895): in 854ms
编辑:
@candrews指出正确的方向后,我在代码中做了一些戳记。性能问题似乎是由中的一些糟糕的总代码引起的Method.equals()。它同时调用这toString()两种方法,然后进行比较。每次toString()使用StringBuilder一堆追加方法时都没有很好的初始化大小。在做.equals比较的字段将显著加快。
编辑:
我得到了一个有趣的反射性能改进。现在,我们使用反射在AnnotationFactory类内部进行窥视,以直接读取字段列表。这使反射类对我们来说快了20_倍_ ,因为它绕过了使用该method.equals()调用的调用。这不是通用解决方案,但这是ORMLite
SVN存储库中的Java代码。