最近在Flex有讲很多向反转控制框架前进的趋势。在这个大趋势里面，我们可以察觉到有一个高水准的趋势是向模块性框架发展。这样的一条架构的道路可以带来很多好处，特别是在用大量团队和正式发行流程进行企业级设置时。此帖解释了在Flex上下文中模块性的意思，讨论了执行模块的带来的一些好处和可能的东西。

What is Modularity什么是模块性?

模块性是比Flex Module和ModuleLoader元件更具综合性的东西。这些都只是模块性的一种表现形式之一，但是原则上是更宽阔的：模块性是把应用分割成更小的单元以用来单独开发和配置。在Flex的内容中，这些单元可能是模块，子应用或者其他任何类型的包装内容。一个木块性的应用通常有如下的一个结构。

Figure 1 — 一个模块性应用的结构

在上图，应用是由一个简单的外围组成，这个外围用来加载三个模块： Dashboard, Contacts 和 Messages。 这些模块代表应用的不同功能区域。他们执行细节各自独立。应用外围负责加载和规划模块，还有为他们之间提供通讯。这个可以是一个全局模型，一个接口的注册点，或者是像图一一样，是信息传输载体。

模块化的好处有哪些呢？

模块化可以给应用的终端用户带来好处，同样也能给开发和发布团队带来好处。一下是它的一些好处：
•        模块可以单独进行开发，测试和搭建。
•        由于一个模块的改变并不要求其他模块或者外围应用一起改变或者重新编译，所以构建时间缩短了。
•        模块可以在需要时再调用，所以最初应用下载会很小。
•        如果用户从未使用一个模块的某功能，那么这个模块将无需加载。
•        模块将可以单独的配置到产品里面，代替之前配置整个应用。
•        可以根据用户的权限的不同加载不同的模块。
•        由于模块本能上的结合，所以模块比一个继承系统更好理解和维护。
•        模块之间的交互可以被分成简单的API，随着应用的增加会渐渐衰退。
在构建和配置方面的效率的好处被证明为是最重要的。小型开发团队的开发者们可以各自开发模块。模块之间可以指定统一的通讯协议，所以可以无需改变和改进直接运行。

模块化的框架供应

一些框架帮助建立模块应用。PureMVC 大概是最早做这个的吧，它使用框架的多核版，它的Pipes对于模块间的控制的信息很有用。Parsley应用框架同时也是设计为支持模块应用的，在这个里面模块将有它自己的反转控制内容，这个内容是从外围应用继承对象定义。Parsley 包括一个信息框架，这个信息框架可以用来松耦合模块间的通讯。轻量级的 Swiz 框架近期也是期望改善它在对模块开发方面的支持。
另外相对于这这些个已建立的框架，有一些脱离的框架特意专注于模块性。Potomac 和 Adobe Gravity 是 OSGi授意下的两个新的框架, OSGI是Java的动态模块系统。这两个新的框架都是以在运行时加载包（即，模块）和在它们之间通讯时使用服务借口而提供基础架构为目标的。Adobe Gravity 作为一个 Adobe 内部项目而保留，当Potomac公开可用的时候，他们有计划将来会开源发行，然后以Flex Builder的插件的形式包含开发工具。

Cairngorm 3 和模块化

[url="http://opensource.adobe.com/wiki/display/cairngorm/Cairngorm+3]Cairngorm 3[/url] 参考架构（现在在草稿阶段）的一个关键信息是将应用分割成独有的功能区域，这样可以独立开发。换句话说，一个模块化的架构的每个功能性区域是一个模块。Cairngorm 的指导文件建议使用一个简单的API（有可能是一系列的接口，事件和数据转换对象组成）进行模块之间的通讯。这个方法最小化一个应用的独有功能区域之间的依赖关系。它发扬了Robert Martin 在稳定性方针中的 “良好独立性“的提议。更多细节请参考Creating Functional Areas 草稿.

企业级解决方案: Adobe LiveCycle Mosaic ES2
LiveCycle Mosaic ES2 离没框性框架还很远，但是模块性在它的开发中师非常重要的一个组成部分。使用杂合的方式建立一个应用，合并不同的功能块为人性化视窗是一个客户端和服务端技术，这项技术专注于不同用户执行的不同事件。在服务端，当LiveCycle DataServices可用于整合不同数据源的时候，可以存储和共享可复用的应用套件。在客户端，应用是用不同的物件组装而成，可以用存在的Flex和HTML应用里面的片段开发。一个自定义的外围应用加载和规划这些物件，框架为他们之间的通讯提供一个公共的歇息信息API。关于更多的Adobe 企业级模块性解决方案，请参考 LiveCycle Mosaic ES2 产品页。

总结
由于我们想在Flex和AIR里面建立更大和更好的应用，为保证有效开发，可量测性和可维护性，模块化的话题变得越来越重要了。分离一个大的应用的各个部分至关重要，这样他们可以单独的开发，测试和部署。 Flex SDK 可以用Modules和Sub-Applications提供一些简单的模块化方法，然后一些框架建立在这些之上一提供更多的功能。此外， Adobe 现在LiveCycle Mosaic ES2里面已经发行了企业级解决方案，LiveCycle Mosaic ES2利用模块方法为快速开发和部署RIA到浏览器和桌面提供了底层构造。

本文来自: Flex 应用里面的模块性

WEB UI Treasure Chest v 1.0

Chest contains:

1. Cursors
2. Checkboxes
3. Radio Buttons
4. Buttons
5. Forms
6. Ribbons
7. Page Corners
8. Calendar (I hate to make it every f****ng time)
9. Scrollbars
10. Signs
11. Tooltips bubbles
12. Small elements like bullets, arrows, paypal logo, visa etc

本文来自: 一套WEB UI 的psd图标

令人期待的Adobe Flash Player 10.1已经发布了，AnandTech紧锣密鼓的对其进行了评测。对于广大用户来说，我们并不关心这个版本更新了什么功能，而是其在播放Flash时采用了GPU加速功能。现在就看一下令人兴奋的结果吧。
一、ASRock ION + Atom 330 (1.6G双核) + Vista x64 + GeForce 9300/9400M 环境下：

图表的左侧一列是采用的视频，分别是Hulu和YouTube支持的各种视频格式，包括360p、480p以及720p的视频，右侧两列分列了Flash的两种版本10.0.32.18以及10.1.51.45以窗口形式播放前面对应的视频时CPU的占用情况。

这张图表是全屏时对应的CPU占用情况。

二、AMD 785G系统（集成Radeon HD 3200) AMD Sempron LE-1150 （2GHz 单核 基于K8的CPU 二级缓存512k）环境下：

说明：上面第二个表的CPU采用的是Athlon 64×2 QL-64 双核2G的CPU，其他配置不变。第三个表代表丢帧率（越小越好），两种CPU下结果类似，第四个表中的数据采集时显卡换为Radeon HD 5850、CPU换为 Athlon II X2 240。

三、HP Mini 331 （Nvidia ION LE）环境下：

四、Gateway NV58 （Intel GMA 4500 MHD) 环境下：

五、核心测试环境为：双路16线程的3GHz Nehalem处理器的Mac Pro工作站，显卡为EVGA Geforce GTX 285，30′显示器，分辨率为2560×1600。

小提示：因为是多核系统所以CPU占用超过100%

六、补充知识：

在Adobe发布的三种平台（Windows/Linux/Mac）的Flash 10.1中，只有Windows版本采用了针对使用DXVA的Flash视频文件的H.264加速。

这就意味着，你可能需要一款支持DXVA或者DXVA2的显卡来实现这种加速。Nvidia声称其G80系列以后的产品都支持此功能。最新的基于Nvidia的ION芯片组的平台是今天的测试基础。这里列一下ATi系列支持此功能的芯片：

Ati Radeon HD 4000, HD 5700, HD 5800系列

Ati移动Radeon HD 4000系列或更高

Ati Radeon HD 3000 集成显卡或更高

Ati FirePro V3750, V5700, V7750, V8700 V8750或者以后的版本

另外Intel的G45系列理论上可以支持显卡加速。但是在测试时使用的笔记本平台上并没有太好的表现。

翻译不妥的地方多提意见。

来源：互联网周末

本文来自: Flash Player 10.1 beta GPU 加速能力测试

Flashstreamworks主要关注的是视频趋势，但是最近关注了一些最新开发出来的Flash 3D的空间。下面是收集的一些站点。

Bandit3 Most Wanted
令人印象深刻的站点，采用的是Away3D引擎。在这个复杂的世界里，可以环游街道，出入建筑，探索公司更多的东西。

Portfolio Nick Joore
Nick Joore的三维文件夹是必看无疑的。当驾驶着飞船巡游彩色世界，那种感觉很像是在玩wii游戏机，而实际这只是Papervision 3D渲染出来的效果。

Papervision 3D showcase
如果你在寻找有趣的Papervision 3D例子，这里绝对是最合适的。这个站点包含了大量的例子，可以预览、描述和排名。

Alternativa3D V7 demo
Alternativa3D是一个针对flash player 10优化的第一人称射击演示。v7演示包含了很多的广告，虽然样子一般，但是执行效率确实令人惊叹。

本文来自: 令人拍案叫绝的flash 3D站点

苹果iPhone不支持Flash已经引起了很多用户包括Adobe的不满,不久前Adobe表示了自己的不满,在iPhone用户试图访问Flash内容时,Adobe提示用户由于苹果方面的原因他们无法访问Flash,今天Adobe平台业务部总经理及副总裁大卫·瓦德瓦纳在接受采访时再次谈到了 Flash和iPhone的关系.

瓦德瓦纳表示:“希望苹果向Adobe打开他们的API,因为广大用户都希望在iPhone上面体验Flash内容.未来,互联网将向两大趋势发展,一个是富媒体会持续增加,另外就是支持丰富多媒体应用的移动设备持续增加.”

瓦德瓦纳指出:“Adobe将就这两大发展趋势持续在游戏、在线视频、富媒体广告和富媒体应用四大领域展开工作.事实上,我们在这些领域投入了10年.”如今,大约70%的线上游戏和几乎100%的富媒体广告是Flash制作的.

关于Adobe为何与苹果没有很好的合作的问题,瓦德瓦纳解释说:“整体来说,Adobe和苹果公司有很好的合作,多年来,我们的 Photoshop等产品与Mac很好的配合,并且创造了设计业的奇迹,但是在iPhone上面的合作尚未全面展开.现在有300万用户利用iPhone 尝试去下载浏览Flash内容,我们希望和苹果有很好的合作.”

去年Adobe推出了一个Open Screen Project(简称为OSP)联盟,目前全球较大的手机厂商基本都和Adobe建立了合作关系,比如诺基亚、摩托罗拉、三星、LG、RIM、Palm、谷歌、微软等,唯独缺少了苹果.

本文来自: Adobe：希望苹果iPhone可以接受Flash

前SNS相当热门，因此也有想做SNS游戏的想法，毕竟从校内网和及开心网的运营来看，第三方的SNS游戏制作公司盈利还是相当大的。可以说 2009年是SNS游戏是兴起的一年，而10年则会是百花齐放的一年，这是一块大蛋糕，虽然有人劝我说这类游戏已经泛滥，但我觉得蛋糕大也说明市场大。下 面说说做一个SNS游戏所需要做的一些事情。
1、Flash素材库的建立
这个需要美工来做，首先做成一个包括许多游戏中要用的的元件的库文件，元件的建立可以用别人的素材，也可以自己手绘，这个要看美工的能力，最后编译成SWF文件来供AS程序员来调用。
2、游戏主程序的建立。最好用FLEX来完成，因为flex builder不管是对项目的控制还是面向对象的管理都比用Flash 来做好很多。项目要建成ActionScript，因为你既然是做游戏就不会用到FLEX的控件，因为所有的游戏里面的控件都不是普通程序里面的控钮或是 标签控件。 Gamelook.com.cn
3、后台WEB语言的选择。其实一开始想使用Ruby On Railsr，但是最终还是放弃了。后来又考察过JSP，因为JAVA是一门支持多线程的语言，不像ROR或是PHP之类的单线程语言，而且JSP又可以 用线程池，在WEB服务器和数据库的并发性能上肯定会好些。但是JAVA的线程同步也会随着应用的复杂出现一些陌名其妙的事情，这也是我最终决定放弃 JSP的原因，再后来我看了一篇JSP和PHP关于数据库性能评测的文章后我就完全抛弃了JSP，因为JSP和PHP分别用普通方式和连接池(jsp)和 长连接(php)的的方式评测结果来看，几乎是一样，虽然连接池或是长连接的效率相比普通方式的数据库评测提高了将进三倍，但却未必适合像SNS游戏这样 有些巨大同时上线用户的程序。传统方式的数据库操作是当需要从数据库取数据的时候连接数据库，取到数据后，则关闭数据库连接，这样的方式虽然在频繁的连接 与断开中损失了一些效率，但是从数据库的负载来看却比较好的。试想一下，一同数据库服务器同时有1万人连接，并且进行着select、update、 insert等操作的时候，会是什么样的场景。因为JSP看起来是真的适合做B/s的软件，而不应该是网站，虽然性能优异，但是决不那么容易驾驭，或许牛 人可以写出多线程支持完美，且高负载的WEB后台程序，但是对于SNS游戏这种短平快的项目，显然是不适合的。这样看起来PHP是最合适不过的选择了，简 洁的语言、灵活的编程方式，以及丰富的类库，以及全球300万PHP程序员的资源共享，决定了这门语言的生命力。我这里不推荐用PHP的框架，因为毕竟不 是用PHP做网站，我们要做的只是一个能与as程序交互的WEB后台程序，用框架必定也会损失一些性能，而且最主要的还是下面要说到的通讯协议库 AMFPHP的存在。
4、说到通讯协议最开始的想法是采用JSON，通过PHP的JSON库将数据库中的数据通过JSON的方式返回给AS程序，然后解析处理，因为比 XML格式来说JSON的包会小一点，但是从本质上来说XML和JSON都是文本类型的数据包，效率来说肯定比不上使用二进制的AMF格式，而PHP有大 名鼎鼎的AMFPHP包，可以提供使AS程序与PHP进行通讯，当然AMF3也有自身的缺点，虽然是二进制的数据包，但是本身有过多的描述信息，且并未进 行过压缩，据我观察描述信息占到500多个字节左右，哪怕是一个只有一个英文字母的数据包，因此对AMF3进行压缩是相当必要的，虽然当数据返回量大过 5K时，可以基本忽略500多个字节的冗余信息，但是对于SNS游戏来说，往往有时用户服务器上取到的数据就是很短小的数据包，比如说用户点击的某一块地 上的种物成熟剩余时间（这里以开主农场游戏为背景），这样的一个包，如果用纯JSON包来构建，相信不会超过100个字节，但是返回的AMF3包足足会有 600多个字节，于是当游戏用户达到一定的数量级别，加之此类操作的频繁程度，相应这其中的总体效率会降低很多，因此在服务器端的压缩数据应该说是必须 的。当然我们可以用ZLIB库来进行压缩，但是压缩也有一个隐患，就是要消耗服务器的CPU占用率，当这种压缩的操作很频繁的时候服务器的CPU势必会保 持在一个比较高的百分比上，因此在选择压缩比例的时候要总体来权衡。 游戏大观Gamelook.com.cn
5、一个团队要将这些技术整合在一起，并加以实际应用做成SNS游戏可不是一件容易的事情，程序开发完成后，还要进行游戏本身的BUG测试，之后就 是压力测试，再下面就是服务器的构建以及宽带的选择，产品上线前要做一一的宣传工作，上线以后还要做推广，以及维护、更新工作。
总结：虽然说SNS游戏做起来门槛不高，但是要真正做好一个SNS的应用我觉得并不是一件很简单的事情，首先游戏的创意其实决定了游戏本身的盈利， 如果没有好的创意，做出来的游戏没有什么可玩性，用户既使在你一定的推广下会来注册你的游戏，但是你绝对不会拥有一定数量的活跃用户。然后就是技术支持， 你的团队中要有精通flash的美工人员（如果只是会用flash而不具备鼠绘能力的美工，那么你的游戏将不会带给用户多少的冲击视觉），还要有能积极响 应并处理AS的高级程序员（如果程序员经验不很丰富，无法及时去改正程序中的BUG以及无法满足用户的一些改进BUG的要求，而导致论坛里骂声一片）。再 者就是要有一个WEB语言的高手（新手是无法驾驭好后台通讯协议的）以及一个可以灵活使用SQL命令的数据库工程师，通常PHP程序员都是会直接采用 SQL命令来操作数据库的，我觉得这是一个好习惯，我不太喜欢框架中的封装好的数据库类，我觉得这是高级程序员做给低级程序员使用的一种在降低性能提高通 用性的情况下产物。因为一个胸怀大志的程序员，应该很少用人家的框架，而应该在自己的项目中总结一些重构以及复用的方法。当然还要有一个服务器配置、运营 的高手，因为做SNS游戏肯定是需要自己有服务器，虚拟主机也好，VPS也罢，都是支撑不起如果大的访问量的，服务器的优化、集群以及分布管理都是需要认 真考虑的东西，这关系到整个应用的最终命运。最后还要有一个CTO，会运筹为握的人，把握SNS的方向才能真的走向成功，希望中国的SNS第三方开发商们 能怀着一颗热切的心投入SNS应用的开发，却迎接2010这个山雨欲来风满楼的年度！

本文来自: sns游戏开发