更新与应用程序捆绑的图像的更好方法

发布于 2024-11-08 06:12:28 字数 448 浏览 4 评论 0原文

在我们的 iOS 应用程序中,我们的资源包中有近一百个图像文件。现在我们希望使它们基于网络,因为图像可能随时更改(更新/不再需要/添加)。我们正在讨论哪种方法是最佳的。根据我所读到的内容,我了解到资源包在设备上不可编辑。因此,当我启动应用程序时,我将从服务器检查是否有任何图像更新。如果是这样,我将下载更改后的图像,然后将它们保存到文档目录中。然后在应用程序中,对于每个图像,我基本上必须检查它是否在资源包中,然后从那里获取它。否则从文档目录中选择它并显示它。

另一种方法是我的资源文件夹中没有任何内容,我从服务器下载应用程序启动时的所有图像并将它们存储到文档目录中,然后在后续应用程序启动时下载更改的文件。在这里,我消除了对资源文件夹是否存在图像的检查,并且我的应用程序包大小将会减小。

第三种方法是在首次启动时将文件从我的资源目录复制到文档目录,然后从文档目录继续。

从性能的角度来看,有什么更好的方法或者所有方法都相似的建议吗?

In our iOS app we have close to a hundred image files in resources bundle. Now we want to make them network based since the images may change (updated/no longer needed/additions) at any time. We are debating at what approach would be optimal. From what I have read, I understand that the resource bundle will not be editable on the device. So, when I start the app, I will check from the server if there are any image updates. If so, I will download the changed images and then save them to documents directory. Then in the app, for every image, I will basically have to check if it is in the resources bundle, then grab it from there. Else pick it from documents directory and display it.

Another approach is I don't have anything in the resources folder, I download all images on app launch from the server and store them to documents directory and then on, download the changed files at subsequent app launch. Here I am eliminating the check on resources folder if an image is present or not and my app bundle size would be reduced.

The third approach would be to copy the files from my resources directory to the documents directory on first launch and thereafter continue from documents directory.

Any suggestions on what would be a better approach or all of them would be similar from the performance point of view?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

黑色毁心梦 2024-11-15 06:12:28

IMO,选项三在消除不必要的代码和预加载尽可能多的数据之间提供了最佳平衡。您不想让用户在应用第一次启动时等待 100 个图像下载,因此预加载尽可能多的图像。复制代码很简单,只会使用一次。这样就消除了您必须使用其他选项进行的运行时检查。

IMO, option three offers the best balance between eliminating needless code and preloading as much data as possible. You don't want to make the user wait for 100 image downloads when the app starts the first time, so pre-load as many as possible. The copy code is simple and will only be used once. So that eliminates the runtime checks you'd have to do with the other options.

凶凌 2024-11-15 06:12:28

不用担心,性能不会成为问题,除非您使用特别不明智的图像查找算法。

对于如此少量的文件,文件系统遍历应该相当快。

No worries, performance will not be an issue, unless you use a particularly unwise image lookup algorithm.

Filesystem traversal should be pretty fast for such a small amount of files.

完美的未来在梦里 2024-11-15 06:12:28

在自己实现某些东西之前,我建议您查看现成的图像缓存工具。即来自 EnormEgo 的 EGOImageView。

我已经在几个依赖于从 URL 抓取图像的应用程序中使用了它。它会为您处理一切,您只需设置一个“背景”图像以供其显示,同时它会在后台抓取基于 URL 的图像。第二次使用时,立即可用。绝对得到我对易用性的投票...

ps它是免费使用的

Before implementing something yourself, I would recommend looking at something off the shelf for Image Caching. Namely EGOImageView from EnormEgo.

I have used it in several applications which are dependent on grabbing images from URLs. It handles everything for you, you just set up a 'background' image for it to show while it goes about it's business of grabbing the URL based image in the background. The second time you use it, it's available immediately. Definitely gets my vote for ease of use...

p.s. it's free to use

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文