AIR, 我已经对你彻底失望了.

看来不管我怎么努力 话题还是不可避免的被引到 flex上.
其实 flex在现阶段唯一可取的就是 在处理大数据量时带来的性能优势了.
而flex在开发时所表现出来的优点我觉得也无外乎以下几条:
1 有好的开发工具
2 as3 可以是强类型的 可以在开发期纠错
3 基于标签的UI编码方式 (这个说它是优点 主要是让熟悉html 和 jsptag的开发人员用起来更习惯)

而一但需求稍微复杂一点 扩展flex的控件 就是一件很头疼的事情.
大量的as避免不了.

当然 我说的这个缺点主要还是集中在 "Flex自带的组件不够多 组件的接口和事件不够丰富 扩展不够方便"
是的 最大的不足就在这里

组件化程度不高 我反复的强调过很多次这个问题. 而企业级开发中 这个问题是很重要的.

直接牵涉到快速开发 后期维护 系统一致性 等很多问题.

记得以前有个 第三方的flex扩展组件库 可惜后来死掉了
如果它能够很好的发展 作为flex一个有效的补充 也许flex的情况就会好很多.


关于flex组件化程度 你可以拿flex和extjs中 同样的组件做个对比 看看extjs的组件所提供的接口 事件 用户体验以及扩展方式.
对比一下就知道了 flex作为一个世界级大公司的 重要产品 它应该感到羞愧的.

关于Flex组件化我是看了其组件化源码的，对其生命周期是很了解，我不了解ExtJs的组件模型，所以我不敢说二者谁强谁弱，但是我以前用Delphi开发过组件，很明显组件化开发要比Dlephi强很多，简单很多。如果您对FLex组件生命周期也很了解的话，我相信你说的是客观的。对于ExtJS到底谁更适合企业应用的UI层开发，希望更多人进行讨论，有人用过Flex吃过亏，也有人用ExtJs吃过亏，大家多讨论，多ＰＫ，问题才能阐述清楚，感谢楼主提供了一个可以引起大家兴趣的帖子。

Flex 中的list，dataGrid，下拉列表框，tree 是比较常用的了，在呈现大量数据的时候，的确有一定性能上的优势，因为它的renderer是复用的。如果仅仅是简单的数据呈现，也没什么问题。但是实际应用中，renderer都是比较个性化的，当你精心构造好了一个renderer交给list呈现的时候，性能的问题就来了，创建要白屏一会，滚动的时候开始变卡。不要告诉我你应该优化你的renderder让它变的尽量简单，事实是flex组件创建速度太慢，应该优化的是flex组件。后来还是自己实现了，性能和功能还算比较理想。Flex组件性能的提升空间还是很大的，不过其生命周期过于复杂，整个就是奔着一重量级方向去的，期待其轻量化，也是不太可能了。

个人感觉Flex组件在应对一些个性化界面方面有些心不从心，如果去扩展现有组件，性能上绕不过去，整个框架限制的比较死，可扩展的余地也不是很大。

列举一下Flex使用中感觉不顺的地方，可能有些地方已经有比较好的解决办法了，罗列一下，仅供参考。

1 mxml编译速度过慢，在同时编写多个模块的时，等待编译的时间比较折磨人。
2 css 选择器实在太弱，给开发增加了不必要的代码量，此情况在Flex4中已有所改善
3 tree组件没有横向滚动条，是有意为之，还是有待完善
4 dataGrid横向滚动会卡
5 label组件的文本截取算法效率太低，整个把文本全扫描了一遍，应该换为更好一点的二分查找算法
6 tooltip的消失延迟时间是全局的，不能单独定制
7 richeditor整个就是封装死的，你想扩展都无从下手，当然可以通过一些hack手段可以做到
8 基于list的组件如dataGrid,tree等在可变行高情况下，滚动条的算位不准
9 UICompoent的生命周期过于复杂，导致组件创建速度偏慢，创建50个checkbox，就能开始感到短暂的白屏，后来学乖了，在有大量界面组件的时候，不敢再用Flex组件的，改用flash的simplebutton，性能提升显著。
10 renderder不能写的太复杂，会有性问题，严重限制了创意的表达，后来改为自己实现组件
11 一些需要文本呈现的地方，如list,datagrid,tree,tooltip如果能直接支持html格式会更实用一些，虽然做一些扩展也能做到
12 对html格式支持的比较弱，在做html呈现的时候，不太理想。
13 repeater组件超难用

FLex组件生命周期理解透彻了可能某些问题会得以解决。如果在组件代码中使用setStyle方法，会导致性能奇慢。

做一些不是很个性化的数据展现类型的企业应用,flex开发比较快,也比较方便.
涉及到一些个性化以及类似图文展现的应用,就只能自行写as来开发组件,或者用一些hack的方式来处理.
UIComponent确实感觉冗余了点,动不动一个类就上万行的代码,让人吐血.
至少从代码模型上和ExtJs还差很多,Ext也有Ext的问题...

关于setStyle的问题，都建议尽量不要调用，会导致性能低下。

假设我写了一个renderer,里面有一个lable组件，我希望根据数值的大小显示不同的颜色，比如大于100显示红色，小于100显示蓝色，很自然的我会这么写

<mx:Label text="{data}" color="{data>100?0xff0000:0x0000ff}"/>

很遗憾这样是行不通的，首先样式是不支持值绑定的。好吧，hack一把让样式支持值绑定，然后你又会被告知setStyle会带来低下的性能问题。

我想这是一个再普通不过的需求了，解决这个问题会有好几种办法，要么写复杂的AS3代码，要么再冗余一个Label，但是不论哪一种都不如上面来的直接简单和自然。如果setStyle没有性能问题，如果样式支持值绑定，整个世界就变的清净了。话说回来了，这个世界又那会有十全十美的东西，要么您就期待Flex一点一点慢慢改进吧，要么您就去封装自己的组件库吧。

顺便一提，Flex默认的几个Renderder都是用As3写的，创建和布局逻辑代码不少，如果你想继承一下扩展一把，那是不行地，里面几个关键的变量和方法都是私有的。期望Flex以后在设计API的时候，能够抱着更加开放的态度，以利于大家扩展，才有可能形成一个成熟的组件库市场的氛围。

Flex的SDK封装得的确让人很恼火，官方的SDK就像大家说的“从性能、体积、灵活性和可扩展性这几方面都不理想”，想自己在Flex中实现一个可拖拽的组件，还没写逻辑，一继承UIComponent就是一两百k，让人郁闷。只希望adobe在Flash Builder上多下点功夫，真正让Flash Builder可以用起来。

原来您是这样理解Flex组件开发的，难怪！

vii779这么理解有什么不妥吗? 你是怎么看的?


BTW :
vii779 ltian znjq  等几位朋友的跟帖讨论 要比主贴更精彩
建议关注flex 开发的同学看一下.
(虽然我主贴是关于 AIR的 但是我不介意在这里讨论 flex的问题 呵呵
因为关于flex 其实我也有很多话想说)

我关于AIR的具体的分析贴 打算在AIR 2.0正式推出 并且我使用过之后再写.
但是不管怎样 如后面一位朋友所言 我对AIR更多的是一种恨铁不成钢的感觉 而没有绝对的恶意.

不妥之处欢迎指正，期待您的高见。