Android 安卓4.4 Kitkat上的安卓问题

我遇到了一个问题，因为Aquery库只在通过GridView/ListView滚动加载带有分页的图像时才延迟加载Android 4.4 Kitkat上的图像

以下是日志：

12-03 10:39:43.678: W/AQuery(6261): reporting:java.io.IOException: open failed: EMFILE (Too many open files)
12-03 10:39:43.678: W/AQuery(6261): at java.io.File.createNewFile(File.java:946)
12-03 10:39:43.678: W/AQuery(6261): at com.androidquery.callback.AbstractAjaxCallback.getPreFile(AbstractAjaxCallback.java:1150)
12-03 10:39:43.678: W/AQuery(6261): at com.androidquery.callback.AbstractAjaxCallback.httpDo(AbstractAjaxCallback.java:1609)
12-03 10:39:43.678: W/AQuery(6261): at com.androidquery.callback.AbstractAjaxCallback.httpGet(AbstractAjaxCallback.java:1344)
12-03 10:39:43.678: W/AQuery(6261): at com.androidquery.callback.AbstractAjaxCallback.network(AbstractAjaxCallback.java:1243)
12-03 10:39:43.678: W/AQuery(6261): at com.androidquery.callback.AbstractAjaxCallback.networkWork(AbstractAjaxCallback.java:1082)
12-03 10:39:43.678: W/AQuery(6261): at com.androidquery.callback.AbstractAjaxCallback.backgroundWork(AbstractAjaxCallback.java:1014)
12-03 10:39:43.678: W/AQuery(6261): at com.androidquery.callback.AbstractAjaxCallback.run(AbstractAjaxCallback.java:977)
12-03 10:39:43.678: W/AQuery(6261): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
12-03 10:39:43.678: W/AQuery(6261): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
12-03 10:39:43.678: W/AQuery(6261): at java.lang.Thread.run(Thread.java:841)
12-03 10:39:43.678: W/AQuery(6261): Caused by: libcore.io.ErrnoException: open failed: EMFILE (Too many open files)
12-03 10:39:43.678: W/AQuery(6261): at libcore.io.Posix.open(Native Method)
12-03 10:39:43.678: W/AQuery(6261): at libcore.io.BlockGuardOs.open(BlockGuardOs.java:110)
12-03 10:39:43.678: W/AQuery(6261): at java.io.File.createNewFile(File.java:939)
12-03 10:39:43.678: W/AQuery(6261): ... 10 more

似乎我需要最小化外部存储上打开的文件，但如何做到这一点？有什么想法吗？

编辑： 我可以复制它，而且它似乎只发生在Kitkat上。以前版本的aquery也有这个问题。看看现在发生了什么

好的，我刚测试过。问题是因为我的可输入设置：

当显示的图像太多时会发生这种情况。如果没有这个选项，应用程序将比文件限制更快地耗尽内存（所以情况更糟）

我的建议是限制活动中的图像或仍在使用的片段的数量

我正在检查是否有更好的解决方案，但可能需要一些时间

---

您也可以尝试其他图像加载库，看看是否会发生这种情况。

我在KitKat中遇到了同样的问题。 修复方法如下：在BitmapAjaxCallback.java中将options.inInputShareable从“true”更改为“false” 从任何URL加载的每个位图都存储到文件中。如果inInputShareable为true，则您的进程具有用于共享的重复文件描述符。因此，当超过1024个文件描述符泄漏时，就会发生EMFILE。 但实际上，我不明白为什么在KitKat之前它能正常工作：）

p.S.inInputShareable=false作为可输入=false工作，并导致快速OOM：( AQuery中正确的修复方法是将BitmapFactory.decodeFileDescriptor的调用更改为BitmapFactory.decodeByteArray（不要使用decodeStream！！！它忽略Inpurgable，尽管它有JavaDocs）

---

我发现这个问题与KitKat中的bug有关：

Android Query发布了另一个版本（0.26.8）来解决这个问题：

---

我一按后退按钮，应用程序就会崩溃，并出现以下日志：12-05 17:44:19.808:E/InputChannel JNI（1683）：错误24 dup channel fd 86。12-05 17:44:19.818:E/InputEventSender（1683）：异常调度完成信号。12-05 17:44:19.818:E/MessageQueue JNI（1683）：MessageQueue callback中的异常：HandlerReceiveCallback如何限制活动中仍在使用的图像或片段的数量..？您的应用程序保留了多少图像？只有在您有300-500个未发布的图像视图（由活动或可能不可见的片段保留）时才会发生此情况。如果仅显示少量图像，则可能存在内存泄漏活动或碎片。