FlexLite 为游戏而生的轻量级UI框架

   先扯一段前言，谈谈动机，若没时间看，建议直接跳过无视它。
======================前言分隔线==========================

        最近Flash Builder4.7移除了Flex设计视图的事被讨论的很热。有部分人觉得很可惜，也有人觉得无所谓。我也谈谈我的看法。认为无所谓的，我猜大部分应该都是游戏开发者，因为我也是其中之一。Adobe当初推出Flex的时候，是针对企业级应用市场的。四年前那个时候RIA的概念非常火，我也是那时候开始接触Flex的，那时候Flex4还在Beta版。Adobe也没想到，几年后企业级应用市场会被游戏开发远远甩在后面。经历了数个RIA外包后，我也转型到现在的游戏开发行业了。从Flex项目到纯AS项目的转换，让我突然无比怀念Flex的高效工作流。相信用纯AS拼过游戏UI面板的同行，一定能深深明白其中的抓狂感受。。。原先轻松欢乐的拼UI过程，在游戏开发中却成烫手山芋。我甚至有同事因为一直被分到做这个，最终转行了 。我们怀念的是自动布局，是皮肤分离，是可视化的所见即所得。

       游戏开发为什么不直接用Flex？

      Flex一开始就是设计给企业级应用的，框架中的很大部分功能在游戏中是用不着的。比如DataGrid这种超重量级组件。还有大量为方便企业级应用开发而设计的机制。它有绑定机制，它有全局样式继承体系，spark组件的皮肤甚至是完全搭建于矢量绘图元素之上的，更不用说为了向后兼容Flex3，包含的大量兼容性代码。看看拥有1万4千行代码的顶级基类UIComponent，你的组件想要轻量都是很难的。再说绑定机制，看上去代码很简洁，就一个[Bindable]标签而已。但是你用mxmlc编译一个文件，设置参数keep-generated-actionscript=true,就能看到，多了这一个标签，编译器帮你自动生成了多少代码。对于游戏开发这种性能权重较高的项目来说，是否使用它要根据实际情况认真考虑下才行。

         Adobe为什么捐赠Flex？

        在此只谈下个人观点。我认为这个决策是正确的，Adobe今后会更加专注Flash的发展路线：侧重于游戏。目前Flex的地位其实是比较尴尬的，因为Flash在游戏行业的份额远远超过了企业级应用。而Flex无论在Web端游戏还是移动端都不具有性能优势。加上已经设计的如此庞大的框架体系，想要向后兼容又为游戏瘦身是自相矛盾的。商业利益驱动下，自然是要捐出去的。好集中所有资源做更有价值的事。不仅Flex，移动端的FP也是同理。果断放弃现在才能全力投入Flash核心功能开发上，不断提升性能。如今FP和AIR的版本迭代比以往任何时候都更迅速了，而且针对游戏开发的新功能越来越多。而核心性能的提高，也带动了第三方框架的发展，比如Starling。Adobe专注核心开发+第三方有针对性框架的发展，会比一个大一统的框架有钱途。

         Flex是性能非常优秀的框架

        前面才分析过了Flex的性能，我这是在自相矛盾吗？：当然不是。这两者并不冲突，前面提到的内容，主要是框架整体。Flex的性能不高也是针对游戏而言，只是被加上了太多的“额外功能”而已。请不要继续停留在Flex性能低下的印象里。为什么这么说？典型的例子：如果你完全看懂了Flex无处不在的“三阶段布局渲染”机制，再回头比较下你现在所使用的”UI框架“，你就不会再认为它性能低下了。关于这个内容，请自行google或者阅读Flex SDK源码，关键词：LayoutManager 。Flex提出了一套完整高效的UI自动布局机制，延迟渲染贯穿其中，既有效避免了大量重复处理操作又带来了最易用的自动布局接口。可惜被Flex其他部分给拖累了，给人造成了貌似Flex设计有问题的错误印象。另外它的组合式组件结构，依赖注入的设计，皮肤分离等机制，都非常值得学习。曾经尝试过一些其他语言的原生UI框架，Flex始终是我认为的设计最好的UI框架，不带之一。

===========================前言分隔线==============================

       做减法不做加法

      我们之前的项目， 粗略估计，UI部分的工作时间已经快接近一半了。痛苦而漫长。而且UI改版几乎是不可避免的，一旦改版又要从头来过。为了彻底改变这个状况，提升开发效率。我们在8个月前发起了这个项目FlexLite，希望设计一个为游戏而生的轻量级UI框架。只从Flex里剥离出针对游戏开发有用的部分：我们保留了自动布局，皮肤分离等机制。剔除所有不相关的或者影响性能的代码：以1000行的核心代码重写并实现了UIComponent。并改写部分逻辑以更加灵活地适应游戏开发需求：扩展spark的皮肤机制，让它支持所有类型的皮肤注入。“所有”是什么概念？可以是spark原生支持的绘图元素(绘图元素模块将会在未来版本移除)，可以是位图，可以是swf导出素材，甚至可以不是显示对象。具体交由项目注入的皮肤适配器解析。

        目标点概要(临时):

• Skin分离机制:用XML布局，用可视化工具编辑并生成皮肤代码，组件上只写逻辑，通过公共属性接口动态控制皮肤，监听事件。
• 开发可视化编辑器，支持用拖拽组件或导入面板的方式创建所见即所得的UI界面，并且通过Skin分离机制与纯AS项目无缝集成。
• 完整的自动布局机制：完全实现Flex的流式布局方式。在所有组件上应用,让制作好的UI通用性更强。
• 实现一套组件默认皮肤，为迅速搭建UI写测试逻辑的工作流提供支持,不用等待正式UI完成才开始，可以并行工作，逻辑完成后能方便地替换皮肤。
• 提供针对游戏的常用UI组件封装，如图文混排聊天组件，动态漂浮文字等。
• 对非框架显示对象的兼容：通过SkinnableElement类包装普通素材显示对象，也实现统一的自动布局。
• 全局的多语言翻译函数支持，tr(“key”)，在底层做注入的统一处理。提供多语言自动配置识别工具。
• 设计一套程序与Flash CSx美术UI人员协作的更加高效的工作流，类似Flash Catalyst的转换机制，面板自动导入。
• 原生的位图化UI支持，加速UI的渲染性能，UI组件在全局共享缓存位图数据并自动管理内存回收。
• 简洁清晰的全局注入机制，为皮肤，字体，单例，配置全局默认值。
  

        可视化编辑器     

        为了实现可视化操作，我们开发了可视化编辑工具，并自己实现了一个XML到AS文件的编译器。XML文件作为中间代码，保存发布AS文件到目标工程，与纯ActionScript项目无缝集成。可视化编辑器的工作量实际上才是最高的。我们目前已经开发了两个月，虽然界面很简陋，但终于有个可以测试的版本了。能自动导入swf，位图化并共享素材，转换滤镜信息，字体样式等，最关键的是能像Flash Catalyst一样选中素材转换成框架里对应组件皮肤，然后直接发布到目标工程里。这个编辑器起初只是想模拟Flash Builder的设计视图，开发到现在，更像是Flash Builder+Flash Catalyst了 。已经一边投入新游戏项目中测试，一边继续开发。

        起初发起这个项目的时候，就是打算将它开源的。但是可视化编辑器的工作量远远超出了我们的预计。最后决定暂时只开源FlexLite库源码部分，毕竟它参考了Flex源码，虽然也是我们一行一行优化并重新实现的。可视化编辑器里完善还有段距离，我们会继续开发，等到经过一个完整游戏项目的测试使用后再说。现在的版本还不稳定，接下来可能还有很多调整，继续精简优化。另外，还要感谢下老板一直以来的支持我们全职开发，希望这个项目能跟进一步。

        FlexLite库检出地址(包含xml编译器源码)：
Google Code：  https://flexlite.googlecode.com/svn/trunk/flexlite               GitHub: https://github.com/flexlite

注：库编译需要Flex SDK4.6+AIR3.3支持，因为位图素材编解码器部分，提供了Jepg-xr格式编码器和异步位图解码功能支持。不过不用担心版本问题，有版本要求的类我们都是通过项目内注入的配置方式获取的，只要你的目标项目不注入这些类，就不会有版本需求。类似这样的配置问题还比较多，但现在我们的to-do-list已经排满了内容，没法抽出时间来写教程。另外，目前的版本是不稳定版本，接下来可能发生较大改动，所以目前仅供阅读，不建议直接投入使用。如果有幸能得到较多人关注，我们在有一个完善版本发布的时候，将会补充测试例子项目，和一些列使用教程。感谢您的关注！
[更新] 
首页：http://www.flexlite.org/
交流群：82796656(欢迎加入，探讨一切跟Flash相关的技术问题)
新浪微博：http://weibo.com/flexlite