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

У меня есть активность 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 и сбора мусора ..

1 Ответ

18 голосов
/ 18 августа 2010

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

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

...