About

<#TEMPLATE_INCLUDE_NINEPAGE_ABOUTME#>
  • Mar

    8

    开发者们在开发桌面应用时往往不需要考虑性能问题,可以选择 Flex 组件框架中 MX 或 Spark 包中的控件,因为它们功能强大(只要业务逻辑不是死循环或,基本上就不会有什么大问题)。但由于移动设备性能较低,所以开发者们在开发 Adobe AIR 应用时总是会选择更为轻量级的 UI 框架。

    比如基于 Starling 的 Feathers UI 组件,但 Starling 是基于 Stage3D 的,所以 Feathers 也是基于 Stage3D 的,这意味着如果项目中本身有传统显示对象,那么需要同时刷新 Stage3D 层和传统显示对象层,并却需要保持通信与渲染的同步,最终这有可能导致项目的性能并不能很好的发挥,甚至还可能导致更差的效果,所以在使用 Feathers 开发移动项目时往往不得不避开传统显示对象的使用。

    再比如选择 Flex Spark 移动主题(注意:Spark 主题和 Spark 移动主题并不是完全一样的,Spark 移动主题是针对移动设备优化后的主题,类库并不完全相同,并且每个类的功能或多或少的也并不相同),这是个不错的选择(我喜欢),它能支持所有传统显示对象,包括复杂功能的 Flex 显示控件(但并不推荐使用太过复杂的控件或较占资源的控件)。

    另一种选择是 MadComponents,这套 UI 组件其实并不仅限于 Adobe  AIR 移动开发,包括纯 AS 的 WEB 应用也可以,它采用 XML 布局,所以可以像在 Flex 中使用 MXML 布局那样进行快速的开发。

    Spark 移动主题与 MadComponents 比较: 

    1、MadComponents 在 AS 中采用 XML 布局,并不能真正的可视化的布局控件,对于已经习惯 MXML 布局的开发者,可以忽略这一点。

    2、MadComponents 相比于 Spark 移动主题更加轻量级,轻量级意味着它会相对少一些功能,开发的时候成本可能会更高。

    a、比如 MadComponents 没有像 Spark 移动主题那样拥有持久化机制;

    b、比如 MadComponents 采用的是 AS 语法,所以设置样式时没有像 Spark 移动主题使用 CSS 语法那么方便。

    c、比如当项目本身涉及大量的位图资源的时,MadComponents 无法像 Flex 中 Spark 移动主题那样使用强大的 @media 规则。

    d、比如当界面设计中矢量元素较多的情况下,Adobe 设计类软件生成的 FXG 资源文件与 Flex 的软件接力强大功能也体现出来了。

    e、MadComponents 并没有中文支持,甚至在 Google 上的 swc 文件往往也不是最新的,它的更新地址在 Facebook,国内用户你懂的(当然对于技术人员而言,这一点也可以忽略)。

    其它无法一一例举,作为快速和轻量级(相对于 Spark 移动主题)UI 组件开发,MadComponents 已经非常棒了。

    以下为 MadComponents 相关链接

    https://code.google.com/p/mad-components/

    https://www.facebook.com/groups/madcomponents/