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

Ответ 1

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

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

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

Скорее всего, это чистая ошибка Android небольшая, хотя и не ноль.

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

• Нет проблем с execute() как таковым, но вы просто исчерпали память, и трассировки стека, с которыми вы столкнулись, просто демонстрируют, что execute() подчеркивает вашу кучу.

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

• Проблема каким-то образом вызвана самой сетью 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-specific) и избавиться от ThreadSafeClientConnManager

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

UPDATE

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

Проблема заключается в том, что:

HttpConnectionParams.getSocketBufferSize(params);

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

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

HttpConnectionParams.setSocketBufferSize(params, 8192);

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

Ответ 2

здесь исправление: 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".

Ответ 3

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

// 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);