нехватка памяти, ошибка моего приложения? - PullRequest
5 голосов
/ 16 июня 2010

У меня есть приложение на рынке Android, в котором исключения и ошибки отлавливаются и отправляются мне acra.

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

Всегда ли это означает, что в моем приложении возникла проблема, или же в телефоне не хватает памяти из-за другого процесса?

Будут ли пользователи также получать диалог с fc?

Дополнительная информация

В моем приложении нет ничего интенсивного с памятью ..

нет изображений ... нет больших кусков данных .. только простое представление .. и самое интенсивное объявление mobclix ..

Я новичок в Java ... так что у меня может быть утечка где-то ... но мне трудно отладить это. Но на данный момент я даже не уверен, что что-то не так ...

Я получаю около 25 -50 ошибок в OOM ежедневно ... но по сравнению с 60 000 объявлений, которые он показывает в день. (я показываю только 1 или 2 объявления для каждого запуска), это не слишком много.

1 получить ошибки, такие как:

"java.lang.OutOfMemoryError
at org.apache.http.impl.io.AbstractSessionInputBuffer.init(AbstractSessionInputBuffer.java:79)
at org.apache.http.impl.io.SocketInputBuffer.<init>(SocketInputBuffer.java:93)
at android.net.http.AndroidHttpClientConnection.bind(AndroidHttpClientConnection.java:114)
at android.net.http.HttpConnection.openConnection(HttpConnection.java:61)
at android.net.http.Connection.openHttpConnection(Connection.java:378)
at android.net.http.Connection.processRequests(Connection.java:237)
at android.net.http.ConnectionThread.run(ConnectionThread.java:125)

"

"java.lang.OutOfMemoryError
at java.io.BufferedReader.<init>(BufferedReader.java:102)
at com.mobclix.android.sdk.Mobclix$FetchResponseThread.run(Mobclix.java:1422)
at com.mobclix.android.sdk.MobclixAdView$FetchAdResponseThread.run(MobclixAdView.java:390)
at java.util.Timer$TimerImpl.run(Timer.java:290)

"

"java.lang.OutOfMemoryError
at org.apache.http.util.ByteArrayBuffer.<init>(ByteArrayBuffer.java:53)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.init(AbstractSessionOutputBuffer.java:77)
at org.apache.http.impl.io.SocketOutputBuffer.<init>(SocketOutputBuffer.java:76)
at android.net.http.AndroidHttpClientConnection.bind(AndroidHttpClientConnection.java:115)
at android.net.http.HttpConnection.openConnection(HttpConnection.java:61)
at android.net.http.Connection.openHttpConnection(Connection.java:378)
at android.net.http.Connection.processRequests(Connection.java:237)
at android.net.http.ConnectionThread.run(ConnectionThread.java:125)

"

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

Ответы [ 6 ]

3 голосов
/ 13 июля 2010

Распространенной проблемой JVM является то, что сборщик мусора может удалять только объекты, на которые нет ссылок.Если у вас есть большие постоянные объекты, тогда важно установить неиспользуемые переменные в этих объектах на нуль, чтобы они разыменовывались.Классическая проблема - хранить что-то вроде объекта HashMap с множеством значений, когда вам это не нужно, поскольку каждая запись в HashMap жует память.

1 голос
/ 29 июня 2010

Как предположил Томас, вы действительно хотите использовать DDMS для проверки использования вашей памяти.

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

Обработка растровых изображений также может быть очень дорогой на Android. Что делает ваше приложение? Кроме того, у вас есть много ссылок на какие-либо элементы пользовательского интерфейса? Любые из них определены как статические?

1 голос
/ 17 июня 2010

Вы использовали трекер распределения в DDMS? Может помочь вам найти неожиданные утечки памяти. http://developer.android.com/resources/articles/track-mem.html (Я сам пока не использовал его)

0 голосов
/ 01 июля 2010

Когда вы получаете OutOfMemoryError, вы можете быть уверены, что это ваше приложение, а не другое, которое его вызывает. Каждое Android-приложение запускается на собственной виртуальной машине Dalvik с максимальным выделением памяти 16 МБ.

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

0 голосов
/ 16 июня 2010

Что вы имеете в виду под «общими java» исключениями, и если они не связаны с вашим программным обеспечением, то почему вы их получаете?

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

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

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

EDIT

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

0 голосов
/ 16 июня 2010

Есть вещи, которые могут быть вне вашего контроля (например, память на телефоне), но тем не менее вы несете ответственность за поведение вашего приложения.

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

...