Как стать автором
Обновить

Комментарии 19

Огромное спасибо за перевод. А то вчера прочитать не успел, а тут и русская версия подоспела.
Не за что, нужно поддерживать сообщество.
Хорошая статья, наконец-то переход от «Hello World!» к чему-то действительно полезному.
Большое спасибо автору.
MAT очень полезная приложение спасло меня когда нужно было найти утечку памяти в моем приложении. только благодаря ему я узнал что в Toast'ах нужно использовать application context, а не activity.
С developers.android.com:
public Toast (Context context)

Since: API Level 1
Construct an empty Toast object. You must call setView(View) before you can call show().
Parameters

context The context to use. Usually your Application or Activity object.
Нет сомнений что там так и написано, тем более очень странно, что Toast продолжал удерживать контекст не давая сборщику удалить активность после выхода из приложения.
На досуге попробую повторить данную ситуацию.
На самом деле интересно было бы изучить более детально вопрос нативной памяти, а не битмапов.
В этой статье Вам дали основу анализа памяти, всё остальное можно освоить самому.
Основа анализа хипа жавы, а нативная память — это совсем другая история и походу нужно иметь девелоперский девайс с самосборной прошивкой что б были символы для дебага. И сам девайс еще д.б. мощным…

В Вашем случае все битмапы почему-то попали в основную память, что мне не понятно ибо всегда наблюдал, что она попадает именно в нативную и тут начинаются все проблемы.

Или это какая-то фича 3.0?
Собственно, вот — не понимаю от куда там массив байт взялся внутри битмапа.

Собственно и нигде нет этого mBuffer'а
Он не внутри, он как бы представляет собой back memory для Битмапа.
Не понял — можете пояснить или кинуть ссылкой? что за «back memory»? и что значит «как бы»?

Этот дамп — дамп хипа джавы. Причем тут указаны ссылки внутри джавовских объектов. Т.е. в данном случае он показывает некий «mBuffer» внутри битмапа. Вопрос — от куда он?
Ответ: из пикселей Битмапа. В оригинале всё должно быть подробно.
Нееее, Вы не поняли. Это появилось в 3.0 такое, видимо, что битмап хранится в джавовском хипе, до него все хранилось в нативной памяти.
То есть в хипе Dalvik'a, разъясните пожалуйста, а где у приложения находится нативная память? Просто я раньше думал, что всей памятью заведует Dalvik.
Есть вариант, что это такая хардварная оптимизация рендеринга. Но тоже странно.
В любом случае — наибольшая проблема именно с битмапами, а они падают именно в нативную область. А что в данном случае рисуется — не понятно ибо в сырцах нет таких полей у битмапа и тпх.

Быть может, это хитрый девелоперский хоникомб.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории