actionscript 3:加载器在容易出错的连接上默默失败

发布于 2024-09-12 10:24:44 字数 391 浏览 3 评论 0原文

我们的 Flash 应用程序必须从远程目标加载 50 个左右的文件。在正常网络条件下,这是没有问题的。然而,我们的一些用户开始报告应用程序在加载阶段“停止工作”。

经过一些测试,我们将网络质量降低到每 3 个数据包中有 1 个突发丢失的程度,我们成功地重现了错误报告。查看 firebug,似乎有一些文件(50 个文件中的 1 到 3 个)开始加载但从未完成。 ActionScript 中不会引发任何错误,也没有文件无法完成的明显模式。

有人以前遇到过这种情况并找到原因和/或解决方法来处理这些情况吗?

编写一些手动验证加载程序是否停止加载并重新启动加载过程的东西并不太难,但我想知道我们是否只是没有监听正确的错误事件(现在我们监听进度、完成和 IOErrors)或是否还有其他解决方案?

干杯 标记

Our Flash app has to load 50 or so files from a remote destination. Under normal network conditions, this is no problem. However some of our users started to report that the application "stopped working" during the loading phase.

After some tests where we decreased the network quality to a point where 1 out of 3 packets were dropped in bursts, we managed to reproduce the error reports. Looking at firebug, it appears as if a few of the files (1 to 3 out of the 50) begin loading but never complete. No errors are raised in ActionScript and there is no apparent pattern in which files fail to complete.

Has anybody run into situation before and found a cause and or fix to deal with these situations ?

It's not too hard to write something that manually verifies if loaders stop loading and restart the loading process, but I was wondering if we're simply not listening to the right error events (right now we listen to progress, complete, and IOErrors) or if there are other solutions ?

Cheers
Mark

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

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

发布评论

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

评论(6

友谊不毕业 2024-09-19 10:24:44

您如何处理所有这些加载?您只是使用 Loaders(或其子类,如 URLLoader)还是使用一个可以为您处理所有这些的库?

Greensock 的 LoaderMaxBulkLoader 是我在进行大量加载时使用的。我最近才开始使用 LoaderMax 而不是 BulkLoader,因为它具有一些不错的功能。

How are you handling doing all of this loading? Are you just using Loaders (or subclasses of, like URLLoader) or are you using a library that will handle all of these for you?

Greensock's LoaderMax and BulkLoader are what I use when I have mass loading to do. I only recently started using LoaderMax over BulkLoader because of some nice features it has.

╭ゆ眷念 2024-09-19 10:24:44

好吧,来自另一个帐户的迟来的跟进。

感谢您的所有建议。我们有一个解决方法,其中涉及当服务器未能及时响应或客户端在 X 时间内不再接收字节时重新安排负载。在最坏的情况下,这将意味着用户将不得不等待更长的时间。

不过,请求默默失败的原因仍然是个谜。

@Danyal - 很好的建议,我怀疑情况并非如此,因为我们的装载机是受管理的,但我必须检查一下才能 100% 确定。

Ok a long overdue follow up from a different account.

Thanks for all your suggestions. We've got a workaround which involves rescheduling loads when the server fails to respond in time or the client no longer receives bytes for X amount of time. At the worst this will mean users will have to wait a bit longer.

The cause of the requests silently failing is still a mystery though.

@Danyal - good suggestion, I suspect this isn't the case as our Loaders are managed, but I'll have to check to be 100% sure.

诗笺 2024-09-19 10:24:44

您可能需要检查的一件事是,如果您同时发出所有这些请求,它们的加载可能会超时并导致您的文件无法加载。服务器通常对其可以处理的并发请求数量有限制。

因此,最好管理您的加载,以便您一个接一个地加载项目,而不是启动所有项目并等待它们全部完成。

One things you might want to take a look into is if you're making all of these requests all at once they loading might timeout and cause your files not to load. Servers often have limitations on how many concurrent requests it can serve up.

Therefore, it's good practice to manage your loading so that you load items one after another rather than start them all and wait until they all finish.

梦屿孤独相伴 2024-09-19 10:24:44

您是否检查过是否维护了对加载程序的引用?如果您将加载器定义为具有弱侦听器的局部变量,则它们有可能在加载过程完成之前被垃圾收集,并且失败将是无声的。

Have you checked that you are maintaining references to your loaders? If you are defining loaders as local variables with weak listeners there is the chance that they could be garbage collected before the loading process completes, and the failure will be silent.

浅浅淡淡 2024-09-19 10:24:44

raix,虽然严格来说不是一个加载库,但在 加载多个 XML 文档并输出类型化值 其中包括处理错误和超时。

下面的代码加载一个 XML 文档,并在 10 秒后回退到静态版本(尽管它可以轻松地在两者之间链接另一个 XML 加载):

Observable.xml(new URLRequest(xmlDocumentURL))
    .timeout(10000, Observable.returnValue(defaultProductCategories))
    .subscribe(function(xml : XML) : void
    {
        trace("Either way, we have an XML document");
    });

raix, while strictly speaking is not a loading library, has an example on Loading multiple XML documents and outputting a typed value which including handling errors and timeouts.

The code below loads an XML document and falls back to a static version after 10 seconds (though it could easily chain another XML load between the two):

Observable.xml(new URLRequest(xmlDocumentURL))
    .timeout(10000, Observable.returnValue(defaultProductCategories))
    .subscribe(function(xml : XML) : void
    {
        trace("Either way, we have an XML document");
    });
十年九夏 2024-09-19 10:24:44

我有一个 adobe Air 移动应用程序,它从由 PHP 文件提供的 URL 加载。我的加载程序会默默地失败并且不返回任何数据(使用通用加载程序或 Greensock)。所以我做了你最终做的事情,只是检查无提示的失败并简单地重试。这有效,但我意识到这是多么荒谬,而且与调试模拟器相比,移动设备上的情况变得更糟。

这是我发现的修复方法,或者至少大大减少了失败的数量:

旧方法:
在我的 PHP 文件中,我将运行数据库查询,将数据打包为 XML 格式,将任何二进制文件转换为 Base64,然后发送标头信息,然后回显出我完成的 XML。

新方式:
我所做的是立即尽快发送我的标头信息,然后执行 PHP flush(); ,然后进行数据库查询、xml 打包和编码,然后 echo 输出完成的内容XML。

到目前为止似乎已经修复了它,我仍然检查故障,但还有很多。

我的服务器也有足够的能力处理这些请求,而且我不会打包那么大的 XML,甚至不会考虑它需要初步刷新。另外,当我从网络浏览器加载该 URL 时,一切都工作正常。这就是为什么我从来不认为这是一个问题。

我相信现在修复它的原因是因为通过尽快发送标头,应用程序知道其请求已被确认并且数据即将到来。看起来 http 请求的超时时间非常短暂(至少在 AS3 中),导致大量失败。

I have an adobe Air mobile application that loads from an URL which is served up by a PHP file. My loader would silently fail and not return any data (using generic loader OR Greensock). So I did what you ended up doing by just checking for a silent fail and simply retrying. This worked, but I realized how ridiculous this was, plus the situation got worse on the mobile device as opposed to the debugging simulator.

Here is what I found as a fix or has at least greatly alleviated the amount of failures:

Old way:
In my PHP file I would run a database query, package up the data formatted into XML, convert any binary to Base64 and then I would send the header information followed by echoing out my completed XML.

New way:
What I did was right away send my header information ASAP, then do a PHP flush(); followed by my database query, xml packaging and encoding, then echo out the completed XML.

So far seems to have fixed it, I still check for failures, but there are MANY less.

My server is also plenty capable of handling these requests, and I am not packaging that big of an XML to even consider it needing a preliminary flush. Plus when I load that URL from a web browser, everything works fine, always. Which is why I never considered that to be an issue.

I believe the reason it is fixed now is because by sending the headers ASAP the application knows that its request was acknowledged and data will be coming. It would seem that http requests are very short-lived for their timeouts (at least in AS3), causing the mass amount of failures.

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