OpenFL引擎使用总结

我们使用OpenFl引擎开发了手机网游《超级足球》，已经在删档内测了，估计是国内第一款用OpenFL引擎做的手机网游了。本文就来总结下使用OpenFL引擎的心得。

一、OpenFL的特色

OpenFL是Open Flash Library的简写，从名字能看出它的目标是兼容Flash  API，实际也正是如此，具体来说有以下特色：

    1、它实现了Flash as3绝大部分的API（不包括Stage3D部分）；

    2、它跨平台性好，能编译出Flash、Android、iOS、Windows等不同平台的产品；

    3、编译出来的Android、iOS、Windows产品是原生C++语言，比Flash虚拟机有更高的性能；

    4、OpenFL是用haxe和C++编写的，haxe与as3语法非常接近，比as3更强大。

另外，OpenFL说它还支持HTML5、BlackBerry、FireFox OS和Tizen，但HTML5本身的性能有限，BlackBerry几个平台目前比例很低，我们基本无视了。

 

正是因为haxe类似as3、OpenFL实现了Flash绝大部分API，我们招聘的as3程序员看半天就能上手开始写代码，之前的经验得到复用。

而在Flash上积累的库代码也比较容易移植到haxe上来，在haxe官网上列出从Flash移植过来的库有：box2d、flambe、flixel、flashpunk等等。

我们花了5人日就把Flash as3上的骨骼动画库DragonBones移植到了haxe上，并修复了原版的一些bug，这些都离不开haxe和OpenFL。

 

二、我们的改进

虽然OpenFL的showcase列举了近100个游戏，但基本都是单机游戏，而且轻度小游戏居多，用来做复杂些的手机网游，还需要加强火力，我们对OpenFL引擎、相关库和工具做了一系列的改进。

2.1新增对压缩纹理的支持

Android平台在2.3版本后都支持ETC1压缩纹理，就像iOS都支持PVRTC压缩纹理一样。使用压缩纹理，图片的文件大小只有PNG的30%左右，内存占用一般只有PNG的20%不到，还省了PNG解码的CPU消耗，在iOS上通常都会使用压缩纹理，但OpenFL引擎在Android平台上未支持。

我们在OpenFL引擎的C++部分增加了对压缩纹理ETC1的支持，在《超级足球》中，场景切换一般都在0.5秒内完成，游戏中很少出现loading画面，体验更流畅。

2.2新增对图片缓存的支持

在引擎的C++部分增加了对图片缓存的支持，应用层加载同一图片时，会复用之前已加载的资源，减少了图片的重复读取和内存占用，让应用层无需关注图片缓存管理。

2.3优化空指针错误的处理方案

在Flash页游开发时期，空指针是最常见的错误，只不过Flash Player默认不崩溃，容错性处理了这类错误。

OpenFL对空指针错误的默认处理是崩溃，这个在实际应用时体验不好，我们像Flash那样处理，让空指针错误只是抛异常，并在应用层捕获输出日志，这样既让程序容错性更好，又能查出是哪里出问题，方便fixbug。

2.4对swf库的优化

我们还修复了haxe swf库的一些bug，使OpenFL能直接解析并播放swf文件，美术同学能复用Flash编辑工具和swf资源，减轻了团队学习成本和资源浪费。

 

2.5对UI编辑的改进

我们UI库主要使用的是stablexui，增加了帧动画、数字的BmpFont、Table、支持记录条数很多的ListView等控件；

实现了直接把PSD文件导出为stablexui文件的脚本和编辑器，极大减轻了从美术资源到UI界面比较琐碎的对坐标工作；

还实现了基于stablexui库的UI查看器；

以上的改进使得我们做UI功能比较轻松了。

2.6其他

haxe支持条件编译，能够用一套代码编译出不同平台的安装包，在多平台运营时，这个特性很重要。

我们还实现了自动生成配置文件、自动处理图片（缩小、拼图、压缩）、每日自动构建不同平台的安装包

 

三、OpenFL的风险

最大的风险是，OpenFL的稳定性还需进一步提升。从OpenFL版本更新记录来看，近一年的更新比较积极，但整体的稳定性和社区氛围还需要持续加强。目前我们使用OpenFL在个别Android手机上出现崩溃情况，这是相对严重的问题。

从2D游戏的技术选型来说，cocos2d-x比OpenFL更稳定些，如果团队熟悉C++，优先选择cocos2d-x。另一方面如果有大公司对OpenFL进行支持，相信会极大的促进Flash开发者迁移到OpenFL上，毕竟OpenFL不仅能做Flash，还能做Android、iOS应用。