Я обнаружил, что о моей проблеме много раз сообщалось в Интернете, но я не нашел правильного объяснения по этому поводу.
В моем Galaxy Note, когда я выхожу из программы, у меня есть некоторыевремя такого рода сообщения в le logcat.
threadid=3: reacting to signal 3
Wrote stack traces to '/data/anr/traces.txt'
Я не могу получить доступ к файлу.В представлении DDMS ничего не отображается в Проводнике.
Я прочитал в Интернете, что ANR (приложение не отвечает) было связано с длительным процессом Activity.Но в моем случае моя деятельность не делает ничего особенного.
Я использую SurfaceView, который запускает 3 потока.Один из них может занять много времени (1 или 2 секунды) в начале приложения (он читает файлы больших данных из sdcard), но в конце ничего не делает при выходе.
Iможно увидеть 10 процессов в представлении DDMS, но я не знаю, какой поток # 3!Так что я не знаю, является ли это одним из потоков, которые я запускаю, или это поток Android.
Больше, чем нахождение проблемы, я хотел бы понять, что является сигналом 3. Когда произошел этот король проблемы,Это происходит только из-за того, что процесс не отвечает, или из-за другой проблемы?Я тестировал свой родной код под Linux (beagleboard).Нет утечки памяти и ошибки сегментации.Почему эта проблема возникла только при выходе из приложения (и только иногда).Означает ли это, что уничтожение моего потока некорректно?
Я использую этот код
public void surfaceDestroyed(SurfaceHolder holder) {
boolean retry = true;
while (retry) {
try {
thread.join();
retry = false;
} catch (InterruptedException e) {
// try again shutting down the thread
}
}
}
У меня также есть специальный код в onDestroy моей Деятельности.
Этот код делает некоторый нативный код бесплатным.Поскольку это код на С ++, он вызывает весь деструктор моих объектов.Я не знаю, является ли это разрушение длительным, но я полагаю, что оно не должно занимать более 1 мс.
Хорошо.Я работаю над этой проблемой уже 1 неделю.Следующим шагом для меня, если я не понимаю проблемы, будет перезапуск нового проекта и импорт моего кода, часть за частью, чтобы проверить, когда проблема действительно произошла.