大规模闪存生产的最佳实践是什么？
我说的是几千个Flash动画等。自然有很多文件管理。
人们如何管理 DAM、CMS 等此类资产？
swf、图像、字体的最佳实践，以将大小保持在最小。 压缩方案？
送货怎么样？ 这种规模需要什么样的服务器？
I am talking about several thousands of flash animations etc. Naturally there is lot of file management.
How do people manage these kind of assets like DAM, CMS?
Best practices for swfs, images, fonts to keep the size to minimum. Compression scheme?
What about delivery? What kind of servers are needed for this scale?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
你的问题非常广泛，很难回答，因为我们不知道任何细节。 然而，有许多工具可供您使用，它们可能会让您的生活变得更轻松，具体取决于您想要做什么。
关于 Flash/Actionscript，有大量工具可以让您的生活变得更轻松，特别是在开源领域。 例如，您可以让服务器根据用户的请求动态生成 swf。 这样您就不必预先预先生成每个 swf。 根据数据库中存储的数据，您可以使用服务器端脚本生成 XML 文档，然后将该文档提供给名为 swfmill。 Swfmill 基本上是一个命令行编译器，它将 XML 文档形式的 swf 描述作为输入，并生成 swf 作为输出。 Swfmill 不执行脚本（逻辑），但它可以让您嵌入字体、位图、矢量艺术等。
然后有 MTASC (AS2) 和 Haxe。 两者都是可以生成 swf 文件的命令行编译器。 MTASC 是围绕 ActionScript 2 构建的，而 Haxe 是它自己的语言，与 Actionscrip 非常相似。 同样，根据对服务器的请求，您甚至可以在服务器上生成 Actionscript/Haxe，对其进行编译并将其注入到 swfmill 创建的 swf 中，然后将其提供给用户。
使用版本控制和脚本化构建。 在大型系统上，最好采用脚本化构建。 理想情况下，有一个命令可以重建整个系统。 尽量避免任何手动交互，在有压力的时候会出错。 有一些软件系统可以帮助您解决此问题，例如 Cruise Control。
再说一次，我不知道你想要完成什么，所以我不能更具体。
在可用性方面，您将必须深入研究网格和云计算的世界。 这是一门需要单独处理的黑术。 正如其他地方所建议的，您可能想在 ServerFault 上提出更具体的问题。 但与此同时，请查看 highscalability.com。 他们的 Real Live Architecture 部分中有一些非常有趣的文章，讨论了 Digg、eBay、YouTube 如何还有更多的网站在高压下进行了扩展。
祝你好运！
Your question is quite broad and difficult to answer since we do not know any of the specifics. However, there are a number of tools available to you that could potentially make your live easier depending on what you're trying to do.
Concerning Flash/Actionscript, there is quite a plethora of tools available to make your live easier, especially in the open source space. E.g. you can have the server generate swf's on the fly depending on what the user is requesting. This way you don't have to pre-generate every swf up-front. Based on data stored in a database you can use a server-side script that will generate an XML document that is then fed to a tool called swfmill. Swfmill is basically a command-line compiler that takes a description of a swf in the form of an XML document as input and produces a swf as output. Swfmill doesn't do script (logic) though, it will however let you embed fonts, bitmaps, vector art etc.
Then there are MTASC (AS2) and Haxe. Both are command-line compilers that can produce swf files. MTASC is build around ActionScript 2 whereas Haxe is it's own language and very similar to Actionscrip. Again, based on the request to the server you can even generate Actionscript/Haxe on the server, compile it and inject it into a swf created by swfmill to then serve it to the user.
Use version control and scripted builds. On large systems it's a good idea to have scripted builds. Ideally there is one command that can rebuild the entire system. Try to avoid any manual interactions, it will go wrong during times of pressure. There are software systems that can help you with this like Cruise Control.
Again, I don't what you're trying to accomplish so I can't be more specific.
In terms of availability you will have to dive into the world Grid and Cloud Computing. This is a black art that needs its own treatment. As suggested elsewhere, you might want to ask more specific questions on ServerFault. In the meantime however, check out highscalability.com. They have some really interesting articles in their Real Live Architecture section that discusses how Digg, eBay, YouTube and many more websites have been made to scale under high pressure.
Good luck!
将所有文件存储在 DAM（例如 Artesia）上，用于管理闪存文件。 接下来，我们构建了所有应用程序以集成到 DAM 中进行交付。
Store all the files on a DAM like Artesia for managing the flash files. Next, we built all our apps to integrate into the DAM for delivery.
只是一个想法，不是完整的答案：
您可能需要考虑“在云中”托管，例如 Amazon 的解决方案（商业） 和 Google（免费开始）。 随着您的资源需求的增长，这些服务可以轻松扩展。
另外，据我所知，Flash SWF 文件已经被压缩，但是有一些优化器，例如 this （商业）。
Just a thought, not a complete answer:
You might want to consider hosting "in the cloud" like the solutions from Amazon (commercial) and Google (free to start). These services offer easy scalability as your resource needs grow.
Also, as far as I know, Flash SWF files are already compressed, but there are some optimizers like this one (commercial).
SWF 文件将相当小，除非它们有导出的 fla 中不需要的额外库项目。 它们也被压缩（在大多数情况下），所以我不用担心文件本身。 我的公司每天可能提供 10 万个 SWF，并在负载均衡器后面运行 IIS 的 3 个 Web 服务器上进行。 这些服务器上的 CPU 永远不会变得很高（肯定低于 10%）。 我们使用一台共享存储设备来提供来自 SMB 的所有文件。 它运作得相当好。
SWF files are going to be fairly small unless they have extra library items that they don't need in the fla they were exported from. They are also zipped (in most cases) so I wouldn't worry about the files themselves. My company serve maybe 100k SWFs a day and do it on 3 web servers running IIS behind a load balancer. The CPU on those servers never goes very high (less than 10% for sure). We use one shared storage device to serve all the files from over SMB. It works rather well.
我总是尝试将 ActionScript 保留在 .as 文件中，并将该文件 #include 到脚本所需的框架中。 这使得在版本控制系统中跟踪脚本更改变得更加容易。 否则，如果您在 .fla 中嵌入 ActionScript，则无法区分版本之间的文件更改（AFAIK）。 我使用 TortoiseSVN 进行版本控制。
I always try to keep the ActionScript in a .as file and #include that file into the frame that the script is needed. This makes it easier to track the script changes in a version control system. Otherwise, if you embed the ActionScript in the .fla, you can't diff file changes between versions AFAIK. I use TortoiseSVN for version control.