ошибка памяти, ошибка моего приложения?

Question

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

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

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

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

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

Существует ничего intensite памяти в мое приложение ..

Изображений нет ... нет больших кусков данных .. только простой view..and наиболее интенсивнее Mobclix ad ..

Я новичок в 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) 

"

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

Answer 1

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

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

Answer 2

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

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

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

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

EDIT

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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