“Adobe Flex”和“Adobe Flex”有什么区别？以及使用 fl.controls 和 fl.events 库的 AS3 应用程序？
像这篇文章似乎可以说 Flex 是一个用于制作在 Flash Player 中运行的类似桌面应用程序的库。但令我困惑的是，我已经构建了模仿桌面外观和感觉而没有任何“灵活性”的 AS3 应用程序。我使用名为 fl.controls 和 fl.events 的库，它工作得非常好，带有按钮、文本框、列表框、组合框等。
帮助我解决这个问题。 fl.controls和fl.events实际上是flex的一部分，但我从未意识到这一点？或者它们是一个竞争性的小部件库/框架，但出于营销原因 Adobe 没有费心指定一个像“flex”这样性感的名字？
如果 flex 与 fl.controls 和 fl.events 不同，您可以在 flex / AIR 应用程序中使用这些库吗？ （我不关心“flex”方面，只想制作 AIR 应用程序）或者是一个非此即彼的问题，是 fl.* 还是单个项目中的 flex 库？
另外，为了清楚起见，我现在在 FlashDevelop 中工作，而不是在 Adobe 的任何专有 IDE 中工作。所以我想我对基于“特定库附带的 IDE 版本”的软件包之间的差异有点迷失了。
articles like this one seem to say that Flex is a library for making desktop-like applications that run in Flash Player. But what confuses me is that I have already built AS3 applications that imitate desktop look and feel without any "flex". I use libraries called fl.controls and fl.events, and it worked perfectly fine, with buttons, textboxes, listboxes, combo boxes etc.
Help me get my head around this issue. Is fl.controls and fl.events actually a part of flex, but I never realized this? Or are they a competing widget library/framework, but one that for marketing reasons Adobe did not bother assigning a sexy name like "flex"?
If flex is distinct from fl.controls and fl.events, can you use these libraries in a flex / AIR app? (I don't care about the "flex" aspect, just want to make AIR apps) Or is it a matter of either-or, either the fl.* or the flex libraries in a single project?
Also, for clarity, I am now working in FlashDevelop and not in any of Adobe's proprietary IDE's. So I guess the difference between packages based on "which version of IDE got shipped with the particular library" is sort of lost on me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
据我所知，
fl.controls库实际上只是一堆可以在 Flash 中使用的小部件。另一方面，Flex 是一个应用程序开发框架，具有一系列丰富的开发功能，这是单独使用 AS3 和 fl.controls 无法获得的。Flex 为您提供的一些功能：
默认情况下，当您在 Flash Builder 中创建新的 Flex 项目时，不会导入这些控件。然而，这似乎是可能的。
据我所知，这样做的用例并不多（除了集成遗留代码），因为与
fl.controls相比，Flex 提供了一切，甚至更多。The
fl.controlslibrary, from what I can tell, is really just a bunch of widgets you can use in Flash. Flex, on the other hand, is an application development framework with a set rich development capabilities you can't get using AS3 andfl.controlsalone.Some of the things that Flex get you:
By default, these controls are not imported when you create a new Flex project in Flash Builder. It appears, however, that it is possible.
From what I can tell, there aren't many use cases for doing this (other than integrating legacy code) since Flex provides everything and more compared to the
fl.controls.fl.controls.*是 Flash Professional 中使用的组件。它们类似于 Flex 框架中的mx或spark组件。然而，Flexspark组件比 Flash Professional 组件先进得多，但我相信当您使用 Flex 组件时，您必须将 MXML 代码与 AS3（而不仅仅是 AS3）结合使用。fl.controls.*are components used in Flash Professional. they are akin tomxorsparkcomponents in the Flex framework. however, the Flexsparkcomponents are much more advanced than the Flash Professional components, but i believe you'll have to use MXML code with AS3 (instead of just AS3) when you use Flex components.当将 Flex 用于台式计算机时，上述答案是合理的，但对于移动设备，问题更为复杂。 Flex 的易于开发优势伴随着性能损失，这对于移动开发来说是一个大问题。通过消除状态和数据绑定，可以实现所需的性能提升。有许多 Adobe 文档建议不要使用它们。为了轻松消除这些问题，我发现最简单的方法就是不使用 mxml。因为，当以编程方式实例化图形组件时，最容易在没有状态的情况下相处。
Spark.Components 和 fl.controls 都可以换肤。不同之处在于，spark.components 有一个可换肤界面，允许用户使用许多不同的皮肤来为相同的组件换肤。对我来说，这是一个优雅的功能，但我还没有看到需要。尽管如此，我可以想象为多个客户开发相同组件的公司会发现这非常有用。
我希望我可以在这里报告 fl.controls 与 Spark.components 的相对性能。如果有人有这样的数据，请发布。通过查看类层次结构，可以清楚地看出 fl.controls 的重量更轻，但如果能够衡量这一优势那就太好了。
The above answers are reasonable when using Flex for desktop computers, but for mobile devices the question is more complex. The ease of development advantages of Flex come with a performance penalty that is a great problem for mobile development. One can achieve needed performance gains by eliminating states and data binding. There are a number Adobe documents recommending not using them. And in order to eliminate these easily, I have found it easiest to also not use mxml. Because, it is easiest to get along without states when graphical components are instantiated programmatically.
Both spark.components and fl.controls can be skinned. The difference is that spark.components have a skinnable interface that allows one to skin the same components with many different skins. For me, this is an elegant feature for which I have not yet seen a requirement. Although, I can imagine firms that develop the same components for multiple customers find this very useful.
I wish that I could report here on the relative performance of fl.controls vs spark.components. If anyone has such data, please post it. By viewing the class hierarchy it is clear that fl.controls are lighter weight, but it would be nice to be able to measure that advantage.