快速,稳健地保存/加载文档状态,适用于图像编辑器

mem*_*com 7 java iphone serialization android image-processing

我正在寻找一些批评我的方法来存储Android和iPhone手机的位图编辑器的状态.即使是"看起来很好!" 回复会很棒!

在应用程序中,当前用户文档包含几个可以绘制的位图图层(每个可能是1024 x 768像素).该应用程序的基本要求是:

  1. 我需要能够保存和恢复文档状态.

  2. 当用户退出应用程序或接到电话时,我需要能够快速保存文档状态(大约2秒钟内).

  3. 如果应用程序崩溃,我需要能够恢复文档状态(如果用户失去可能30秒的工作,则可以).

对于1,我找不到任何支持图层的打开文件格式.我将使用以下文件结构来存储我的文档:

document_folder/
  layer1.png
  layer2.png
  ...
  metadata.xml
Run Code Online (Sandbox Code Playgroud)

图层只存储为.png文件,.xml文件包含数据,例如当前可见的图层.文档文件夹可以由应用程序按原样打开,也可以将文件夹存储在.zip文件中.对于其他应用程序来说,这似乎是一个很好的简单格式.

除了.png文件,我还允许以自定义.raw文件格式保存图层,其中包含来自位图的未处理原始像素数据.我可以在手机上快速保存这些(<0.5s),而.png文件需要一两秒钟.

我在启动时快速保存文档的计划是创建一个名为/ autosave的文件夹,并在那里保存所有图层的.raw版本.在一个图层上编辑几个命令之后,我会在后台线程中更新该图层的.raw文件.为了保存时的稳健性,我会将图层保存为例如layer1_tmp.raw,当我确认文件已完全写入时,将layer1.raw替换为此文件.

如果应用程序在使用过程中崩溃,我只需重新打开/ autosave文件夹.当应用程序关闭或用户接到电话时,我只需要将最后修改的层更新为自动保存.当用户想要保存时,我只是将所有.raw文件转换为.png文件,然后压缩文件夹.

你怎么看?有明显的缺陷吗?有更简单的方法吗?我不知怎的重新发明轮子?谢谢.

dbm*_*dbm 0

我认为你有一个很棒的计划。我可能会走同样的路(但这本身并不意味着什么:-)

我在想的是,如果您不仅可以有一个保存文件的工作线程,而且可以有一个完整的后台服务(当然有一个工作线程,因为服务本身也在主线程中运行)。

这样,您就可以保证总有一些活动可以处理您的图层增量,无论绘图活动是否崩溃或有人打电话给您。突然之间,您不再具有相同的计时约束(如果愿意,写入操作可以花费 10 秒,您的活动既不会被阻止,也不依赖于写入操作)。当然,当您的服务清空其保存队列(以节省系统资源)时,它就会自杀。

为了进一步推广这个想法,我不知道您要向原始文件写入多少数据?您每次都写入完整的 1024x768 层还是只重写更改的部分?我也不确定数据实际上如何传输到服务(从活动)。我不知道意图是否可以处理额外的字节数组的最大大小。

希望这能给您带来更多想法。

干杯!