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

Разглеждайки проследяването на стека, изглежда, че изпълнението на HttpClient.execute() на Android хвърля OOM.

Това не е посочено от проследяването на стека, което имате за проблема. Разбира се, вие не предоставихте цялото проследяване на стека по проблема.

Кой е най-добрият начин да привлечете вниманието на разработчиците на Android за това? Някакви по-добри опции от докладване на http://code.google.com/p/android/issues?

Шансовете това да е чисто Android грешка са малки, макар и не нулеви.

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

1. Няма проблем с execute() сам по себе си, но че просто ви изчерпва паметта и следите на стека, които сте срещнали, просто показват, че execute() натоварва вашата купчина.

2. Проблемът е в някои модификации, които HTC направи на Android за Thunderbolt, вероятно влизащи в сила само когато сте в LTE мрежата.

3. Проблемът по някакъв начин е причинен от самата LTE мрежа на Verizon (напр. някакъв техен прокси сървър изпраща обратно невероятна информация, която кара 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);

връща тази стойност от 2MB или нещо такова, която задейства 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", така че максималните размери на буфера на сокет за четене/запис да са огромни, когато вашият устройството е на wifi. нещо като следното би било истински стрес тест:

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