我有一位客户问我“从AS2 / Flash升级到AS3 / Flex有什么优缺点？”他的应用程序存在性能和可维护性问题。
我讨厌这些问题，因为我只想说“AS3 / Flex会更快，更易于维护”，但我知道我应该更具体。该应用程序接近100,000行代码，文档记录很少，并且UI似乎都是动态生成的。
显然，从Flash / AS2迁移到Flex / AS3的成本很高，但提高速度和可维护性是否值得？有谁知道它将在多大程度上提高速度和可维护性？在AS2中你有什么不能做的吗？我猜不会。你在AS3中可以做的事情是否真的很重要，你不能在AS2中做到这一点？
我想这个问题的后半部分是在与客户打交道时如何正确回答这些问题？如果不花费很多时间查看成千上万行代码，我不确定我是否可以非常准确。
谢谢！
答案 0 :(得分：3)
<强>性能 由于您有100,000行代码，因此在VM上执行代码的速度要快10倍（如adobe所说）肯定会提高性能。但是当前应用程序的性能如何？如果它足够好，那么你真的不应该考虑这个专业人士。
可维护性和可重用性 如果当前代码库难以维护且不可重用，那么它需要重构，而不是用新语言重写。 AS3确实鼓励有助于可维护性和可重用性的编码实践，但这并不意味着您和您的团队将遵循它们。使用AS3也可能最终得到一个难以维护的代码库。也可以以可维护和可重用的方式重构AS2代码。
新技术 我相信这是唯一真正的职业选手。 Flex / AS3是一项新技术。这是一个很好，干净的。很多人都强烈支持它。 Adobe正在推动每个人从AS2切换到AS3。聘请新的AS2开发人员将变得越来越难。支持AS2的开发工具将会减少。而我的猜测你迟早要做出改变。
所以，IMO，除了这里列出的所有利弊，你需要让你的客户明白，如果你要定期更新应用程序，这迟早要做。而且我认为你不应该急于这样做。
答案 1 :(得分：2)
维基百科有一个很好的Flash Player版本新功能列表：
http://en.wikipedia.org/wiki/Adobe_Flash_Player
从版本9开始的所有内容仅适用于AS3。以下是一些重点，包括我自己的一些内容：
编写了在FP8（Flex 1.5）和FP9 +（Flex 2+）下运行的Flex应用程序，我可以告诉您它的速度要快得多。对于人们每天花费大量时间的商业应用程序，我认为这可能是一个显着的改进，可以减少最终用户的头发拉动。对于字符串连接和数组排序等低级操作，存在性能指标，但这些指标并不等同于您在实际应用程序中看到的性能增益。实际上，它们会更小，但可以衡量。
最终，您可以做的最好的事情是向他们估算维护应用程序的成本与重写和添加后续功能的成本。如果他们不打算在应用程序中进行大量更改，则重写可能不值得。但是如果应用程序添加了很多功能，并且您觉得使用Flex和AS3可以显着提高效率，那么您应该能够向他们展示数字并让他们根据这些数据做出决定。
答案 2 :(得分：2)
升级的最大和最重要的原因是，就Adobe而言，AS2是一种死语言。 AS2在它自己的特殊VM（准确地说是AVM1）内部运行，它与Flash播放器的其余部分一起消失，永远停留在Flash 8的世界中。没有任何新功能或优化可以回到AS2 - 期间
此外，如果这个应用程序将持续很长时间，重要的是要了解知道和理解AS2的开发人员的数量随着时间的推移会逐渐减少。如果在应用程序中发生跳转到AS3，那么尽早（而且可能更便宜）做到这一点会更快，而不是更晚。
答案 3 :(得分：1)
其他答案很好地涵盖了基础，但我只是贡献了性能方面，编写良好的AS3的脚本执行往往比AS2在AS3中的执行速度快3到100倍。它根据所做的事情而有很大差异。但请注意，对于大多数应用程序，性能问题并非完全或甚至主要是由于脚本执行。通常渲染是最大的瓶颈，在这种情况下，切换到新的AS3 VM可能会产生适度的好处，甚至可能根本没有。只有分析才能判断您的特定应用程序是否会显着改善性能。
但这只是为了填写讨论。我同意其他评论者的观点，最大的问题是许多新功能仅适用于新VM。请记住，这不仅仅是切换语言的问题 - Flash播放器当前有两个不同的虚拟机，而AS2 VM现在基本上是一个遗留应用程序。
其他人没有涉及的另一件事 - AS2和AS3内容之间的互操作性非常差。如果您可能正在加载外部内容（SWF），或尝试使用第三方库（图形组件或类似的东西），您可能会发现大多数此类内容已经是AS3，而AS2的内容只会越来越少了。
答案 4 :(得分：1)
AS3优于AS2--上面有很多原因，包括VM性能，更严格的编译器，用于执行更清晰的编码实践（严格打字等）。我没有看到有人提到你可以在运行时在AS3中更改对象的父对象，这是你在AS2中无法做到的事情，如果遇到这个问题，你就会知道路障是多么令人失望。
但是，更重要的是，当你在AS3中编写代码时，他们的工作正如他们所支持的那样。没有这个古怪的AS2，你可以在相当规律的基础上发现错误，缺点和奇怪的代码限制结果！
如果您正在考虑移植/重写，您还应该考虑如果您的开发团队对AS2有经验而不是AS3，您可能需要等待的任何学习曲线。
拥有100,000行代码库（任何actionscript标准都非常庞大），除非代码记录完整，优雅且有条理，否则移植将成为一场噩梦。你可能会发现，从为头部重新编写开始为应用程序构建一个更高效和有组织的框架/设计模式最终会大大削减代码库的大小...也许它只需要一个50,000行代码库，如果它是做对了吗？
祝你好运！答案 5 :(得分：0)
我个人永远不会忍受AS2并在3之前完全避免使用该语言。其他人已经发布了很多理由，但这里有一个快速列表：
对我而言，选择不是Flash / AS2和Flex / AS3 - 你根本不会失去Flash ......您只能获得Flash，Flex和纯AS3。
答案 6 :(得分：0)
我建议将一个100,000行应用程序从AS2移植到AS3，与从头开始完全重建的做法几乎没有什么不同，考虑到需要花费的时间。您会发现，甚至可能不需要这些100,000行中的许多行。如果代码包含任何类型的框架等，我会更担心，因为您可能必须自己移植这些，此时您可能刚刚重新开始。您的客户需要考虑他们希望这个项目存活多久。如果不到几年，我说不要打扰。如果这个应用程序是他们的整个业务，我说时间版本2.0，当你在AS3重写功能时，花时间来改善应用程序的功能和可用性。
答案 7 :(得分：0)
我不太了解整个AS2抨击的事情......我知道只有极少数人真正了解AS2的伟大可能性... AS2可以与Ruby相比，而AS3只是Java的地方是10年前...是的它很慢，但它比AS3更强大和更具表现力...我不知道AS3有什么基本功能，AS2没有（不要混淆语言和API），除了正确的错误处理... on a moreless related topic, i got in to details recently ... AS3可以访问更大的API，但大多数重要的事情都不是你在商业应用程序中非常需要的......
AS2可以高效率和优雅，如果你真的完全使用它...如果你想在AS3中具有与AS2相同的灵活性（或至少你可以得到的最佳近似值），你会发现你的大部分代码执行速度超出了窗口......
我很认真... 如果您想要定位AVM2，请使用Flex通过MXML以及尽可能少的AS3，或Haxe ...如果快速开发，请使用Flex对你来说很重要，而Haxe如果更关注性能（嗯，还有其他理由这样做，但我认为它们更主观）......
直到今天AS3已经走到了尽头......自推出以来，该语言并未发生一些变化......确定，flashplayer具有新功能，但AS3自3年前发布以来一直保持AS3，除了Vector，这只是一些非常糟糕的事情...你可能要注意从AS1到AS2需要3年时间，从AS2到AS3需要3年......现在是AS4的时候了，但是Adobe似乎没有在这样的事情上工作......相反，他们专注于越来越多地扩展他们的产品调色板......
从理论上讲，我得到的印象是，你有大约10万行意大利面条代码......所以实际的问题是代码，而不是语言...你需要重写...如果你觉得它有意义，你甚至可以在AS2中重写它（虽然我仍然建议使用Haxe）......实际使用AS2的唯一一点就是你可以复制并粘贴一些实现，如果你幸运的话......但是你真的应该从头开始构建一个干净的应用程序，使用你使用的语言提供的最好的，作为OOP，AOP和FP的一个子集（Haxe / AVM1将允许所有这些事情）或声明方法，如MXML允许的那样...
除了显而易见的问题，即成本，没有重写的意思......专家是你用更好的代码库，更可维护，更灵活，甚至可能表现更好，或至少它使分析和后来的优化更容易...... 语言的表现力是一个因素，当谈到编写好的代码时，仅仅因为开发人员很懒，但除此之外，它对性能和生产力没有影响......
...我建议你告诉他们一个简单的事实：他们可以拥有一个软件，以最低的价格提供一套固定的功能（这可能是他们现在所拥有的，在你的情况下），或者他们可以拥有灵活/可扩展/精心设计的软件......即使他们选择了后者，他们也必须接受，每隔一段时间你就需要采取激烈的措施，例如重写......代码不断降级是一个不可否认的现象......当你设计一个软件时，你就会开始决定它可以在哪个方向上进化，而你却无法做到这一点，在这个方面，为实现功能添加了晦涩的脏黑客网络，该软件没有进行布局，会使任何进一步的扩展变得不经济......当您要扩展的软件（无论是否属于您）时，请毫不犹豫地向您的客户指出，这是一个非常好的观点。重写，而不是让他们支付额外的fu所需的所有低效工作他们需要的功能......软件扩展的成本在数量上有所增长......在重写之后，这个成本会回到“接近0的浅部分”......这取决于你自己的专业知识来确定重要的是做一次重写更有意义（如果只需要通过100K行代码来实际进行评估，那么在我看来这显然是重写的好时机）...了解你的想法在哪里软件应该去，需要什么，并选择最有效的方式...
答案 8 :(得分：-3)
在查看升级应用程序代码库之前，我会扩展硬件（特别是如果您认为升级很困难）。扩展硬件既快又便宜。