Android HttpClient OOM на 4G/LTE (HTC Thunderbolt)

Глядя на трассировку стека, похоже, что реализация Android HttpClient.execute() выдает OOM.

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

Как лучше всего привлечь к этому внимание разработчиков Android? Есть ли варианты получше, чем отчеты по http://code.google.com/p/android/issues?

Вероятность того, что это чистая ошибка Android, мала, но не равна нулю.

Вот некоторые другие возможности, в произвольном порядке:

1. Нет проблем с execute() как таковым, но у вас просто не хватает памяти, а трассировка стека, с которой вы столкнулись, просто демонстрирует, что execute() нагружает вашу кучу.

2. Проблема заключается в некоторых модификациях, которые HTC внесла в Android для Thunderbolt, которые, возможно, вступают в силу только в сети LTE.

3. Проблема каким-то образом вызвана самой сетью Verizon LTE (например, некоторые их прокси-серверы отправляют обратно нелепую информацию, из-за которой у HttpClient возникают проблемы).

Любые идеи о том, как я могу обойти это?

Во-первых, я бы использовал существующие инструменты (например, сброс HPROF и проверку с помощью Eclipse MAT), чтобы убедиться, что у вас нет утечки памяти в целом, из-за которой комбинация Thunderbolt / LTE просто спотыкается.

Далее я рекомендую вам придумать какой-нибудь способ последовательного воспроизведения ошибки. Это может быть ваше существующее приложение с рядом шагов, которые нужно выполнить, или это может быть специальное приложение (например, зарегистрируйте URL-адрес, который запускает OOM, а затем создайте крошечное приложение, которое просто выполняет этот запрос HttpClient). Я бы хотел, чтобы в DeviceAnywhere был Thunderbolt, но это не похоже на него. Я прощупаю и посмотрю, смогу ли я получить помощь на этом фронте.

Что касается решения этой проблемы, в качестве временной меры вы можете определить, что вы используете Thunderbolt через данные android.os.Build и, возможно, что вы используете LTE через ConnectivityManager (я предполагаю, что LTE будет отображаться как WiMAX, но это просто предположение) и предупреждать пользователей о проблемах с этим комбо.

Кроме того, вы можете попробовать немного изменить использование HttpClient и посмотреть, повлияет ли это, например:

• Если вы поддерживаете только API уровня 8 или выше, вы можете попробовать AndroidHttpClient в качестве замены.
• Отключите многопоточный доступ (вообще или специфичный для Thunderbolt) и избавьтесь от ThreadSafeClientConnManager

Мне жаль, что у меня нет для вас "волшебного ответа".

ОБНОВЛЕНИЕ

Теперь, когда у меня есть полная трассировка стека, просмотр исходного кода... несколько проясняет ситуацию.

Проблема, похоже, в том, что:

HttpConnectionParams.getSocketBufferSize(params);

возвращает это значение размером 2 МБ или около того, которое запускает OOM. Это ужасно большой буфер, особенно для движка Dalvik GC, который может быть фрагментирован (да, это слово снова).

params вот HttpParams. Кажется, вы сами их создаете через getHttpParams(). Например, AndroidHttpClient устанавливает значение 8192:

HttpConnectionParams.setSocketBufferSize(params, 8192);

Если вы сами устанавливаете размер буфера сокета, попробуйте уменьшить его. Если нет, попробуйте установить его на 8192 и посмотрите, поможет ли это.

вот исправление: https://review.source.android.com/22852

тем временем URLConnection невосприимчив. эта проблема есть только у HttpClient.

если вы разработчик, желающий протестировать такой сбой, вы можете использовать «adb shell setprop», чтобы установить, скажем, «net.tcp.buffersize.wifi», чтобы максимальные размеры буфера сокета для чтения/записи были огромными, когда ваш устройство подключено к Wi-Fi. что-то вроде следующего было бы настоящим стресс-тестом:

adb shell setprop net.tcp.buffersize.wifi 4096,80999999,80999999,4096,80999999,80999999

именно такое изменение конфигурации вызывает ошибку HttpClient. я не знаю, каковы точные значения для Thunderbolt, но кто-то с устройством может узнать, используя «adb shell getprop | grep buffersize».

Возможно, это поможет:

// Set the timeout in milliseconds until a connection is established.
int timeoutConnection = 5000;

// Set the default socket timeout (SO_TIMEOUT) 
// in milliseconds which is the timeout for waiting for data.
int timeoutSocket = 4000;

// set timeout parameters for HttpClient 
HttpParams httpParameters = new BasicHttpParams();
HttpConnectionParams.setConnectionTimeout(httpParameters, timeoutConnection);
HttpConnectionParams.setSoTimeout(httpParameters, timeoutSocket);
HttpConnectionParams.setSocketBufferSize(httpParameters, 8192);//setting setSocketBufferSize

DefaultHttpClient httpClient = new DefaultHttpClient();
httpClient.setParams(httpParameters);