手游基本框架的介绍

    本文是看到《乐元素CTO凌聪访谈：游戏引擎技术选型之王道》这篇文章后，我觉得还是挺有道理的，其他也说出了一些手游的基本框架，特别是对资源更新模块的讲解，虽然很多只给了一个泛泛的概念，对于小白来说，还是挺有概念价值的。但是说到实际，概念归概念，到最后能写出代码才是王道，管你什么框架。部分内容如下，方便以后自己查看。

    

一：你们为什么喜欢上脚本化，并且选择了Lua语言？

      因为Cocos2d-x里面也支持挺多的脚本引擎，包括Lua、JavaScript还有C++。大家都知道C++有很多内存泄露、崩溃，很难解决。而且崩溃了也不会给你什么有用的Crash信息。

      我们做游戏运营，当用户的游戏Crash掉之后，我们要能拿到他的数据。为此我们自己打造了一整套Crash工具，从网上可以直接拿到Crash信息，分析用户的堆栈。用了脚本引擎，就可以降低Crash率。

为什么选择了Lua，而没有选择JavaScript？因为JS太复杂了，很难控制它。而整个的Lua就500K代码，你自己吃透它非常简单，没几行代码就读完了。同时我们也自己改了一些脚本，加了一些函数。对于JavaScript语言来说，它的状态机太复杂了。支持匿名函数，又支持各种各样的Funtion，使得状态机异常复杂，它的解析器也很复杂。我想我们会用更简单的语言，那就是Lua。

     并且Lua和C贴的是最紧凑的，我们要写个接口非常简单。Lua也有许多插件，用Lua在Java、OC和C之间互相调用都非常简单。

但是Lua也不是没有问题，它也有多线程的额问题，线程安全这块你要自己解决。这块技术，Lua还是比较复杂的。但是Lua主要业务是逻辑，至于考虑到多线程的问题，我们会有个专门的引擎组去解决，这是一队技术最好的程序员。游戏的逻辑会写在机要线程里面，所以这方面关系不大。引擎组去做多线程的事儿，和我们用到的Lua特性，关系不大。

对于游戏的开发人员，最好不要去碰多线程的东西，多线程容易出错。这里的技术选型，主要考虑的：一个是性能，一个是控制力。用Lua和C的效果基本上差不多，能有80%的效率。这也要看应用的场景，如果你是密集型运算，那可能性能还要差一些，但是LuaJIT的加速已经很快了。在iOS上性能提升5~6倍，在Android上可以达到60倍。

二： 这个Cocos2d-x和Lua定下来之后，你们都做了哪些工作？ 

        我们自己做的东西还是挺多的，我们自己做了Lua的调试器，我们用的是一个开源的ZeroBrane，在这之上自己修改的。可以说这是全世界最快的Lua调试器，把我们的Lua调试器性能提高了120倍。支持symbols和文件的快速定位，支持Push to device，改善了智能提示。

    另外，我们做了一个资源管理器，可以做到增量更新、安全下载、安全加载、动态更新四个重要的功能。

比如在用户的本地apk里面，某些文件比较比较旧了，需要从网上下载一个文件，系统需要有一个缓存目录，去存放从远端下载的内容，然后再更新到本地apk目录里，这三个目录的同步，就是资源管理器要做的事情。

    现在的游戏包一般都很大，100~200MB的有很多，甚至有的超过1GB了。所以说要做增量更新。我们有大小包部分，一般你先留一个小包，也看不同的市场。比如说有些网络好的市场，我们小包就行了。有些网络差的市场，我们就用大包。未来游戏更新的时候，我们都可以用增量更新，不用重新下大包。

考虑中国很多用户用2G网络下载不方便，所以在中国市场，肯定要用大包，有WiFi网络的时候把整包下了就行。但是在日本市场，你完全可以用小包，十几MB的包，效果最好。十几MB的包一般来说，里面有基本的资源，让你能进去，有个首页。进去之后按场景下载，这个是按需下载。

     你进某个场景的时候，突然有个人冒出来，他骑了条龙，你边没有这个资源，你需要从远端下载完了之后，他才能够穿上去。这里面就有个问题，游戏希望这个人能出现，但是这个人出现的时候他没资源，怎么办？一般的做法是这个人先裸身，先别穿什么东西，就是一个简单的朴素装。后台从远程下完之后，再把它穿上去，这就叫做动态加载。

我们是参考git的设计去做资源管理器的，今后如果可能，资源管理器其实完全可以基于git去做，这样更方便静态资源的部署.

 

三、那么游戏每次启动的时候，需要做哪些版本校验呢？

      首先，我们的游戏内容，会有几个存储的地方。一个是apk/ipa中的存储，一个是CDN的存储；一个存储是存放更新文件的本地存储。配置在服务器上有个配置版本号。游戏启动后，会去调这个配置服务器找版本号。看配置版本号是不是跟我们本地的配置版本号一样。如果一样，你就不用去更新配置。如果不一样，就到静态服务器去拉他的配置。

     我们每次文件都是增量更新的，不会覆盖原来的，我们文件名都不一样。它会取这个配置，取完这个配置再跟本地的文件系统进行一个对比。因为我们本地文件系统，为了保证他的一致性，全部是MD5校验。

上面刚才说了，一个是apk里面的存储，一个是Web上的存储，一个是Cache里面的存储。资源管理器会管理各处的存放的数据。没有就直接去下载。

  

四、现在有许多SDK，统计的SDK、广告条的SDK、各大运营商的SDK等等。你们对SDK是如何管理的？现在我听说Cocos2D-x引擎内部，也在集成这个，你怎么看？

     触控对Plugin-x的实现确实花费了许多功夫，要在不同开发语言之间，做一个统一的SDK体系不容易，还要提供C++，Lua，Java，Javascript的API，有N种语言接口。从他来讲肯定是C语言先支持，然后再网上搞各种语言绑定是最靠谱的。可以想象工程量相当庞大。当然，这对于开发者来说是极大的好事，一次可以部署多个SDK。

但我们的情况比较特殊，我们现在很多的收入来自海外，我们经常集成的Facebook SDK，它三天两头变一次，一个版本一次变，所以对于这种特殊情况，我们就无法用plugin-x了，只用Lua和Java自己封会简单一些，容易应对这种频繁变化的情况。遇到SDK发生改动是很讨厌的事情，应为SDK是JAVA的SDK，它一变，我们就不能用增量更新了，只能更新整个包。

五、触控最近出了一个CocoStudio，你们是否用过了？感觉怎么样？

     我觉得Cocostudio想法挺好的，我也觉得Cocostudio他能够做完善的肯定很好。现在这个阶段，我们用过还是觉得，一些功能还可以继续完善。当然CocoStudio也有比较好的东西，我觉得是UI编辑器，它看起来挺酷的，它支持组件直接嵌套等功能。最好是后面能开放出来让我们游戏厂家自己灵活定制。

    我们现在有自己的UI编辑器，我们自己的UI编辑器基于Flash。因为我们很多都是Flash转的。反正就是Flash做完原件，把Flash的东西导出来，我们自己写个插件把它导出来，所有的美术都是用原来的机制，包括原件的动画，全都是这样，很容易导出来。我们自己也做过骨骼编辑器。

我们也比较关注CocoStudio的这个骨骼编辑器的和动画编辑器。我们现在使用的是一个叫Dragon Bones的骨骼编辑器，未来我们可能会用比较老牌的Bone。我觉得我们现在，还是爱用自己的轮子，毕竟对来说最熟悉嘛。

六、总结

    对于乐元素这样有600人的大公司来说，其技术实力太强大了。他们追求极致的可控性，追求极致优化的工作流，这样才能发挥出这么多员工的整体实力。笔者能感觉到，对于这样庞大的团队来说，Cocos2D-x是一个非常优秀的技术方案，跨平台与高性能兼具。但为了实现自己对技术和结果的掌控，乐元素自己做了相当多的工作，部署了Cocos2D-x + Lua + Wax/LuaJava + Tolua++，自己用ZeroBrane改了个高性能调试器，自己做了资源管理器，自己做了Crash跟踪系统。毕竟是大公司大团队，在Cocos2D-x的基础上，还是有许多想象力和可发挥空间的。

    同时，我们也能感觉到，触控在中小开发者方面，也给予了足够多的扶持。CocoStudio就是最好的例子。UI编辑器、场景编辑器、动画编辑器、策略编辑器。CocoStudio工具集弥补了之前Cocos2d-X的工具缺失或者不全的局面。虽然目前市面上已经出现基于Cocos2d-X的工具，有收费也有免费。但是像CocoStudio这种一整套的游戏开发工具集并没有。关键是整套的游戏开发工具集可以让游戏开发的流程更科学规范，开发成本更低。我们可以看到，CocoStudio对于许多大型开发团队，也有许多可以借鉴的地方。最重要是的是，它方便了中小开发者，快速的开发出优秀的跨平台游戏。