Android FileOutputStream 方法“被忽略”
对于我的应用程序,我使用三个文件来存储本地数据,其中两个文件在应用程序启动时进行检查并远程更新(如果有较新的版本可用或文件尚不存在)。第三个是在应用程序运行时可以定期存储的用户数据。
所有三个文件都使用相同的方法来保存文件:
public boolean setLocalFile(String Filename, String FileText, Context con) {
try {
FileOutputStream fos = con.openFileOutput(Filename, Context.MODE_PRIVATE);
fos.write(FileText.getBytes());
fos.close();
return true;
} catch(Exception e) {
handleError(e); // local method that simply does a System.out.println
return false;
}
}
现在第三个文件可以正常写入,但前两个文件(在启动时检查并写入)根本不写入。在调试中,似乎完全跳过了 setLocalFile 方法,而没有引发异常或使应用程序崩溃,并且报告的唯一错误日志似乎是:
07-11 16:14:13.162: ERROR/AndroidRuntime(1882): ERROR: thread attach failed
07-11 16:14:18.882: ERROR/gralloc(62): [unregister] handle 0x3bfe40 still locked (state=40000001)
不幸的是,我没有在网上找到任何与这些相关的有用信息。
这让我很困惑——我不知道为什么在这个特殊情况下它不写。有什么想法吗?
I use three files for storing of local data, for my app, two of which get checked on app start-up and updated remotely (if a newer version is available or the files do not yet exist). The third is for user data that can periodically be stored while the app is running.
All three use the same method to save the file:
public boolean setLocalFile(String Filename, String FileText, Context con) {
try {
FileOutputStream fos = con.openFileOutput(Filename, Context.MODE_PRIVATE);
fos.write(FileText.getBytes());
fos.close();
return true;
} catch(Exception e) {
handleError(e); // local method that simply does a System.out.println
return false;
}
}
Now the third file writes fine, but the first two (that are checked and written on start-up) don't write at all. In debug, it appears as if the setLocalFile method is completely skipped without throwing an exception or crashing the app and the only error logs reported appear to be:
07-11 16:14:13.162: ERROR/AndroidRuntime(1882): ERROR: thread attach failed
07-11 16:14:18.882: ERROR/gralloc(62): [unregister] handle 0x3bfe40 still locked (state=40000001)
I've not found anything useful online, in relation to these either, unfortunately.
It's got me stumped - I have no idea why it's not writing in this particular case. Any ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
迟来的更新...提供发生此问题的代码可能不太实际,因为我怀疑实际上需要我的所有代码来全面检查它。
我的变量名以大写字母开头,很大程度上是因为在使用其他语言大约 10 年后,我刚刚再次回到 Java,所以我花了一段时间才重新回到事物的摇摆中 - 不太漂亮,但如果我会感到惊讶这会有所作为。尽管如此,还是感谢大家的回复。
问题的背景是我决定将这些文件中保存的数据作为类对象进行处理。因此,Drafts 对象将保存所有草稿文档,类构造函数将调用 getLocalFile 方法并将其本地存储在类中,允许我在将其再次写入文件之前使用它(使用各种 get/set 类型方法)使用“commit”方法(调用setLocalFile)。
有各种这样的类对象被调用,但为每个数据文件实例化的对象绝不会超过一个。让我困惑的是,除了 FS 操作被忽略之外,一切都工作正常。一旦我直接访问文件(忽略我编写的类包装器),问题就消失了。
类包装器在应用程序的其他部分工作正常,这个问题只发生在它的一个复杂且相当密集的部分。
正如我所说,我只是在长时间缺席(并且发生了很多变化)之后才重新回到 Java,但是看看这个问题以及它如何“解决”本身,我的猜测是这是某种形式的线程/内存问题 -本质上,我从太多的对象访问 FS,最终它决定不再玩了。
正如我所说,问题已解决,但令我烦恼的是该解决方案不允许我更优雅地包装我的数据对象。如果有人可能提出此问题的原因/解决方案是什么,我会很乐意尝试并报告回来,否则此响应可能会帮助将来遇到类似问题的人 - 至少找到一个不优雅的 解决方案...
A belated update... Giving the code where this issue was occurring probably would not be too practical as I suspect one would practically need all of my code to examine it fully.
My variable names began with capitals largely because I've just been getting back into Java again after about 10 years with other languages, so it took me a while to get back into the swing of things - not pretty, but I would be surprised if it would have made a difference. Nonetheless, thanks guys for the responses.
The background to the issue was that I had decided to handle the data held in these files as class objects. So the Drafts object would hold all the draft documents and the class constructor would call the getLocalFile method and store it locally in the class, allowing me to work with it (using various get/set type methods), before writing it again to a file with a 'commit' method (calling setLocalFile).
There were various such class objects being called, but never more than one instantiated for each data file. What stumped me was that everything was working fine, except the FS operation was simply being ignored. Once I accessed the files directly (ignoring the class wrappers I'd written) the problem vanished.
The class wrappers work fine in other parts of the app and this problem only occurred in the one, complex and rather intensive, section of it.
As I said, I'm only getting back into Java after an extended absence (and much has changed), but looking at the issue and how it 'resolved' itself, my guess is that it was some form of thread / memory issue - essentially I was accessing the FS from too many objects and eventually it decided it didn't want to play anymore.
The problem, as I said, is resolved, but it bugs me that the solution did not allow me to wrap my data objects more elegantly. If someone might suggest what may the cause / solution for this, I'll happily try it out and report back, otherwise this response may help someone with a similar problem in the future - at least to find an inelegant solution...