Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
19.04.2016, 17:13
|
|||
---|---|---|---|
Деструктивная |
|||
#18+
Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Это хороший подход? Или лучше этим заниматься в onResume/onPause? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
19.04.2016, 17:22
|
|||
---|---|---|---|
Деструктивная |
|||
#18+
ыудусеИли лучше этим заниматься в onResume/onPause? Всего по этому коду не увидеть, но если учесть, что андроид бывает, что фоном дергает подготовку фрагментов (не показывая самого фрагмента), то лучше-бы делать по методичке. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
19.04.2016, 17:23
|
|||
---|---|---|---|
Деструктивная |
|||
#18+
ыудусеЭто хороший подход? Или лучше этим заниматься в onResume/onPause? ну так в том же топике написано, что onPause вызовется только когда сама Activity уснет. Так что если у тебя куча "спящих" фрагментов на бэкстеке и память кончается, то ждать onPause не вариант. Имхо над чем стоит таки задуматься это 1) есть ли вообще проблема с "утечкой" памяти, или мы, как обычно, занимаемся преждевременной оптимизацией 2) если утечка есть, то в том ли она, что много фрагментов на бэкстеке, может проблема в другом? 3) если много фрагментов на бэкстеке, то оправдано ли это? может нужно что-то в консерватории подкрутить? например уничтожать ненужные фрагменты или вообще другую архитектуру использовать. в чем особый профит кучи фрагментов, что у нас типа Single Window Application на одной активити? 4) если ничего из перечисленного неприемлемо, то да - уничтожай ресурсы как описано в теме. тот еще гемор, но можно если нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=13&mobile=1&tid=1331126]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
165ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
2ms |
others: | 12ms |
total: | 272ms |
0 / 0 |