我看到getInputStream返回时出现间歇性延迟,并且还有间歇性慢速读取 输入流。
我正在使用异步HttpURLConnection在服务器上执行GET。服务器返回XML 串。我正在观看使用Fiddler的服务器事务和事务并返回到 服务器是一致的(相对于Android应用程序的执行)大约250-600毫秒。执行 在Android设备上虽然可以延伸到10+以上。我已经尝试过使用支架的性能 单独的设备,在同一个无线网络上,但我看到同样长的间歇性延迟。有时 我收到套接字超时异常。
我的应用程序在HiSense Android平板电脑上运行。我正在指挥机器人 通过笔记本电脑上的Fiddler代理流量。我正在使用调试模式 通过USB从代码中捕获一些定时数据。 timer_value由我的活动设置 它开启了异步任务。从asynchTask开始,日志时间以毫秒为单位累计。
我可以看到它不是来自Fiddler的DNS问题。我试图先关闭连接 在开始新的之前。我试过关掉“保持活力”。我看起来有潜在的影响 cookie同步......有什么想法吗?
以下是asynchTask中的代码:
@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 ms:
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
答案 0 :(得分:0)
在交换平板电脑以尝试调试此问题后,我现在怀疑根本原因是我一直在使用的HiSense平板电脑的性能或特定Android版本。
当我在调试模式下使用运行Android 4.4.4的华硕Nexus 7,相同数量的内存,但具有更强大的CPU和更新版本的操作系统时,系统就像一个冠军。我没有看到任何超时,而且表现非常接近我从Fiddler看到的。无论是否启用了keep-alive,系统都能正常运行。
我不确定为什么海信的表现如此糟糕。我没时间理解这一点。那台机器运行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