再度分(tu)析(cao)Egret这个年轻人
写在最前
笔者用Egret来开发游戏已经有2年多之久了，从它出现到如今的3.2.x版本，经历了很多很多，也做了很多类型的游戏了，关键是踩了很多很多坑。
很多网友问我Egret有哪些优劣，我也只是说了一点点，所以现在来总结说说Egret的适用范围。
Egret算是游戏引擎吗？
如果你熟悉Flash + AS3，那你会怎么定义AS3呢，是引擎还是语言框架？从Egret诞生到现在，它其实只是实现了一套类似Flash + AS3的语言框架和开发流，当初为什么选用TypeScript作为开发语言，就是为了亲AS3程序员而已。其实用JavaScript完全可以的，只是要自己去实现继承和其他一些语法糖(TS也没啥语法糖)，选用TS应该是白鹭公司比较机智的做法。Egret在Flash部分则是模仿了个遍，从显示列表到事件分派机制都和Flash很像，虽然AS3是开源的，而Flash则没有开源，但是从Adobe离职的Egret创始人应该是对Flash甚是了解了。
游戏引擎需要具备些什么功能呢？反观Egret拥有哪些功能呢？
Egret开发流
打开Egret官网，你就会看到很多很多形形色色的软件，八仙过海各显神通。然而，在笔者的开发过程中看出，Egret Wing是最实用的，其次是Texture Merger，再次是Egret Inspector，其他就基本没怎么用了(基本都尝试过，但都觉得缺了点什么)。
总之，Egret的开发流确实是朝着游戏开发去的，确实为游戏开发提升不少效率。但是，这些软件在用户体验上做得还是不够的，想必很多开发者也吐槽过这和那了，好在官方人员会及时改进体验和修复Bugs，不然你在开发过程中必定无语。
就笔者而言，在整个开发过程中，就是Egret Wing和代码编辑器(Intellij Idea)的配合，结合Egret的eui(前身egret gui)引擎，分离了皮肤和逻辑代码，基本可以算是一套完整的开发流了，当然某些游戏还需要DragonBones还有Egret Feather的配合，但是甚少。
Egret没有提供场景概念，这让很多不是AS3的开发者不大适应，因为Egret只是提供了最基本的显示对象(egret.DisplayObject还有容器类)还有一些基本的功能对象，游戏场景和特效都需要自己去实现。
要用Egret开发中型的游戏，你需要很多第三方类库的配合，然而egret也没有搞出一套类似NPM的包管理工具(曾经想搞，但是越来越没有动力了)，如果能搞起来，那Egret社区还会怕没人气？
Egret适合做Native游戏吗？
笔者之前写过一篇博文，http://www.cnblogs.com/rockyf/p/limitations-of-egret.html/，关于Egret的局限的文章，里面指出了Egret在底层，抽象出了一套上下文，然后Native和Web各自去实现这套上下文，看似没有毛病，但是思考到深入你就会发现这对Native来说很不公平。
文中也明确指出了这种做法的问题，虽然在Egret拥有了更高的灵活性，但是使得Native被拖累了。这要说到Native了，就Egret的Native部分，实则，只是实现了一套拥有HTML5能力的“浏览器”而已，因为它并不是真正的浏览器，所以在性能上略微比Web高，但是拿全Native code编译的游戏来比较可以明显看出Egret开发的游戏略显卡顿。如果你发现Egret打包的app游戏不卡，那请用动态的大面积的动画来做demo比较，因为Egret的“不卡”是建立在自动脏矩形的基础上的，Egret的自动脏矩形在静态显示对象虽然效果显著，但是在动态显示对象来说，那就坑爹了，这就是为什么明明一个列表里项目很多帧率还是很高，而一拨动列表帧率立马就降了很多的原因。
最近看了cocos js的做法，他们实现了一套js binding，所有显示对象都分类native obj和script obj两部分，然后绑定，这样使得script更加轻量，主要的工作交给了native code去处理的，运行效率明显提升。
笔者在开发过程还碰到过这么一个问题，就是在iOS上，EgretRuntime只能被添加到UIViewController的view的顶层，因为暴露给开发者的只有一个initWithViewController，直接不管你要怎么管理整个app的视图就addSubView进去了，这点对于想用native code多处理点逻辑的开发者来说，这简直不能接受，已经吐槽，官方并不接受。
笔者最近又遇到一个问题，也是在iOS上的native打包，Egret Native的iOS版本里修改了Apple jsc，只为增加三个方法进去，使得它不能和原版的Apple jsc并存，最终导致EgretRuntime不能和React Native共存，最终导致笔者在该放弃Egret还是放弃RN上难以抉择。
从开发工具看
Egret Wing的出现，是Egret的一次重大变革，因为可以可视化编辑UI了，然而Egret Wing在后来叛变了，它觉得它只是做一款可视化编辑器太屈才了，于是又了代码编辑能力。当然，这只是笔者的拟人修辞手法而已，其实是一些开发者嚷嚷着要Wing增加一个代码编辑的功能。
笔者是反对的，因为笔者在用过一次Wing编辑代码后，就放弃了，完全不能跟成熟的代码编辑器比。
当时站在反对方的笔者已经意识到了Egret这次可能要改变战略路线了，要搞IDE了，笔者的疑虑是Wing在可视化编辑上是否还能照常迭代，因为工作重心变为了代码编辑器，不免使得Wing在可视化编辑上失宠。
目前Wing已经改了内核，使用了vsCode二次开发，然而在可视化编辑上还是有不少Bug，所以笔者还是坚定地用Egret Wing2.5.x配合Intellij Idea来开发。
在Lakeshore刚出来的时候，笔者就把玩了一次，发现这的确是一个不错的工具，不用写代码即可完成开发，和官网说的一模一样，笔者的一个朋友(一位策划)立马咨询了笔者，笔者只是淡淡地说，拿去玩吧！
题外：看到Lakeshore，笔者直接联想到的就是wow3的map editor了，暴雪十年磨一剑才把wow3连同编辑器创造出来，笔者这辈子都无法驾驭得了这把宝剑啊！
看看其他引擎
笔者比较宅，用了Egret后就没怎么去接触其他游戏引擎了，直到看到了LayaAir的发布。LayaAir发布的前后，Egret突然把WebGL版本给实现了，这个众多开发者从Egret诞生至今一直在求的版本。想必是业界同行给予的压力吧，不然还能一直拖着，毕竟每次Egret引擎版本更新日志里最后的尚未实现里都会加上一行：WebGL版本。LayaAir这个东西其实比Egret还是Flash，整一个都是Flash的翻版，毕竟人家是从Flash转HTML5的工具出身的，笔者认为Flash模仿上LayaAir更胜一筹。
再看Cocos-js，笔者知道很多开发者对它都是骂声一片，因为它前期太不稳定了，各种bug各种坑，还认识一个大牛就是从cocos-js转到Egret来的。笔者其实在13年就关注cocos-js了，那时候对移动游戏前端还是不怎么了解，只知道它只是一个HTML5的实现而已，哪知道现在它整合了所有平台后，开发一款游戏是那么轻松。Egret模仿着它，但是还是被它甩了，为什么？cocos作为业界知名的游戏引擎，母体是用c++缩写，在native code的实现上，只需要实现js binding或者lua binding，就能实现高效的脚本引擎驱动的游戏引擎了。而Egret从诞生起就是一个HTML5游戏引擎，而其native的实现只是高度抽象的上下文的实现而已，怎能匹敌cocos！C++程序员是很贵的！(言外之意呢。。。)
cocos上个月发布的cocos creator更是把Egret吓了一跳，如此类似Unity 3D的开发环境，如此快速的开发流，如此多的平台封装，从头到脚都开源，连native code都是开源的。Egret开始方了！
其实如果是纯HTML5的层面，各大引擎都能将运行效率做到极致，只是看哪家的开发流更快速更好用了！
最近接触了一个过来的库，叫paperjs，这个库了得啊，将矢量绘制发挥到了一个新的高度，它的实现比较有趣，其思路有点模仿Photoshop，所有对象都是有Path即路劲构成，自由度特别高，做图表还好，做游戏的话笔者还不能很好驾驭啦！
官方对引擎的包装效果
在这点上，Egret官方的运营团队做得是不错的，他牢牢地抓住了《神经猫》，并一跃而起，突然成为了新星，然后在各大社交开始宣传。然而笔者早已看穿了一切。
笔者的一个朋友总是会突然问我Egret现在占有率有多少了？好多次了，然而他却是一个cocos lua开发者，在经历很多cocos lua的版本迭代后，他貌似快受不了了，经常改动c++代码，使得项目在维护成本上增加了不少（这也是native code占有率增加的坏处之一）。其实这位朋友他是想转Unity 3D的，但是Egret在他看来是在太火，想先看看Egret，Egret赢了。
其实业界各大同行的营销策略其实都差不多，在社交平台上都有表现，而且还各有着重表现的一面。只要有一款相对成功的产品出来，官方必会大力宣传，并着重申明Power by ....。
Egret Runtime
这个名词应该是Egret广告里比较多的一个词了，因为它能大大提升Egret产品在Android手机上的运行效率，不信可以看官网上的截图，于是一款原生暖手宝就诞生了。
在Runtime还没有出来的时候，还只有Native打包这个东西，后来不知道他们搞了这Runtime，还说Native只是Runtime的一个分支，但是在笔者看来，Runtime是Native的分支才对，明显Native更加基础。
记得业界有一个传闻说egret和cocosjs达成了一个协议，公用一个Runtime，这样一来，cocosjs在web上的运行效率也能提高不少。
edit 2017/03/03
笔者之前一直没接入过Runtime这个东西，如今知道真相的我眼泪掉下来。
相信众多Egret开发者对于Runtime的理解都是这样的吧：只要我的游戏是用Egret开发并发布的到某个URL上，用集成了Runtime的浏览器打开了这个游戏的URL地址，这个游戏就会流畅地跑起来。如果是用普通浏览器打开了这个URL地址，那还是会很卡。
时至今日，笔者还以为白鹭团队是把WebView重写了一写，通过OpenGL来渲染。果然，它确实使用OpenGL来渲染，但是它并不是一个WebView，而只是Native的形式，相当于只是Native的一个动态加载而已。
它实则是去白鹭官方更新的Runtime库，再去下载publish --runtime native出来的游戏包。
看到这里，你应该就懂它的实现方式了吧。
坑，果然是我太年轻。想起三年前Runtime出来的时候，那是据说微信内嵌浏览器支持了X5浏览器内核，就有Runtime支持了，游戏就会流畅地跑起来了。
今日看来，这都是我臆想出来的。。。
最后说两句
在笔者两年多的开发经历来看，Egret真的在web平台上的效率确实还行，所以，如果贵公司只是想用Egret来做轻度的只有web端发布的游戏的话，用Egret确实是一个明智的选择。
但是，言外之意就是说，如果除了web端还有native app端的发布的话，那真的不建议用Egret，谁用谁知道，笔者已经进了不知道多少个坑了，基本上每个版本native support一编译，就能把笔者吓一跳，wtf，这特么什么鬼，然后提交给了Egret官方，改了bug后就发一个hotfix版本给我，这也只有那几个官方跟我衔接的人才知道吧！
不只是坑多，还有就是js code相对于native code占比太高而导致运行效率太低的问题才是Egret不适合做Native app的最大的遗憾，如果Egret 的native support也支持js-binding那该有多好啊，如果Egret的native support也能开源，也该有多好多好啊！
可惜了！
笔者已经在转Unity的路上了，要搭伙的一起啊！！！
