Flex应该选择spark还是mx，有什么好纠结的

鱼(spark)，我所欲也，熊掌(mx)，亦我所欲也，二者不可得兼，舍鱼(spark)而取熊掌(mx)者也。

搞技术本身就很苦逼，何必折腾自己呢。简约是我的风格，也是我的态度。我为自己代言。

-------------------------------------------------华丽丽的分割线-------------------------------------------------

以下文章转自：http://bbs.9ria.com/thread-226659-1-1.html

骚年们，在你们看这篇贴子时一定要淡定，因为它也许会让你很痛苦，也许会让你很激动。我不仅要说慎用Spark组件，还要说最好禁用Spark组件。不管怎么样，Spark真的曾经让我不淡定过，但我现在淡定了，原因我将写在最后。

Adobe官方在Flex4（现在也该叫Flash Builder）发布之后，一直在推荐使用Spark组件，但本人要说的是Flex开发者应该慎用Spark组件。Adobe官方推荐Spark组件的原因很简单，因为Spark比旧的MX组件更轻量级，并且组件与皮肤分离（这里的组件与皮肤分离事实上是指组件的内容和业务，与皮肤文件分离）——之于Spark组件是否真的轻量级以及性能是否真的比MX高，我会在稍后继续写出。

Adobe的程序员们曾经有一个“非常好的初衷”，一个非常棒的想法，就是纯粹的将组件与皮肤分离，那绝对是类似W3C CSS标准对Web网页类似的大跃进。所以——事实上Flex4几乎与Adobe平面设计套装工具的CS5差不多时间发布，而CS5的套装中包含了一个叫Flash Catalyst的软件工具，这款工具是一款设计师使用的工具。

为什么要扯出Flash Catalyst这款工具？这款工具是本人写这篇贴子的理由——也是它最终导致Adobe的工程师们Spark组件推广失败最主要的原因，并且也是最终让Spark组件在Adobe公司只开发了部份对应的MX版本的组件，并且最终停止了更新Flash Catalyst，最后还将Flex4送给开源组织的等等的全部原因——而归根结缔这些原因在于前一段中“那个非常好的初衷”只是Adobe的工程师们的一厢情愿，为什么说他们一厢情愿了，又要在后面写出（- -，淡定、淡定）。

Flex的程序员们可能只有听过Flash Catalyst这款工具，但从来没有使用过这款工具（除非你既做PhotoShop、Illustrator、FireWorks <以下可能会用PS、AI、FW等来简称它们>等平面设计，又做FLEX程序开发）——没错，它就是Adobe开发用来将平面设计软件工具生成Flex皮肤的工具，它的最佳兼容工具是AI CS5（全称Adobe Illustrator CS5），有一个词叫“软件接力”，从PS到Flash Catalyst是单向的软件接力，因为一旦PS的文件导入到Flash Catalyst后，如果再想修改，就无法再从Flash Catalyst返回到PS了，但AI CS5就可以双向软件接力，一旦在Flash Catalyst中发现平面有需要修改的地方，仍然可以返回到AI中去修改，但必须是CS5以上的版本。

那么我就先在这里回答一下，为什么说Adobe的工程师们一厢情愿了。好吧，我承认我很啰嗦了，让我们再回想一下第三段中那个“非常好的初衷”吧，真的是非常棒——可是我要说的是在Flex开发过程中，这个非常棒的初衷实现不了，既便能实现，中小型的公司也实现不了，只有在一个非常大型的IT公司，并且具有一名非常优秀的项目经理人的情况下才能实现。原因主要有如下两个：

CSS对于Web是非编译性的，流程短，并且网页美工是专门学过DIV+CSS的，既便没有学过，个人站长对元素布局、样式设置等都可以按着项目的标准文档说明通过CSS来实现；而Spark皮肤文件对于Flex而言是编译性的，流程长（从PS、AI导出FXG，再导入到Flash Catalyst生成FXP，再导入到Flex），流程长就意义着中间契约的约束就越多，并且大多的平面或动画美工都没有学过Flex，所以在这个中间契约的过程中，他们根本不知道AS逻辑类中外观和部件分别是什么意思，MXML皮肤文件中的那些元标签和属性ID又是什么意思。有人有很长的文章去描述这些中间契约，也有专门的书籍用一整章的资料去介绍这个中间契约，好吧，我整理过了，已是把人家上万字的资料缩短到上百个字而已了，就在这个贴子中http://blog.zinewow.com/post/196.html，所以美工们制作的皮肤文件，对于Flex的程序员们来说，看起来很漂亮，可是那本就是个没法用的玩意儿；那么Flex程序们，你们懂PS、AI、Flash Catalyst这样为美工而开发的软件吗？那么这个艰巨的任务就落实在了项目经理身上了，必须得由项目经理来写一个完整的标准文档来约束（从项目的组织结构到每个软件的约定）这个工作流程了，而这种即懂设计类软件，又懂程序的项目经理多么？好吧，就当你们是个大公司有这样的项目经理，可每次皮肤的修改，项目都是要重新编译并且发布，你们不觉的蛋痛吗？至少我觉的比起CSS对于WEB的来说，它是非常蛋痛的（虽然从功能上来说FXG相对于CSS来说的无限制性的）。另外你也许会想说，你的皮肤文件FXG一旦创建了就可以共享到其它项目中直接可以使用，骚年，Flex CSS样式也是可以共享到其它项目中直接使用的，而且Flex是支持动态加载CSS样式文件的，根本不需要重新编译。美工可以随时在线更新CSS样式文件，而无需通过技术人员打开项目、重新编译、再发布到互联网。
骚年你是不是想说如果你不在这么一个大型的公司，就是在中小型的公司难道不可以吗？我就是自己一个人做完全部的工作流程，从平面设计、到布局、到状态过渡、再到业务逻辑处理，我是全能我骄傲，我一个人搞定全部。骚年，你真棒，你绝对是老板眼中的最爱。因为你做到了很少程序员能做到的事情，没错，老板就是这么想的，因为老板也是会这么要求你做的，因为Flex一直是属于前端程序的，在老板们眼里，只要是前端的，那么无论是界面设计、布局包括前端的业务逻辑，那必须都是得由Flex前端人员来完成滴，不会有专门给你配置专门的Flex美工滴。那么你一个人全部流程，你觉的你需要把工作流程弄的这么长吗？为什么不简化流程？曾看到很多人在一些QQ群里问，Spark组件XX样式属性为什么不能使用，YY样式为什么没有了，为什么提示缺少ZZ皮肤类等等。原因很简单，Spark中样式属性被阉割了许多，没有MX版本的多，Spark给你足够的自由度，让你自己用皮肤类去布局、加状态、加效果、加过渡等；MX简单明了，工作流短、并且简单明了，通过CSS来设置样式，状态、效果、过渡用FLEX程序员可以在组件类中直接实现，布局容器或布局组件类来实现布局。所以更多的单人项目，应选择功能更为强大的MX组件。

所以Flash Catalyst最后停止更新了，因为大中小型公司中没有太多的市场可用；而FLEX4的SDK也送给了开源组织Apache，骚年们，看到了没有，Adobe送的可是SDK，而不是FLEX 集成开发环境，所以你们在 Apache 官方主页是只能下载到FLEX 4.8和4.9等SDK滴，而不能下载到FLEX完整安装版本滴，而在现在在更新Spark组件的也正是Apache，没错Spark就是一个半成品、试验体、烂摊子，现在它在等着别人收拾。

不要忘了前面我留的三个问题，现在才回答了一个哦。接着回答“Spark组件是否真的轻量级以及性能是否真的比MX高”，骚年，Adobe为了推广他们的Spark组件当然会这么说，当然这么说也没有错，被阉割过功能的组件性能可会是会稍稍的高那么一些，但是我要告诉你的是，别撸多了，会伤身的——因为Spark组件并没有比现在的对应的MX高。原因又是如下两点：

首先，Spark组件是基于组合思想的实现，而MX组件是基于继承的组件；在AS3中，继于继承的代码执行效率比基于组合的代码执行效率高；FLEX4中的MX已经是经过优化的组件，相比于旧版本的MX组件来说，更确切它的新名称相对于Spark皮肤来说，它是Halo皮肤的组件；旧版中的MX是没有皮肤这种概念的，旧版本中的halo只是它引的命名空间包含了halo，并且是一种风格样式的意义，而不是FLEX4中的皮肤意义。
然后，不要拿不同的东西去比。你拿Group组件和Canvas去比，当然是Group更轻量级，性能更高；那我拿MovieClip或Sprite和你的Group比不是更轻量性能更高？我Canvas有滚动条和样式等许多功能，你Group有吗？你要比至少也得拿 Skinnable的Group再加Scroller后再来比吧。否则我就拿MC或SP的扩展类比死你，没拿Shape跟你就已经给你便宜了。

其实以上两个原因可以归纳一下，无论是Spark还是Halo，它们都是基于重量级的mx:UIComponent类的，这才是关键——有人说UIComponent继承的类和实现的接口等全部加起来有5万多行代码，也有人说是一万多行代码，我没数过，骚年我不是那么无聊的人，我无聊起来不是人——我给他们打个对折，算它只有5000行代码好了。就这么一个重量级的基类，如果说MX性能低，Spark还能高哪儿去？另外我想说的是代码的多少和性能的高低没有直接关系，要是你要是认为减少代码量能提高性能，那么你就从UIComponent类自定义扩展，只添加自己需要用的属性和方法，无全可以抛弃什么spark、mx神马滴，子对象直接用Sprite和Shape等扩展类，这样才是高性能。而在桌面的快速应用开发中，更应该选择功能更为强大的MX。

无论你选择的是MX还是Spark目的只有一个，那就是尽可能快速的开发，而不用自己去创建一个完整的UI组件库。所以选哪个对于天朝的中小型公司中上班的刁丝该明确了。你也许花了很长时间看完了这篇文章了，或许1小时才看完，不过很好，至少你接下来不用花一个月的时间去学习和研究Spark了。

但有些时候我们确实需要一些高性能的东西，该怎么办？我也在本文的第一段时留下了淡定的说法，这得感谢伟大的FlashPlayer11 & AIR3，感谢在它们中新增的Stage3D功能，感谢Starling将Stage3D的API简化成了以往2D的API，感谢Feathers组件通过Starling提供了可以在移动设备和桌面设备中真正轻量级、高性能的企业级开发组件。有了Starling我淡定了。