Любые эксперты по Android могут пролить свет на то, почему этот метод может зависнуть?
Когда я приостанавливаю поток и смотрю на стек:
Thread [<13> Thread-15] (Suspended)
DexFile.openDexFile(String, String, int) line: not available [native method]
DexFile.<init>(String, String, int) line: 105
DexFile.loadDex(String, String, int) line: 144
Method.invokeNative(Object, Object[], Class, Class[], Class, int, boolean) line: not available [native method]
Method.invoke(Object, Object...) line: 521
... вы можете видеть, что он висит в нативном методе DexFile.openDexFile, он никогда не возвращается.
Это вызывает серьезные проблемы для приложения, которое мы пишем. Это происходит случайным образом и, таким образом, предполагает наличие какого-либо состояния гонки между несколькими потоками, но я подключаю обнаружение и взаимоблокировки, и, кроме того, я ожидаю, что нативный метод вернет мне что-то, даже исключение было бы неплохо !!
Заранее спасибо
Я использую Android 2.2 Nexus One Device, я развертываю приложение из затмения на устройство. Чтобы быть уверенным, что я полностью удалил приложение и снова включил устройство, я все еще вижу вышеупомянутую проблему в случайном порядке.
ОБНОВЛЕНИЕ: Я повторил попытку на эмуляторе Android 2.3.3 (API 10), и у меня возникла та же проблема. Теперь я убежден, что здесь есть серьезная ошибка. Я создал простой тестовый пример, чтобы показать проблему. По сути, я добавляю один dexified jar в папку активов проекта Android. При запуске я копирую этот файл в область данных приложения. Затем я запускаю x потоков и в каждом потоке загружаю этот файл dexified jar, используя DexFile.loadDex, но давая другое имя выходного файла для сгенерированного оптимизированного файла dex. Если вы выберете x, скажем, 30 потоков, вы почти наверняка увидите, как несколько потоков зависают.
Просто чтобы быть уверенным, что я повторил тест, в котором каждому потоку дается свой уникальный файл dexified jar. Та же проблема возникает.
Единственный вывод LogCat, который я вижу, может дать подсказку о том, что идет не так:
02-23 11: 59: 23.097: DEBUG / dalvikvm (12598): DexOpt: спать на стаде (/data/dalvik-cache/system@framework@core.jar@classes.dex)
02-23 11: 59: 23.138: DEBUG / dalvikvm (12602): DexOpt: спать на стаде (/data/dalvik-cache/system@framework@core.jar@classes.dex)
02-23 11: 59: 23.357: DEBUG / dalvikvm (12602): DexOpt: спать на стаде (/data/dalvik-cache/system@framework@framework.jar@classes.dex)
02-23 11: 59: 23.419: DEBUG / dalvikvm (12598): DexOpt: спать на стаде (/data/dalvik-cache/system@framework@framework.jar@classes.dex)
02-23 11: 59: 23.528: DEBUG / dalvikvm (12608): DexOpt: спать на стаде (/data/dalvik-cache/system@framework@core.jar@classes.dex)
02-23 11: 59: 23.577: DEBUG / dalvikvm (12598): DexOpt: спать на стаде (/data/dalvik-cache/system@framework@services.jar@classes.dex)
02-23 11: 59: 23.698: DEBUG / dalvikvm (12606): DexOpt: спать на стаде (/data/dalvik-cache/system@framework@core.jar@classes.dex)
Другая интересная вещь: в качестве примера у меня есть файл dexified jar
myjar.jar (размер 5031)
Каждый поток, открывающий этот dex-файл, создает файл
myjar.jarX.dex (где X - уникальное целое число для каждого потока) (размер 4152)
Потокам, которые не завершают вызов DexFile.loadDex, все же удалось создать файл myjar.jarX.dex, но файл имеет размер 3496
Я полагаю, что в глубинном коде Dalvik есть некая форма расы. Это большой шоу-шоу для нас. Любые предложения, как лучше поступить?