You should consider using the MIDP protobuf code, which is what is used by various Google apps:
http://android.git.kernel.org/?p=platform/external/protobuf.git;a=tree;f=src/com/google/common/io/protocol;h=44814a7cc40a99cf6a866e219793976de8f283a7;hb=HEAD This is much more appropriate for Android. (Note this this is not part of the platform, so you will want to link it into your app in a different namespace.) On Thu, Jul 23, 2009 at 2:30 AM, Micah <[email protected]> wrote: > > It takes 20 seconds to load the test case class on an ADP1. :( If > anyone has any ideas I'm open to trying things out or giving out the > test case source code to look at. I don't know what Protocol Buffers > does that is causing this, but if I'm not mistaken Protocol Buffers > are used internally by the OS so my thought is that someone somewhere > knows the answer. > > On Jul 22, 2:05 pm, Micah <[email protected]> wrote: > > Unfortunately, this doesn't seem to fully resolve my issue. I have > > created a very simple repro case that causes the stall to occur (let > > me know if anyone wants the source / APK). In the test, it will > > eventually finish but it takes ~10 seconds just to make the call: > > > > Class.forName("com.zoltu.AndroidTest.Messages.Sample") > > > > On the plus side, the sample code isn't deadlocking, but it looks like > > I'll still need to test on a physical device to see if it takes a > > noticeable amount of time there like on the VM. > > > > On Jul 22, 10:49 am, fadden <[email protected]> wrote: > > > > > > > > > On Jul 21, 10:56 pm, fadden <[email protected]> wrote: > > > > > > The bug is that, while generating the list of declared methods, the > VM > > > > would initialize classes found in method arguments. Those classes > > > > shouldn't be getting initialized at that point, and initialization > > > > ordering problems ensue. > > > > > I got a copy of the APK (thanks!) and poked at it. I believe this is > > > the same bug. > > > > > When the app launch stalled a sent the process a "kill -3" and pulled > > > the stack trace out of /data/anr/traces.txt. The two interesting > > > threads are: > > > > > "main" prio=5 tid=3 WAIT > > > | group="main" sCount=1 dsCount=0 s=N obj=0x4001d520 self=0xbc60 > > > | sysTid=1086 nice=0 sched=0/0 handle=-1343996920 > > > at java.lang.Class.getDeclaredMethods(Native Method) > > > - waiting on <0x1a8598> (a java.lang.Class) > > > at java.lang.ClassCache.getDeclaredPublicMethods(ClassCache.java: > > > 166) > > > at java.lang.ClassCache.getDeclaredMethods(ClassCache.java:179) > > > at java.lang.ClassCache.findAllMethods(ClassCache.java:249) > > > at java.lang.ClassCache.getFullListOfMethods(ClassCache.java:223) > > > at java.lang.ClassCache.getAllPublicMethods(ClassCache.java:204) > > > at java.lang.Class.getMethod(Class.java:1006) > > > at com.google.protobuf.GeneratedMessage.getMethodOrDie > > > (GeneratedMessage.java:900) > > > ... > > > > > "Graphics" prio=5 tid=19 WAIT > > > | group="main" sCount=1 dsCount=0 s=N obj=0x43748ef8 self=0x1a4878 > > > | sysTid=1094 nice=0 sched=0/0 handle=1722776 > > > at com.ZZZ.Level$Map.<clinit>(Level.java:~1978) > > > - waiting on <0x146768> (a java.lang.Class) > > > at com.ZZZ.Level$LoadedAnnouncement.<init>(Level.java:-1) > > > at com.ZZZ.Level$LoadedAnnouncement.<clinit>(Level.java:2586) > > > at java.lang.Class.getDeclaredMethods(Native Method) > > > at java.lang.ClassCache.getDeclaredPublicMethods(ClassCache.java: > > > 166) > > > ... > > > > > The're both under getDeclaredMethods, and they're both waiting on a > > > Class object monitor (but not the same class). The Graphics thread is > > > doing a couple layers of class initialization that it shouldn't be > > > doing at that point. It's possible we've deadlocked on class init. > > > > > I tried it twice and ended up in the exact same place both times. > > > With the bug fix in place it started up every time. > > > > > This problem will go away in a future release, but for now you can > > > work around it by forcing initialization to happen earlier. The > > > easiest way to do this is to call Class.forName(String className) > > > early in the app start sequence. Start with Level$Map and Level > > > $LoadedAnnouncement and see if that cures it. > > > > > For anyone building their own VM, you can see the patch inhttp:// > code.google.com/p/android/issues/detail?id=3005. > > > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
