GREF увеличение / уменьшение многопоточного сервиса (aidl) - что это значит?

У меня есть активность Android и сервис, реализованный с помощью aidl. Работает как чемпион, у меня есть настройка обратного вызова для передачи некоторых потоковых уведомлений обратно в пользовательский интерфейс, и это, кажется, работает нормально, за исключением большого количества

GREF увеличено до 101, 201,301,401, 501 ... и т. Д., И GREF уменьшился. Я провел поиск в Интернете и обнаружил, что это связано с глобальными ссылками.

08-17 02:31:19.735: DEBUG/dalvikvm(2558): GREF has increased to 301
...
08-17 02:31:25.823: DEBUG/dalvikvm(2558): GREF has increased to 401
...
08-17 02:31:36.772: DEBUG/dalvikvm(2558): GREF has increased to 501
...
08-17 02:31:42.694: DEBUG/dalvikvm(2558): GREF has increased to 601
...
08-17 02:31:48.695: DEBUG/dalvikvm(2558): GREF has increased to 701
... 
08-17 02:31:59.883: DEBUG/dalvikvm(2558): GREF has decreased to 599
08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 499
08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 399
08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 299
08-17 02:31:59.912: DEBUG/dalvikvm(2558): GREF has decreased to 199

Я провел некоторые поиски и увидел, что большинство замечаний по этому вопросу довольно старые. Меня беспокоит то, что я правильно внедряю свой клиент / сервис и хотел знать, как я могу отследить, что вызывает рост GREF. Любые мысли / предложения приветствуются. Спасибо!

Базовый поток программ

Client -> Creates Callback
Client -> Starts Service
Service -> Inits & Starts CountDownTimer
Service.CountDownTimer.onFinish() -> DownloadAndParse()
DownloadAndParse() -> initialize new saxRequest(), new Handler for this request.
Service.Handler->beginBroadcast()
Client.CallbackStub -> updateUI()
Client.CallbackStub -> service.startCountDownTimer()

Надеюсь, это имеет смысл. Я бы разместил здесь код, но его так много в разных файлах. Я подумала, что попытаюсь поднять поток, чтобы увидеть, есть ли что-то ослепительное ... Единственное, что я вижу, это, возможно, повторное использование saxRequest () вместо создания нового экземпляра ... Сейчас я попробую это на самом деле, но мне бы очень хотелось узнать о влиянии GREF и сборки мусора ...

7
задан Chrispix 17 August 2010 в 03:12
поделиться

1 ответ

Это глобальные ссылки JNI. Если вы не пишете собственный код, у вас нет прямого контроля над ними. Сообщения журнала появляются, когда включен CheckJNI, который по умолчанию включен для инженерных сборок и эмулятора.

Эти сообщения означают, что машинный код сообщает виртуальной машине, что нельзя отбрасывать некоторые объекты. По сути, глобальные ссылки - это способ для нативного кода добавлять ссылки на корневой набор сборщика мусора. Предполагая, что машинный код написан правильно, глобальные ссылки будут очищены, когда машинному коду они больше не нужны.

Единственный повод для беспокойства будет заключаться в том, что число глобальных ссылок продолжит расти, поскольку это может указывать на глобальную утечку ссылок. Поскольку виртуальная машина не может освободить объекты, глобальная утечка ссылок в конечном итоге приведет к нехватке памяти виртуальной машины. Чтобы помочь выявить такие проблемы, при включении CheckJNI устанавливается ограничение на количество глобальных ссылок (текущий предел - 2000).

18
ответ дан 6 December 2019 в 10:46
поделиться
Другие вопросы по тегам:

Похожие вопросы: