我看到getInputStream返回时出现间歇性延迟，并且输入流上也出现间歇性慢读取。
我正在使用异步HttpURLConnection在服务器上执行GET。服务器返回XML String。我正在使用Fiddler观察服务器事务，并且返回到服务器的事务在250-600毫秒左右是一致的（相对于Android应用程序的执行）。 Android设备上的执行虽然可以延伸到10多秒。我在同一个无线网络上尝试使用独立设备的性能，但我看到同样长的间歇性延迟。有时我会收到套接字超时异常。
我的应用程序在HiSense Android平板电脑上运行。我正在通过笔记本上的Fiddler代理指导android流量。我正在通过USB使用调试模式从代码中捕获一些定时数据。在启动异步任务时，我的活动会设置timer_value。从asynchTask开始，日志时间以毫秒为单位累积。
我可以看到它不是来自Fiddler的DNS问题。我尝试在开始新连接之前先关闭连接。我试过关掉“保持活力”。我看了cookie同步的潜在影响......有什么想法吗？
这是来自asyncTask的代码：
@Override
protected String doInBackground(String... urls) {
Log.v(LOG_TAG,"top of background = " + Long.valueOf(System.currentTimeMillis()
- ((MyApplication)activity.getApplicationContext()).timer_value) );
URL url;
InputStream is = null;
HttpURLConnection connection = null;
try {
char[] buffer = new char[2000];
int count=0;
url = new URL(urls[0]);
connection = (HttpURLConnection)url.openConnection();
connection.setDoInput(true);
connection.setReadTimeout(10000);
connection.setConnectTimeout(15000);
connection.setRequestMethod("GET");
Log.v(LOG_TAG,"in front of connect = " + Long.valueOf(System.currentTimeMillis()
- ((MyApplication)activity.getApplicationContext()).timer_value) );
connection.connect();
Log.v(LOG_TAG,"time to connect = " + Long.valueOf(System.currentTimeMillis()
- ((MyApplication)activity.getApplicationContext()).timer_value) );
is = connection.getInputStream();
Log.v(LOG_TAG,"time to response = " + Long.valueOf(System.currentTimeMillis()
- ((MyApplication)activity.getApplicationContext()).timer_value) );
StringBuilder response = new StringBuilder();
Reader reader = new InputStreamReader(is, "UTF-8");
while ((count = reader.read(buffer,0,1500)) > 0) {
response = response.append(new String(buffer, 0, count));
Log.v(LOG_TAG,"time so far in read loop = " + Long.valueOf(System.currentTimeMillis()
- ((MyApplication)activity.getApplicationContext()).timer_value) );
}
is.close();
reader.close();
Log.v(LOG_TAG,"time to read = " + Long.valueOf(System.currentTimeMillis()
- ((MyApplication)activity.getApplicationContext()).timer_value) );
return response.toString();
}
catch (Exception e) {
Log.v(LOG_TAG,"exception = " + e.toString());
e.printStackTrace();
return null;
}
}
这是一个比大多数更快的LogCat。 Fiddler显示交易时间为24毫秒。我在441毫秒计时完整代码：
09-16 16:21:44.287: V/kinn_nat5(13131): time to connect = 9
09-16 16:21:44.567: V/kinn_nat5(13131): time to response = 295
09-16 16:21:44.707: V/kinn_nat5(13131): time to read = 434
09-16 16:21:44.717: V/kinn_nat5(13131): time to complete = 441
09-16 16:21:44.757: D/dalvikvm(13131): GC_FOR_ALLOC freed 350K, 11% free 6673K/7495K, paused 21ms, total 21ms
09-16 16:21:44.847: D/dalvikvm(13131): GC_CONCURRENT freed 281K, 10% free 6813K/7495K, paused 2ms+11ms, total 25ms
当它变坏时，它可能会产生超时或可怕的延迟，就像Fiddler的时钟频率为47毫秒的交易一样。我在这里计时18秒！有任何想法吗？
09-16 16:27:55.217: V/kinn_nat5(14093): top of background = 1
09-16 16:27:55.217: V/kinn_nat5(14093): time to connect = 9
09-16 16:28:13.247: V/kinn_nat5(14093): time to response = 18040
09-16 16:28:14.037: V/kinn_nat5(14093): time to read = 18825
09-16 16:28:14.087: D/dalvikvm(14093): GC_FOR_ALLOC freed 266K, 11% free 6716K/7495K, paused 52ms, total 52ms
09-16 16:28:14.097: V/kinn_nat5(14093): time to complete = 18889
09-16 16:28:14.187: D/dalvikvm(14093): GC_CONCURRENT freed 375K, 10% free 6801K/7495K, paused 1ms+2ms, total 15ms
在交换平板电脑以尝试调试此问题之后，我现在怀疑根本原因是我一直在使用的HiSense平板电脑的性能或特定的Android版本。
当我在调试模式下使用运行Android 4.4.4的华硕Nexus 7，相同数量的内存，但具有更强大的CPU和更新版本的操作系统时，系统就像一个冠军。我没有看到任何超时，而且表现非常接近我从Fiddler看到的。无论是否打开保持活动，系统都能很好地运行。
我不确定为什么海信的表现如此糟糕。我没时间理解这一点。那台机器运行4.1.1并且开箱即用，所以我不知道。一世
以下是Fiddler以440毫秒计时的典型交易。我的时间显示在509毫秒完成。
09-17 12:44:42.880: V/kinn_nat5(10361): top of background = 0
09-17 12:44:42.880: V/kinn_nat5(10361): in front of connect = 1
09-17 12:44:42.880: V/kinn_nat5(10361): time to connect = 4
09-17 12:44:43.381: V/kinn_nat5(10361): time to response = 498
09-17 12:44:43.391: V/kinn_nat5(10361): time to read = 508
09-17 12:44:43.391: V/kinn_nat5(10361): time to complete = 509
09-17 12:44:43.521: D/dalvikvm(10361): GC_FOR_ALLOC freed 800K, 8% free 10280K/11116K, paused 17ms, total 17ms