16

背景

我正在开发一个提供简单 HTTP/HTTPS 服务器的 Android 应用程序。如果配置了 HTTPS 服务,那么在每个连接上都会观察到本机内存使用量增加,最终导致应用程序崩溃 (oom),而使用 HTTP 配置可保持本机内存使用量相对恒定。应用程序的 Java VM 在两种配置中保持相对恒定。

该应用程序提供一个 HTML 页面,其中包含一个带有定期轮询的 javascript(每秒一次 json 轮询),因此使用 HTTPS 配置调用应用程序页面并将页面保持打开几个小时将导致提到的内存不足,因为增加本机内存使用量。我已经测试了许多在互联网上发现的 SSLServerSocket 和 SSLContext 配置,但都没有运气。

我在从 2.2 到 4.3 的各种 Android 设备和各种 Android 版本上观察到同样的问题。

对于两种配置 HTTP/HTTPS,处理客户端请求的代码是相同的。两种配置之间的唯一区别是服务器套接字的设置。而在 HTTP 服务器套接字的情况下,单行类似于“ServerSocket serversocket = new ServerSocket(myport);” 完成这项工作,在 HTTPS 服务器设置的情况下,通常会采取设置 SSLContext 的步骤——即设置密钥管理器和初始化 SSLContext。现在,我使用默认的 TrustManager。

需要您的建议

有人知道使用 OpenSSL 的 Android 的默认 TLS 提供程序中的任何内存泄漏问题吗?为了避免本机内存泄漏,我应该考虑一些特别的事情吗?任何提示都非常感谢。

更新:我还通过在 SSLContext.getInstance("TLS", providerName) 中明确给出提供者名称来尝试了 TLS 提供者:OpenSSL 和 JSSE。但这并没有改变什么。

这是一个演示问题的代码块。只需创建一个示例应用程序,将其放入主活动的 onCreate 底部并构建并运行该应用程序。确保您的 Wifi 已打开并通过以下地址调用 HTML 页面:

https://android device IP:9090

然后查看 adb 日志,过一会你会看到原生内存开始增加。


new Thread(new Runnable() {

public void run() {

final int PORT = 9090; SSLContext sslContext = SSLContext.getInstance( "TLS" ); // JSSE and OpenSSL providers behave the same way KeyManagerFactory kmf = KeyManagerFactory.getInstance( KeyManagerFactory.getDefaultAlgorithm() ); KeyStore ks = KeyStore.getInstance( KeyStore.getDefaultType() ); char[] password = KEYSTORE_PW.toCharArray(); // we assume the keystore is in the app assets InputStream sslKeyStore = getApplicationContext().getResources().openRawResource( R.raw.keystore ); ks.load( sslKeyStore, null ); sslKeyStore.close(); kmf.init( ks, password ); sslContext.init( kmf.getKeyManagers(), null, new SecureRandom() ); ServerSocketFactory ssf = sslContext.getServerSocketFactory(); sslContext.getServerSessionContext().setSessionTimeout(5); try { SSLServerSocket serversocket = ( SSLServerSocket )ssf.createServerSocket(PORT); // alternatively, the plain server socket can be created here //ServerSocket serversocket = new ServerSocket(9090); serversocket.setReceiveBufferSize( 8192 ); int num = 0; long lastnatmem = 0, natmemtotalincrease = 0; while (true) { try { Socket soc = (Socket) serversocket.accept(); Log.i(TAG, "client connected (" + num++ + ")"); soc.setSoTimeout(2000); try { SSLSession session = ((SSLSocket)soc).getSession(); boolean valid = session.isValid(); Log.d(TAG, "session valid: " + valid); OutputStream os = null; InputStream is = null; try { os = soc.getOutputStream(); // just read the complete request from client is = soc.getInputStream(); int c = 0; String itext = ""; while ( (c = is.read() ) > 0 ) { itext += (char)c; if (itext.contains("\r\n\r\n")) // end of request detection break; } //Log.e(TAG, " req: " + itext); } catch (SocketTimeoutException e) { // this can occasionally happen (handshake timeout) Log.d(TAG, "socket timeout: " + e.getMessage()); if (os != null) os.close(); if (is != null) is.close(); soc.close(); continue; } long natmem = Debug.getNativeHeapSize(); long diff = 0; if (lastnatmem != 0) { diff = natmem - lastnatmem; natmemtotalincrease += diff; } lastnatmem = natmem; Log.i(TAG, " answer the request, native memory in use: " + natmem / 1024 + ", diff: " + diff / 1024 + ", total increase: " + natmemtotalincrease / 1024); String html = "<!DOCTYPE html><html><head>"; html += "<script type='text/javascript'>"; html += "function poll() { request(); window.setTimeout(poll, 1000);}\n"; html += "function request() { var xmlHttp = new XMLHttpRequest(); xmlHttp.open( \"GET\", \"/\", false ); xmlHttp.send( null ); return xmlHttp.responseText; }"; html += "</script>"; html += "</head><body onload=\"poll()\"><p>Refresh the site to see the inreasing native memory when using HTTPS: " + natmem + " </p></body></html> "; byte[] buffer = html.getBytes("UTF-8"); PrintWriter pw = new PrintWriter( os ); pw.print("HTTP/1.0 200 OK \r\n"); pw.print("Content-Type: text/html\r\n"); pw.print("Content-Length: " + buffer.length + "\r\n"); pw.print("\r\n"); pw.flush(); os.write(buffer); os.flush(); os.close(); } catch (IOException e) { e.printStackTrace(); } soc.close(); } catch (IOException e) { e.printStackTrace(); } } } catch (SocketException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } } }).start();

- 编辑 -

我已经为 eClipse 上传了一个名为 SSLTest 的示例应用程序项目,它演示了该问题:

http://code.google.com/p/android/issues/detail?id=59536

- 更新 -

好消息:今天发现了上面报告的 Android 问题,并提交了适当的提交来修复内存泄漏。有关更多详细信息,请参阅上面的链接。

4

3 回答 3

3

我想这将是一笔可观的时间投资,但我看到 Valgrind 已被移植到 Android。您可以尝试启动并运行它。当然,如果您发现存在内部内存泄漏,除了尝试在未来的 Android 版本中修复该错误外,您无能为力。

作为一种解决方法,您可以使您的应用程序多进程并将 https 服务放在一个单独的进程中。这样您就可以定期重新启动它,避免 OOM。您可能还必须有第三个进程只接受端口 443 连接并将它们传递给 https 工作程序 - 以避免重新启动 https 工作程序时出现微小的中断。

这听起来也像是大量的时间投资:) 但它可能会成功地避免这个问题。

--- 编辑:更多细节 ---

是的,如果您有一个具有自己的 UI 的主应用程序、一个用于处理 SSL 的工作进程和一个用于接受 SSL 请求的工作进程(正如您所说的可能不能是 443),那么在您的正常活动类之上,您将有两个服务类,清单会将它们放在单独的进程中。

处理 SSL 进程:与其等待 OOM 使服务崩溃,服务可以监控自己的 Debug.getNativeHeapSize(),并在增加过多时显式重启服务。要么这样,要么在每 100 个左右的请求后自动重启。

处理侦听套接字进程:此服务只会侦听您选择的 TCP 端口并将原始数据传递给 SSL 进程。这一点需要考虑,但最明显的解决方案是让 SSL 进程在不同的本地端口 X 上侦听(或在选择的不同端口之间切换),侦听套接字进程会将数据转发到端口 X。原因让监听套接字进程优雅地处理 X 关闭的可能性 - 就像你重新启动它时一样。

如果您的要求允许偶尔出现小型中断,我将只处理 SSL 进程,并跳过侦听套接字进程,那么这是一个相对简单的解决方案 - 与您通常所做的没有什么不同。监听套接字进程增加了解决方案的复杂性......

于 2013-09-09T00:27:07.637 回答
0

显式关闭输入流是否有帮助?在示例代码中,输入流似乎只在 SocketTimeoutException 异常的情况下关闭。

- 编辑 -

您可以将 run() 重命名为 run2() 并将 while 循环移动到 run() 并将其从 run2() 中删除,看看是否有区别?这不是一个解决方案,但会告诉您是否有任何长期存在的对象在删除它们的引用时释放内存。

于 2013-09-06T14:08:11.480 回答
0

我建议在您的实现中更改一个细节。

列出所有资源变量,例如 Sockets、Streams、Writers 等。确保声明位于 try 语句之外,并确保在 finally 语句中进行清理/关闭。我通常会做这样的事情来百分百确定:

InputStream in = null;
OutputStream out = null;

try {
    //assign a proper value to in and out, and use them as needed.
} catch(IOException e) {
    //normal error handling
} finally {
    try {
        in.close();
    } catch(IOException e) {}
    try {
        out.close();
    } catch(IOException e) {}
}

它看起来有点令人困惑,但想象一下你在 try 块中使用你的 in Stream 并且你得到一些异常,然后你的 Streams 永远不会关闭,这是内存泄漏的潜在原因。

我不能保证这就是原因,但它应该是一个很好的启动点。

关于管理您的服务。我对 Android 服务有很多不好的体验,因为我在与 GUI 相同的线程中运行它们。在某些情况下,Android 会看到一些执行时间过长的代码并终止您的主进程以防止崩溃。我找到的解决方案是遵循本教程的建议(查看第 4 点):

http://www.vogella.com/articles/AndroidServices/article.html

在此之后,我的服务按预期工作,并没有干扰我的 GUI 进程。

问候

于 2013-09-10T13:19:04.127 回答