По-моему, никто этого не гарантирует. Будешь тормозить в паузе/стопе — не сработает.

ну да, логично

С этим и не спорят вроде.

С этого все началось

Он же просто проверяет какие ссылки доступны из корня. И неважно циклическая она или нет.

Мне кажется, он тупо не понимает, что мы говорим.

Мне кажется, он тупо не понимает, что мы говорим.

думаю да

Приветствую всех, в этом чатике, господа, подскажите, может кто работал с приложухой для приема заявок, нужна приложуха и crm, для салона красоты, или чтото близкое, разумеется не бесплатно, или какие идеи есть?

Он же просто проверяет какие ссылки доступны из корня. И неважно циклическая она или нет.

допустим вы сделали view.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { и тут что-то запустили в другом потоке и там есть ссылка на чтото из активити. Это будет утечкой. } }

Приветствую всех, в этом чатике, господа, подскажите, может кто работал с приложухой для приема заявок, нужна приложуха и crm, для салона красоты, или чтото близкое, разумеется не бесплатно, или какие идеи есть?

Ссылка на чат с вакансиями — в описании.

Ссылка на чат с вакансиями — в описании.

хех, оки

допустим вы сделали view.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { и тут что-то запустили в другом потоке и там есть ссылка на чтото из активити. Это будет утечкой. } }

С этим кто-то спорит? Или для тебя циклические ссылки — всё равно что утечки?

допустим вы сделали view.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { и тут что-то запустили в другом потоке и там есть ссылка на чтото из активити. Это будет утечкой. } }

nope. Это конечно можно утечкой назвать, но не потому что ссылка циклическая, а потому что ссылка на объект есть в другом потоке из корня которого она доступна (собсно она и из корня предыдущего потока доступна будет). Сборщик мусора и не должен ее собирать.

привет, есть у кого то в арсенале либа для построения линейного графика с возможностью выбора точки на нем и получения значения? или такое ток ручками?

Как вы думаете android studio будеи сильно лагать на ноуте с 2 гб оперы и 2200 Гц процессором?(ОС Linux)

да. Это печальное железо устарело лет 5-8 назад

Как вы думаете android studio будеи сильно лагать на ноуте с 2 гб оперы и 2200 Гц процессором?(ОС Linux)

У меня 5 лет назад студия лагала на fx4300 с 8гб на борту)

nope. Это конечно можно утечкой назвать, но не потому что ссылка циклическая, а потому что ссылка на объект есть в другом потоке из корня которого она доступна (собсно она и из корня предыдущего потока доступна будет). Сборщик мусора и не должен ее собирать.

То что потом одному из потоков объекты больше не нужны и мы в другом потоке держим контекст замыкания который мы захватили - это уже другой вопрос. И дело тут не в циклических ссылках, а именно в работе с потоками.

Собсно мы можем другому потоку напрямую ссылку передать - будет тот же результат. И без всякой цикличности.

С этим кто-то спорит? Или для тебя циклические ссылки — всё равно что утечки?

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

Например просто в Runnable

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

Если внутри него крутится уже другое - то и доступны из корня они не будут. Потому что ни на один из объектов ссылки мы не держим. А если мы их держим в другом потоке - значит они доступны из корня того, другого потока, и если мы там ссылку удалим - сборщик точно так же их соберет без всяких проблем. Ничем от прямой ссылки циклические тут не отличаются. Точно так же можно передать прямую ссылку, на активити например, в другой поток и точно такую же утечку мы получим.

Об этом и речь, от чего можно было избавиться избавились, но есть например радио, работает media player, он дестрой не вызывался, приложение выгружено, release вы никак не вызовите, но так как приложение выгружено media player тоже

@ravikwow так вы и не ответили на вопрос, речь шла именно про onDestroy/onStop который не вызывался при выгрузке из памяти

@ravikwow так вы и не ответили на вопрос, речь шла именно про onDestroy/onStop который не вызывался при выгрузке из памяти

Ответил, избавляюсь от всего раньше.

когда раньше, описан кейс

когда раньше, описан кейс

в onSaveInstanceState

и в какой же момент при выгрузке он вызовется?

делаю вывод, что вы абсолютно вы не знакомы с жизненным циклом андроид

и в какой же момент при выгрузке он вызовется?

Вы не знаете когда вызывается onSaveInstanceState?

Вы не знаете когда вызывается onSaveInstanceState?

именно потому что знаю, задаю вам наводящие вопросы, вы же в ответ пишите откровенную глупость

именно потому что знаю, задаю вам наводящие вопросы, вы же в ответ пишите откровенную глупость

Чем? То что избавляюсь от всего не в onDestroy?

вы не понимаете что onSaveInstanceState тоже не будет вызван?

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

«но существуют пока есть корень, хотя оно могло быть убито уже» ну сборщик мусора так и работает. Есть корень — оно живёт. Нет корня — собирает. Не надо сюда циклические ссылки приплетать.

«но существуют пока есть корень, хотя оно могло быть убито уже» ну сборщик мусора так и работает. Есть корень — оно живёт. Нет корня — собирает. Не надо сюда циклические ссылки приплетать.

если оно не используется ниже, то оно будет уничтожено раньше

Ладно, сдаюсь пытаться убедить. Пойду лучше работу работать

если оно не используется ниже, то оно будет уничтожено раньше

знать бы, что здесь вообще имеется в виду и к чему это

вы не понимаете что onSaveInstanceState тоже не будет вызван?

Оно не будет вызвано только если где то вызвали finish, когда активити находится в фореграунд

Оно не будет вызвано только если где то вызвали finish, когда активити находится в фореграунд

вы явно не читали на что начали отвечать

в самом начале было сказано что при полной выгрузке никакие методы не дернутся

в самом начале было сказано что при полной выгрузке никакие методы не дернутся

такое может быть, только если вы убили через adb или система убила foreground activity

если приложение полностью выгружается из памяти системой либо через настройки остановить на onDestroy не попадем, поправьте если путаю

.

про adb я конечно упустил, НО, теперь вы понимаете что вы писали не по теме

остановка через adb все равно что остановить через настройки

знать бы, что здесь вообще имеется в виду и к чему это

{ Object o = что-то посчитали с использованием кучи памяти. Object b = тоже чему то равняется. int i = o.getInt(); если далее o ни где не используется, то оно будет уничтожено. Но если o и b ссылаются друг на друга, то они будут существовать пока не закончится текущий контекст. }

{ Object o = что-то посчитали с использованием кучи памяти. Object b = тоже чему то равняется. int i = o.getInt(); если далее o ни где не используется, то оно будет уничтожено. Но если o и b ссылаются друг на друга, то они будут существовать пока не закончится текущий контекст. }

Нет. Если o нигде не используется, но b используется и ссылается на o, тогда оно, конечно, не может быть уничтожено. Опять приплёл циклические ссылки туда, где их нет.

про adb я конечно упустил, НО, теперь вы понимаете что вы писали не по теме

по теме, а вы придираетесь к варианту, который почти не возможен

по теме, а вы придираетесь к варианту, который почти не возможен

Какой вариант почти невозможен?

Какой вариант почти невозможен?

что система убъет текущую поверх всех видимую активность

по теме, а вы придираетесь к варианту, который почти не возможен

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

Нет. Если o нигде не используется, но b используется и ссылается на o, тогда оно, конечно, не может быть уничтожено. Опять приплёл циклические ссылки туда, где их нет.

В любом случае они будут существовать, если ссылаются друг на друга пока не закончится контекст

В любом случае они будут существовать, если ссылаются друг на друга пока не закончится контекст

что, какой контекст? Ты уже почитал про GC roots? и почему до сих пор нет?

Ошибка при заходе на гугл мап как раньше

что, какой контекст? Ты уже почитал про GC roots? и почему до сих пор нет?

видимо вы не читали.

что система убъет текущую поверх всех видимую активность

http://joxi.ru/1A51WYvSGNapYA

видимо вы не читали.

Все мы? Ты сейчас доказываешь всему чату, что ты один читал?

http://joxi.ru/1A51WYvSGNapYA

ну я написал, что надо до onDestroy, что не так?

В любом случае они будут существовать, если ссылаются друг на друга пока не закончится контекст

Ты по делу скажешь, при чём здесь то, что они ссылаются друг на друга и какой контекст?

Все мы? Ты сейчас доказываешь всему чату, что ты один читал?

У меня было на практике проверено, именно изза этого читал когда то

У меня было на практике проверено, именно изза этого читал когда то

у всех всё на практике проверено, но только ты один почему-то продолжаешь нести бред

Не надо наедятся что все и так умрет. Нужно освобождать ссылки, чтобы GC лучше их собрал и не было утечек памяти.

вот что ты написал, это все равно что бы ты написал "2х2=4", верно, но не связано с обсуждением

Ты по делу скажешь, при чём здесь то, что они ссылаются друг на друга и какой контекст?

Пара ссылок, которые ссылаются друг на друга, будут пригодны для уничтожения, только если на них уже не ссылается корень. Если бы они не ссылались друг на друга, то могли быть уничтожена раньше, если бы не использовались дальше, даже если на них ссылается корень

Пара ссылок, которые ссылаются друг на друга, будут пригодны для уничтожения, только если на них уже не ссылается корень. Если бы они не ссылались друг на друга, то могли быть уничтожена раньше, если бы не использовались дальше, даже если на них ссылается корень

Где написан такой бред? GC не имеет права уничтожать объекты, на которые ссылается корень.

Где написан такой бред? GC не имеет права уничтожать объекты, на которые ссылается корень.

а вы посмотрите на использование памяти

а вы посмотрите на использование памяти

а я посмотрел!

Пара ссылок, которые ссылаются друг на друга, будут пригодны для уничтожения, только если на них уже не ссылается корень. Если бы они не ссылались друг на друга, то могли быть уничтожена раньше, если бы не использовались дальше, даже если на них ссылается корень

Да. Ты верно пишешь. Но есть одно но. Если у тебя корень ссылается на А, а А ссылается на Б - то ровно так же ни один из объектов не будет уничтожен.

Одна фигня. Причем тут циклические ссылки - никто понять не может

У меня 5 лет назад студия лагала на fx4300 с 8гб на борту)

Я в итоге установил ее и он у меня очень долго запускался в итоге я не дождался и снес все вместе с системой

Да. Ты верно пишешь. Но есть одно но. Если у тебя корень ссылается на А, а А ссылается на Б - то ровно так же ни один из объектов не будет уничтожен.

А, нет, неверно. Вот эта часть откровенный бред > Если бы они не ссылались друг на друга, то могли быть уничтожена раньше, если бы не использовались дальше, даже если на них ссылается корень

Одна фигня. Причем тут циклические ссылки - никто понять не может

всего лишь написал, что стараюсь избавляться от них раньше, чтобы они были уничтожены раньше.

А, нет, неверно. Вот эта часть откровенный бред > Если бы они не ссылались друг на друга, то могли быть уничтожена раньше, если бы не использовались дальше, даже если на них ссылается корень

а вы подебажте.

а вы подебажте.

нет, это не описание эксперимента. «Посмотрите туда, посмотрите сюда, увидите, что я прав.» Не увижу. Нужно поставить конкретные условия эксперимента и сформулировать, как трактовать какой результат.

а вы подебажте.

А смысл? И так понятно что они будут жить потому что они доступны из корня, по причине того что лежат на стеке. И неважно циклические они или нет

З.Ы. Тут еще кстати возможны отличия между далвиком и ораклом по причине того что в стековой вм они может и раньше станут недоступны чем в регистровой (но это мои предположения), но не суть важно, после выхода из функции (если переменные доступны только из нее) сборщик их сгребет

З.Ы. Тут еще кстати возможны отличия между далвиком и ораклом по причине того что в стековой вм они может и раньше станут недоступны чем в регистровой (но это мои предположения), но не суть важно, после выхода из функции (если переменные доступны только из нее) сборщик их сгребет

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

З.Ы. Тут еще кстати возможны отличия между далвиком и ораклом по причине того что в стековой вм они может и раньше станут недоступны чем в регистровой (но это мои предположения), но не суть важно, после выхода из функции (если переменные доступны только из нее) сборщик их сгребет

а я и не говорил, что не сгребет после выхода. Я говорил только что они могут быть убиты до выхода.

а я и не говорил, что не сгребет после выхода. Я говорил только что они могут быть убиты до выхода.

А у вас вызовы метода минутами живут?

И еще раз, никаких тут отличий от не циклических

А у вас вызовы метода минутами живут?

бывали секундами, естественно не в UI

А у вас вызовы метода минутами живут?

У меня есть такой метод. 6 минут жду ответ в другом потоке

У меня есть такой метод. 6 минут жду ответ в другом потоке

Ну в принципе ок, да, это я маху дал с вопросом. Но обычные ссылки будут в нем так же как циклические висеть

Привет всем. Такой вопрос, может ли система при необходимости или каком-либо варианте очистить кэш приложения (не данные приложения)? Просто заметил, что иногда пропадают файлы в кэше. Заранее спасибо.

Набросайте ПОСТ запрос пожалуйста

Привет всем. Такой вопрос, может ли система при необходимости или каком-либо варианте очистить кэш приложения (не данные приложения)? Просто заметил, что иногда пропадают файлы в кэше. Заранее спасибо.

Да. Мало того, она будет это делать в самый неподходящий момент.