из ошибки памяти, отказа моего приложения?
у меня есть приложение на Android Market, в котором исключения и ошибки пойманы и отправлены мне acra.
Но я получаю довольно много из ошибок памяти.. В другом виде классов... некоторое мое приложение, некоторый общий Java..
Это всегда означает, что в моем приложении существует проблема, или это может также быть телефон, исчерпал память из-за другого процесса?
Пользователи также получат диалоговое окно ФК?
Дополнительная информация
Нет ничего памяти intensite в моем приложении..
никакие изображения... никакие большие блоки данных.. только простое представление.. и самый интенсивный 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 ответов
Есть вещи, которые могут быть вне вашего контроля (например, память телефона), но, тем не менее, вы несете ответственность за поведение своего приложения.
То, как вы решите проблемы с памятью, повлияет на то, как пользователи будут рассматривать ваше приложение. Если он хорошо работает с другими приложениями, пользователи с большей вероятностью будут его использовать. Если этого не произойдет, они этого не сделают.
Что вы имеете в виду под "общими исключениями java" и если они не связаны с вашей частью программного обеспечения, то почему вы их получаете?
Как вы, вероятно, знаете, виртуальная машина Dalvik имеет только небольшой объем памяти, выделенный для себя (и для вашего приложения). Это реализовано таким образом, чтобы избежать возможности выхода процесса из-под контроля и истощения всех доступных ресурсов, что сделает телефон непригодным для использования. Поэтому если ваше приложение выполняет много операций, требующих много памяти (например, загрузку изображений), и вы не следите за выделением ресурсов (и очищаете их, как только они становятся ненужными), то могут наблюдаться странные результаты.
По поводу принудительного закрытия, поскольку вы отлавливаете эти исключения, они не должны вызывать крах вашего приложения, если только вы не пропустили повторное создание чего-либо после того, как поймали исключение.
Возможно, проверка вашего кода и устранение ненужных выделений памяти окажутся полезными. Также, вы можете протестировать, как это делает мой босс - он просто бесится, нажимая кнопки наугад, пока что-нибудь не упадет :D
EDIT
Поскольку вы говорите, что в вашем коде нет ничего, требующего памяти (кроме рекламы, вероятно), то вы можете провести простую проверку, чтобы увидеть, не хватает ли всей системе памяти, когда возникает ошибка, или это ваше приложение вызывает ее. Посмотрите на обратный вызов onLowMemory. Он вызывается, когда всему телефону не хватает памяти.
Использовали ли вы трекер распределения в DDMS? Это может помочь вам найти неожиданные утечки памяти. http://developer.android.com/resources/articles/track-mem.html (сам я пока не использовал)
Распространенная проблема JVM заключается в том, что сборщиком мусора могут быть удалены только объекты, на которые нет ссылок. Если у вас есть большие постоянные объекты, важно установить для неиспользуемых переменных в этих объектах значение NULL, чтобы они разыменовывались. Классическая проблема - хранить что-то вроде объекта HashMap с большим количеством значений в нем, когда он вам не нужен, поскольку каждая запись в HashMap занимает память.
Как предположил Томас, вы действительно хотите использовать DDMS для анализа использования памяти.
Также очень распространенной проблемой утечек является использование статических переменных - используйте их, только если знаете, что делаете.
Обработка растровых изображений также может стать очень дорогой на Android. Что делает ваше приложение? Кроме того, есть ли у вас много ссылок на какие-либо элементы пользовательского интерфейса? Какие-нибудь из них определены как статические?
Когда вы получаете OutOfMemoryError, вы можете быть уверены, что это ваше приложение, а не другое приложение, которое его вызывает. Каждое приложение для Android запускается на собственной виртуальной машине Dalvik с максимальным объемом памяти 16 МБ.
Если вы не используете растровые изображения (которые являются частым источником утечек памяти), вам также необходимо проверить, правильно ли вы обрабатываете изменения ориентации, то есть без сохранения в памяти каких-либо ссылок на объект относительно пользовательского интерфейса.