为什么HttpURLConnection.getInputStream()有间歇性延迟?

时间:2014-09-17 00:05:13

标签: android performance delay httpurlconnection

我看到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

1 个答案:

答案 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