经典游戏服务器端架构概述 (二)(转)

全服分线模型
一. 模型描述
由于多进程服务器模型的发展,游戏开发者们首先发现,由于游戏业务的特点,那些需要持久化的数据,一般都是玩家的存档,以及一些游戏本身需要用的,在运行期只读的数据。这对于存储进程的分布,提供了非常有利的条件。于是玩家数据可以存放于同一个集群中,可以不再和游戏服务器绑定在一起,因为登录的时候便可根据玩家的ID去存储集群中定位想要存取的存储进程。

[图-全区分线模型]
二. 存储的挑战
需求:扩容和容灾在全区分线模型下,游戏玩家可以随便选择任何一个服务器登录,自己的帐号数据都可以提取出来玩。这种显然比每个服务器重新“练”一个号要省事的多。而且这样也可以和朋友们约定去一个负载较低的服务器一起玩,而不用苦苦等待某一个特定的服务器变得空闲。然而,这些好处所需要付出的代价,是在存储层的分布式设计。这种设计有一个最需要解决的问题,就是游戏服务器系统的扩容和容灾。
从模型上说,扩容是加入新的服务器,容灾是减掉失效的服务器。这两个操作在无状态的服务器进程上操作,都只是更新一下连接配置表,然后重启一下即可。但是,由于游戏存在大量的状态,包括运行时内存中的状态,以及持久化的存储状态,这就让扩容和容灾需要更多的处理才能成功。
最普通的情况下,在扩容和容灾的时候,首先需要通知所有玩家下线,把内存中的状态数据写入持久化数据进程;然后根据需要的配置,把持久化数据重新“搬迁”到新的变化后的服务器上。——如果一个游戏有几千万用户,这样的数据搬迁将会耗时非常长,玩家也被迫等待很长的时间才能重新登录游戏。所以在这种模型下,对于数据存储的设计是最关键的地方。

分区分服的关系型数据库我们常常会使用MySQL这种关系型数据库来存放游戏数据。由于SQL能够表述非常复杂的数据操作,这对于游戏数据的一些后期处理有非常好的支持:如客服需要发奖励,需要撤销某些错误的运营数据,需要封停某些特征的玩家……但是,分布式数据库也是最难做分布的。一般来说我们都需要通过某一主键字段做分库和分表;而另外一些如唯一关键字等数据,就需要一些技巧来处理。

[图-分表分库]
以玩家ID作为分表分库是一个非常自然的选择,但是这种方案,往往需要在逻辑代码中,对玩家数据按照自定义的规则,做存储进程的选择。但是如果发现这个分表分库的算法(原则)不符合需求,就需要把大量的数据做搬迁。如上图是按玩家ID做奇偶规则分布到两个表中,一旦需要增加第三台服务器,数据存储的目的服务器编号就变成了id%3,这样就需要把好多数据需要从原来的第一、二台数据库中拷贝出来,非常麻烦。
有的开发者会预先建立几十个表(如120个表=2x3x4x5),一开始是全部都放在一个服务器上,然后在增加数据库服务器的时候,把对应的整个表搬迁出来。这样能减轻在搬迁数据的时候造成的复杂度,但还是需要搬迁数据的。最后如果与建立的表还是放不下了,依然还是需要很复杂和耗时的重新拷贝数据。NoSQL在很多开发者绞尽脑汁折腾mysql的时候,NoSQL横空出世了。实际上在很早,目录型存储进程就在DNS等特定领域默默工作了。NoSQL系统最大的好处正是关系型数据库最大的弱点——分布。
由于主键只有一个,因此内置的分布功能使用起来非常简便。而且游戏玩家数据,绝大多数的操作都是根据主键来读写的。“自古以来”游戏就有“SL大法”之称,其本质就是对存档数据的简单读、写。在网游的早期版本MUD游戏时代,玩家存档只是简单的放在硬盘的文件上,文件名就是玩家的ID。这些,都说明了游戏中的玩家数据,其读写都是有明显约束的——玩家ID。这和NoSQL简直是天作之合。

[图-NoSQL]
NoSQL的确是非常适合用来存储游戏数据。特别是有些服务器如Redis还带有丰富的字段值类型。但是,NoSQL本身往往不带很复杂的容灾热备机制,这是需要额外注意的。而且NoSQL的访问延迟虽然比关系型数据库快很多,但是毕竟要经过一层网络。这对于那些发展了很多年的ORM库来说,缺乏了一个本地缓存的功能。这就导致了NoSQL还不能简单的取代掉所有服务器上的“状态”。而这些正是分布式缓存所希望达成的目标。分布式缓存在业界用的比较多的缓存系统有memcached,开发者有时候也会使用诸如hibernate这样的ROM库提供的cache功能。但是这些缓存系统在使用上往往会有一些限制,最主要的限制是“无法分布式使用”,也就是说缓存系统本身成为性能瓶颈后,就没有办法扩容了。或者在容灾的情景下,缓存系统往往容易变成致命的单点。
Orcale公司有一款叫Coherence的产品,就是一种能很好解决以上问题的“能分布式使用”的产品。他利用局域网的组播功能来做节点间的状态同步,同时采用节点互相备份的方案来分布数据。这款产品还使用Map接口来提供功能。这让整个缓存系统既使用简单又功能强大。更重要的是,它能让用户对于数据的存取特性做配置,从而提供用户可接受的数据风险下的更高性能——本地缓存。
由于游戏的数据,真正变化频繁的,往往不是“关键”的需要安全保障数据,如玩家的位置、玩家在某次战斗中的HP、子弹怪物的位置等等。而那些非常重要的数据,如等级、装备,又变化的不频繁。这就给了开发者针对数据特性做优化以很大的空间。而且,大部分数据的读、写频率都有典型的不平衡状态。普遍游戏数据都是读多写少。少量的日志、上报数据是写多、几乎不读。
对于缓存系统来说,有三个重要的因数决定了在游戏开发中的地位。首先是其使用的便利性,因为游戏的数据结构变化非常频繁,如果要很繁琐的配置数据结构,则不会适合游戏开发;其次是要能提供近似本地内存的性能,由于游戏服务器逻辑基本上都是在频繁的读写某一特定数据块,如玩家位置、经验、HP等等,而且游戏对于处理延迟也有较高的需求(WEB应用在2秒以内都可以忍受,游戏则要求最好能在20ms以内完成)。要能同时满足这两点,是不太容易的。

[图-分布式缓存]集成缓存的NoSQL根据上面的描述,读者应该也会想到,如果数据库系统,或者叫持久化系统,自带了缓存,是否更好呢?这样确实是会更好的,而且特别是对于NOSQL系统来说,能以一些内部的算法策略,来降低前端逻辑开发的复杂程度。一般来说,我们需要对集成缓存的NOSQL系统有以下几方面的需求:首先是冷热数据自动交换,就是对于常用数据有算法来判别其冷热,然后换入到内存以提高存取性;其次是分布式扩容和容灾功能,由于NOSQL是可以知道数据的主关键字的,所以自然就可以自动的去划分数据所在的分段,从而可以自动化的寻找到目标存储位置来做操作;最后是数据导出功能,由于NOSQL支持的查询索引只能是主键,对于很多后台游戏操作来说是不够的,所以一定要能够到处到传统的SQL服务器上去。
在这方面,有很多产品都做过一定的尝试,比如在redis或者MangoDB上做插件修改,或者以ORM系统封装MySQL以试图构造这种系统等等。

[图-集成缓存的NOSQL]
三. 跳线和开房间
开房间型游戏模型在全区分线服务器模型中,最早出现在开房间类型的游戏中。因为海量玩家需要临时聚合到一个个小的在线服务单元上互动。比如一起下棋、打牌等。这类游戏玩法和MMORPG有很大的不同,在于其在线广播单元的不确定性和广播数量很小。
这一类游戏最重要的是其“游戏大厅”的承载量,每个“游戏房间”受逻辑所限,需要维持和广播的玩家数据是有限的,但是“游戏大厅”需要维持相当高的在线用户数,所以一般来说,这种游戏还是需要做“分服”的。典型的游戏就是《英雄联盟》《穿越火线》这一类游戏了。而“游戏大厅”里面最有挑战性的任务,就是“自动匹配”玩家进入一个“游戏房间”,这需要对所有在线玩家做搜索和过滤。

[图-开房间型游戏]
这类游戏服务器,玩家先登录“大厅服务器”,然后选择组队游戏的功能,服务器会通知参与的所有游戏客户端,新开一条连接到房间服务器上,这样所有参与的用户就能在房间服务器里进行游戏交互了。
由于“大厅服务器”只负责“组队”,所以其承载力会比具体的房间服务器更高一些,但这里仍然会是性能瓶颈。所以一般我们需要尽量减少大厅服务器的功能,比如把登录功能单独列出来、把玩家的购买物品商城功能也单独出来等等。最后,我们也可以直接想办法把“组队”功能也按组队逻辑做一定划分,比如不同的组队玩法、副本类型、组队用户等级等等。
虽然这种模型已经可以对很多游戏做很好的承载了,但是在大厅服务器这里依然无法做到平行扩展,原因是玩家的在线数据比较难分布到不同的服务进程上去,而且还带有大量复杂的数据查询逻辑。

专用聊天服务器不管是MMORPG还是开房间类游戏,聊天一直都是网络游戏中一个重要的功能。而这个功能在“在线人数”很多,“聊天频道”很多的情况下,会给性能带来非常大的挑战。在很多类型的页游和少部分手机游戏里面,在线聊天甚至是唯一的“带公共状态”的服务。
聊天服务处理点对点的聊天,还有群聊。用户可能会添加好友、建立好友群组等各种功能。这些功能,都是和一般的游戏逻辑有一定差别的功能。这些功能往往并不是非常容易实现。很多游戏都期望建立类似腾讯QQ的游戏聊天功能,但是QQ是一整个公司在做开发,要用仅仅一个游戏团队做成这么完整的功能,是有一定困难的。
因此游戏开发者们常常会专门的针对聊天功能来开发一系列的服务进程,以便能让游戏的聊天功能独立出来,做到负载分流和代码重用的逻辑。很多网游系统,其聊天系统从客户端来说就是和主游戏进程分开的。
聊天服务器的本质是对客户端数据做广播,从而让玩家可以交互,所以有很多游戏开发者也直接拿聊天服务器来做棋牌游戏的房间服务器,或者反过来用。由于在游戏“分服”里面单独部署了聊天服务器,这类服务器也往往被用来承担做“跨服玩法”的进程。比如跨服团队战、跨服副本等等。不管这些服务器最终叫什么名字,实际上他们承担的主要功能还是广播,而且是运行玩家“二次登录”的广播服务器。以至于后来,有部分游戏直接全部都用聊天服务器来代替原始的“游戏服务器”,这样还能实现一个叫“跳线”的功能,也就是玩家从一个“在线环境”跳到另外一个“在线环境”去。——这些都是对于“广播”功能的灵活运用。

 

[图-专用聊天服务器]
全服全线模型
尽管分服的游戏模型已经运营了很多年,但是有一些游戏运营商还是希望能让尽量多的玩家一起玩。因为网游的人气越活跃,产生的交互越多,游戏的乐趣也可能越多。这一点最突出表现在棋牌类网游上。如联众、QQ游戏这类产品,无不是希望更多玩家能同时在线接入一个“大”服务器,从而找到可以一起玩的伙伴。在手游时代,由于手机本身在线时间不稳定,所以想要和朋友一起玩本来就比较困难,如果再以“服务器”划分区域,交互的乐趣就更少了,所以同样也呼唤这一个“大”服务器,能容纳下所有此款游戏的玩家。因此,开发者们在以前积累的分服模型和分线模型基础上,开发出满足海量在线互动需求的一系列游戏服务器模型——全服全线模型。

[图-全服全线模型]
一. 服务进程的组织
静态配置全服全线模型的本质是一个各种不同功能进程组成的分布式系统,因此这些进程间的关系是在运维部署期间必须关注的信息。最简单的处理方法,就是预先规划出具体的进程数量、以及进程部署的物理位置,然后通过一套配置文件来描述这个规划的内容。对于每个进程,需要配置列明每个进程的pid文件位置;内部通讯用的地址,如IP+端口或者消息队列ID;启动和停止脚本路径;日志路径等等……由于有了一套这样的配置文件,我们还可以编写工具对所有的这些进程进行监控和操作批量启停。

[图-静态配置]
虽然我们可以以静态配置为基础做很丰富的管理工具,但是这种做法还是有可以改进的空间:每次扩容、更换故障服务器或者搬迁服务器(这在运营中很常见),我们都必须手工修改静态配置数据,由于是人工操作,就总会产生很多错误,根据个人经验,游戏运营事故中的70%以上,是跟运维操作有关;由于整个分布式系统被切分成大量的进程,对于新进入此项目的程序员来说,要完整的理解这个系统,需要在思想上跨越层层阻隔:每个进程的功能、它们部署的关联、每个进程间的协议报的含义、每个业务流程具体的跨进程过程……这要花费很多时间才能搞明白的。而且大部分游戏的这种架构并不统一,每个游戏都可能需要重新理解一次,知识无法重用;在开发测试上,由于分布式系统的复杂性,要多搭几个开发、测试环境也是很费时间的,以至于这项工作甚至要安排专人来负责,这对于小型游戏开发团队来说几乎是不可承担的成本。因此我们还需要一些更加自动化,更加容易理解的全服全线游戏服务器模型。 基于中心点的动态组织SOA架构模式是业界一个比较经典的分布式软件架构模式,这个架构的特点是能动态的组织一个非常复杂的分布式服务系统。这个系统可以包含提供各种各样供的服务程序,而这些服务程序都以同一个标准接口来使用,并且服务自己会注册自己到集群中,以便请求方能找到自己。这种架构使用Web Serivce来作为服务接口标准,通过发布WSDL来提供接口API,这极大的降低了开发者对这些服务的使用成本。在游戏领域,服务器端提供的功能程序,实际上也是非常多样的,如果要构建一个分布式的系统,在这个方面是非常适合SOA架构的思想的;然而,游戏却很少使用HTTP协议及其之上的Web Service做通讯层,因为这个协议性能太低。不过,类似SOA的,基于中心节点的动态组织的服务管理思路,却依然适用。

[图-基于中心点的动态组织]
一般来说我们会使用一组目录服务器来充当“中心点”,代表整个集群。开源产品中最好的产品就是ZooKeeper了。当然也有一些开发者自己编写这样的目录服务器。由于每个服务进程会自己上报负载和状态,所以每个进程只需要配置自己提供的服务即可:服务名字、服务接口。对于请求方来说,一般都可以预先编写目标服务接口的类库,用来编程,有些项目还使用RPC功能,使用IDL语言配置直接生成这些接口类库。当需要请求的时候,执行“名字查找”-“路由选择”-“发起请求”就可以完成整个过程。由于有“查找”-“路由”的过程,所以如果目标服务故障、或者新增了服务提供者,请求方就能自动获得这些信息,从而达到自动动态扩容或容灾的效果,这些都是无需专门去做配置的。

服务化与云尽管动态组织的架构有如此多优点,但是开发者还是需要自己部署和维护中心节点。对于一些常用的服务,如网络代理服务、数据存储服务,用户还是要自己去安装,以及想办法接入到这套体系中去。这对于开发、测试还是有一定的运维工作压力的。于是一些开发团队就把这类工作集中起来,预先部署一套大的集群中心系统,所有开发者都直接使用,而不是自己去安装部署,这就成为了服务化,或者云服务。

[图-服务化、云]
使用专人维护的服务化集群确实是一个轻松愉快的过程。但是游戏开发和运营过程中,往往需要多套环境,如各个不同版本的测试环境、给不同运营平台搭建的环境、海外运营的环境等等……这些环境会大大增加维护服务化集群的工作量,对于解决这个问题,建立高度自动化运维的私有云,成为一个需要解决的问题放上了桌面。提高集群的运维效率,降低工作复杂程度,需要一些特别的技术,而虚拟化技术正式解决这些问题的最新突破。

二. 提高开发效率所用的结构
使用RPC提高网络接口编写效率在分布式系统中,如果所有的接口都需要自己定义数据协议报来做交互,这个网络编程的工作量将会非常的大,因为对于一个普通的通信接口来说,至少包括了:一个请求包结构、一个响应包结构、四段代码,包括请求响应包的编码和解码、一个接收数据做分发的代码分支、一个发送回应的调用。由于分布式的游戏服务器进程非常多,一个类似登录这样的操作,可能需要历经三、四个进程的合作处理,这就导致了接近十个数据结构的定义和无数段类似的代码。而这些代码,如果在单进程的环境下,仅仅只是三、四个函数定义而已。
因此很多开发者投入很大精力,让网络通信的编写过程,尽量简化成类似函数的编写一样。这就是前文所述的远程调用的方法。在全区全线的游戏中,如果是比较重度的游戏,采用RPC方式做开发,会大大降低开发的复杂程度。当然也有一些比较轻度的游戏,还是采用传统的协议包编解码、分发逻辑调用的做法。

简化数据处理在分布式系统中,对于避免单点、容灾、扩容中最复杂的问题,就是在内存中的数据。由于内存中有游戏业务的数据,所以一般我们不敢随便停止进程,也难以把一个进程的服务替换为另外一个进程。然而,游戏数据对比其他业务,还是非常有特点的:
写入越不频繁的数据,价值越高。比如过关、升级、获得重要装备。
大量数据都是读非常频繁,而写非常不频繁的,如玩家的等级、经验。
大量写入频繁的数据,实际上是不太重要,可以有一定损失,比如玩家位置,在某个关卡内的HP/MP等……
因此,只要我们能按数据的特性,对游戏中需要处理的数据做一定分类,就能很好的解决分布式中的这些问题。
首先我们要对数据的分布做规划,一般来说采用按玩家ID做分布,这样能让服务进程中内存的数据缓存高度命中。常用的手法有用一致性哈希来选择路由,调用相关的服务进程。
其次对于读频繁而写不频繁的数据,我们采用读缓存而写不缓存的策略。每个服务进程都保留其读缓存数据,如果需要扩容和容灾,仅仅需要修改服务访问的路由即可。
再次对于读不频繁而写频繁的数据,我们采用写缓存和读不缓存的策略。由于这些数据丢失掉一些是不要紧的,所以容灾处理就直接忽略即可,对于扩容,只需要对所有服务进程都做一次回写即可。
最后,有一些数据是读和写都频繁的数据,比如玩家位置,HP/MP这类,我们采用读写都缓存,由于数据重要性不高,只要我们多分几个服务进程即可降低故障时影响的范围;在扩容的时候调用全节点清理读缓存和回写脏数据即可。

在和持久化设备打交道的时候,传统的ORM类库往往能帮我们把数据存入关系型数据库,然而,使用一个自带数据热备的NOSQL也是很好的选择。因为这样能节省大量的分库分表逻辑代码。

自动化部署集群环境最新的虚拟化技术给分布式系统提供能更好的部署手段,以Docker为标志的虚拟化平台,可以很好的提高服务化集群的管理。我们可以把每个服务进程打包成一个映像文件,放入docker虚拟机中运行,也可以把一组互相关联的服务进程打包运行。这些环境问题都由Docker处理了。但是,我们同时需要注意的是,如果我们的进程的资源是静态分配的(前文提到),在Docker的虚拟机中可能因为内存不足等原因直接无法启动。这就需要我们把完全静态分配资源的程序,修改为有资源限制,但是动态分配的程序。这样我们才能在任何可以部署Docker的机器上部署我们的游戏服务器。

三. 分布式难点:状态同步
分布式接入层一般来说,我们全线服务器系统碰到的第一个问题,就是大量并发的网络请求。特别是大量玩家都在一起交互,产生了大量由于状态同步而需要广播的数据包。这些网络请求的处理,显然应该独立出来成为单独的进程。同时这些网络接入进程,还应该是一个集群中的成员。这就诞生了分布式接入服务层。
这些网路接入进程的第一个功能,就是把并发的连接,代理成为后端一个串行的连接,这可以让后端服务进程的处理逻辑更简单,而且网络处理消耗变得更小。
其次,网络接入进程需要支持广播功能。如果只是普通的广播实现,很多人会需要拷贝很多次需要广播的内容,然后挨个对Socket做发送。这其实是一个消耗很高的操作。而单独的网络接入进程,可以善用“零拷贝”等技术,大大降低广播的性能开销。而且还可以通过多个进程一起做广播操作,以达到更大的在线同步区域。

最后,网络接入进程需要支持一些额外的有用功能,包括通讯的加密、压缩、流量控制、过载保护等等。有些团队还把用户的登录鉴权也加入网络接入功能中。

[图-分布式接入层]
使用P2P网络状态同步产生的广播请求中,绝大多数都是客户端之间的网络状态,因此我们在可以使用P2P的客户端之间,直接建立P2P的UDP数据连接,会比通过服务器转发降低非常多的负载。在一些如赛车、音乐、武打类型的著名游戏中,都有使用P2P技术。而接入进程天然的就是一个P2P撮合服务器。
有些游戏为了进一步降低延迟,还对所有的玩家状态,只同步输入动作,以及死亡、技能等重要状态,让怪物和一般状态通过计算获得,这样就更能节省玩家的带宽,提高及时性。加上一些动作预测技术,在客户端上能表现的非常流畅。

展望
一. 可重用的游戏业务模版
游戏服务端的各种架构中,以前往往比较关注那些非功能性的需求:容灾性、扩容、承载量,延迟。而在现在手游时代,开发效率越来越重要,有些团队甚至不设专门的服务器端程序员。因此游戏服务端架构应该更多的关注业务开发的效率。
现代游戏中,只要是带RPG元素的,角色系统、物品系统、技能系统、任务系统就都会具备,而且都有一批比较稳定的核心逻辑。只要是能在线交互的,就有好友系统、邮件系统、聊天系统、公会系统等。另外商城系统、活动系统、公告系统更是每个游戏都似乎要重复发明的轮子。
游戏的后端应用也有很多可重用的部分,比如客服系统、数据统计平台、官网数据接口等等。这些在游戏服务端框架中往往是最后再添加进去的。
如果把以上的问题都统一考虑起来,我们实际上是可以在一个稳定的底层架构上,构造出一整套常用的游戏业务逻辑模板,用来减少游戏领域的业务代码开发。所以这样一套可以运行各种业务逻辑模版的底层架构,正是游戏服务端架构发展的方向。
二. 动态资源调度的PaaS云
现在有的团队已经在搭建自己的Docker云,这可以让游戏服务器在虚拟云上动态的生长,从而达到真正的动态扩容和动态容灾。加上如果游戏服务器不再是一个个服务进程,而是真正意义上的一个个服务,可以动态的加入或者离开云环境,那么这就是一个游戏领域的PaaS系统。我热切的希望能看到,可以用一套SDK,开发或重用那些成型的业务模版,然后动态注册到服务云中就能运行,这样一种游戏服务器架构。

作者:JumboWu
链接:https://www.jianshu.com/p/4d769767c1ac

经典游戏服务器端架构概述 (一)(转)

架构的分析模型
一. 讨论的背景
现代电子游戏,基本上都会使用一定的网络功能。从验证正版,到多人交互等等,都需要架设一些专用的服务器,以及编写在服务器上的程序。因此,游戏服务器端软件的架构,本质上也是游戏服务器这个特定领域的软件架构。
软件架构的分析,可以通过不同的层面入手。比较经典的软件架构描述,包含了以下几种架构:
运行时架构——这种架构关心如何解决运行效率问题,通常以程序进程图、数据流图为表达方式。在大多数开发团队的架构设计文档中,都会包含运行时架构,说明这是一种非常重要的设计方面。这种架构也会显著的影响软件代码的开发效率和部署效率。本文主要讨论的是这种架构。

逻辑架构——这种架构关心软件代码之间的关系,主要目的是为了提高软件应对需求变更的便利性。人们往往会以类图、模块图来表达这种架构。这种架构设计在需要长期运营和重用性高的项目中,有至关重要的作用。因为软件的可扩展性和可重用度基本是由这个方面的设计决定的。特别是在游戏领域,需求变更的频繁程度,在多个互联网产业领域里可以说是最高的。本文会涉及一部分这种架构的内容,但不是本文的讨论重点。

物理架构——关心软件如何部署,以机房、服务器、网络设备为主要描述对象。

数据架构——关心软件涉及的数据结构的设计,对于数据分析挖掘,多系统协作有较大的意义。

开发架构——关心软件开发库之间的关系,以及版本管理、开发工具、编译构建的设计,主要为了提高多人协作开发,以及复杂软件库引用的开发效率。现在流行的集成构建系统就是一种开发架构的理论。

二. 游戏服务器架构的要素
服务器端软件的本质,是一个会长期运行的程序,并且它还要服务于多个不定时,不定地点的网络请求。所以这类软件的特点是要非常关注稳定性和性能。这类程序如果需要多个协作来提高承载能力,则还要关注部署和扩容的便利性;同时,还需要考虑如何实现某种程度容灾需求。由于多进程协同工作,也带来了开发的复杂度,这也是需要关注的问题。
功能约束,是架构设计决定性因素。一个万能的架构,必定是无能的架构。一个优秀的架构,则是正好把握了对应业务领域的核心功能产生的。游戏领域的功能特征,于服务器端系统来说,非常明显的表现为几个功能的需求:
对于游戏数据和玩家数据的存储

对玩家客户端进行数据广播

把一部分游戏逻辑在服务器上运算,便于游戏更新内容,以及防止外挂。

针对以上的需求特征,在服务器端软件开发上,我们往往会关注软件对电脑内存和CPU的使用,以求在特定业务代码下,能尽量满足承载量和响应延迟的需求。最基本的做法就是“时空转换”,用各种缓存的方式来开发程序,以求在CPU时间和内存空间上取得合适的平衡。在CPU和内存之上,是另外一个约束因素:网卡。网络带宽直接限制了服务器的处理能力,所以游戏服务器架构也必定要考虑这个因素。
对于游戏服务器架构设计来说,最重要的是利用游戏产品的需求约束,从而优化出对此特定功能最合适的“时-空”架构。并且最小化对网络带宽的占用。

[图-游戏服务器的分析模型]

三. 核心的三个架构
基于上述的分析模型,对于游戏服务端架构,最重要的三个部分就是,如何使用CPU、内存、网卡的设计:
内存架构:主要决定服务器如何使用内存,以保证尽量少的内存泄漏的可能,以及最大化利用服务器端内存来提高承载量,降低服务延迟。

调度架构:设计如何使用进程、线程、协程这些对于CPU调度的方案。选择同步、异步等不同的编程模型,以提高服务器的稳定性和承载量。同时也要考虑对于开发带来的复杂度问题。现在出现的虚拟化技术,如虚拟机、Docker、云服务器等,都为调度架构提供了更多的选择。

通信模式:决定使用何种方式通讯。网络通讯包含有传输层的选择,如TCP/UDP;据表达层的选择,如定义协议;以及应用层的接口设计,如消息队列、事件分发、远程调用等。

本文的讨论,也主要是集中于对以上三个架构的分析。
四. 游戏服务器模型的进化历程
最早的游戏服务器是比较简单的,如UO《网络创世纪》的服务端一张3.5寸软盘就能存下。基本上只是一个广播和存储文件的服务器程序。后来由于国内的外挂、盗版流行,各游戏厂商开始以MUD为模型,建立主要运行逻辑在服务器端的架构。这种架构在MMORPG类产品的不断更新中发扬光大,从而出现了以地图、视野等分布要素设计的分布式游戏服务器。而在另外一个领域,休闲游戏,天然的需要集中超高的在线用户,所以全区型架构开始出现。现代的游戏服务器架构,基本上都希望能结合承载量和扩展性的有点来设计,从而形成了更加丰富多样的形态。本文的讨论主要是选取这些比较典型的游戏服务器模型,分析其底层各种选择的优点和缺点,希望能探讨出更具广泛性,更高开发效率的服务器模型。
分服模型

一. 模型描述

分服模型是游戏服务器中最典型,也是历久最悠久的模型。其特征是游戏服务器是一个个单独的世界。每个服务器的帐号是独立的,而且只用同一服务器的帐号才能产生线上交互。在早期服务器的承载量达到上限的时候,游戏开发者就通过架设更多的服务器来解决。这样提供了很多个游戏的“平行世界”,让游戏中的人人之间的比较,产生了更多的空间。所以后来以服务器的开放、合并形成了一套成熟的运营手段。一个技术上的选择最后导致了游戏运营方式的模式,是一个非常有趣的现象。

[图-分服模型]
二. 调度架构
单进程游戏服务器最简单的游戏服务器只有一个进程,是一个单点。这个进程如果退出,则整个游戏世界消失。在此进程中,由于需要处理并发的客户端的数据包,因此产生了多种选择方法:

[图-单进程调度模型]
同步-动态多线程:每接收一个用户会话,就建立一个线程。这个用户会话往往就是由客户端的TCP连接来代表,这样每次从socket中调用读取或写出数据包的时候,都可以使用阻塞模式,编码直观而简单。有多少个游戏客户端的连接,就有多少个线程。但是这个方案也有很明显的缺点,就是服务器容易产生大量的线程,这对于内存占用不好控制,同时线程切换也会造成CPU的性能损失。更重要的多线程下对同一块数据的读写,需要处理锁的问题,这可能让代码变的非常复杂,造成各种死锁的BUG,影响服务器的稳定性。同步-多线程池:为了节约线程的建立和释放,建立了一个线程池。每个用户会话建立的时候,向线程池申请处理线程的使用。在用户会话结束的时候,线程不退出,而是向线程池“释放”对此线程的使用。线程池能很好的控制线程数量,可以防止用户暴涨下对服务器造成的连接冲击,形成一种排队进入的机制。但是线程池本身的实现比较复杂,而“申请”、“施放”线程的调用规则需要严格遵守,否则会出现线程泄露,耗尽线程池。

异步-单线程/协程:在游戏行业中,采用Linux的epoll作为网络API,以期得到高性能,是一个常见的选择。游戏服务器进程中最常见的阻塞调用就是网路IO,因此在采用epoll之后,整个服务器进程就可能变得完全没有阻塞调用,这样只需要一个线程即可。这彻底解决了多线程的锁问题,而且也简化了对于并发编程的难度。但是,“所有调用都不得阻塞”的约束,并不是那么容易遵守的,比如有些数据库的API就是阻塞的;另外单进程单线程只能使用一个CPU,在现在多核多CPU的服务器情况下,不能充分利用CPU资源。异步编程由于是基于“回调”的方式,会导致要定义很多回调函数,并且把一个流程里面的逻辑,分别写在多个不同的回调函数里面,对于代码阅读非常不理。——针对这种编码问题,协程(Coroutine)能较好的帮忙,所以现在比较流行使用异步+协程的组合。不管怎样,异步-单线程模型由于性能好,无需并发思维,依然是现在很多团队的首选。

异步-固定多线程:这是基于异步-单线程模型进化出来的一种模型。这种模型一般有三类线程:主线程、IO线程、逻辑线程。这些线程都在内部以全异步的方式运行,而他们之间通过无锁消息队列通信。

多进程游戏服务器多进程的游戏服务器系统,最早起源于对于性能问题需求。由于单进程架构下,总会存在承载量的极限,越是复杂的游戏,其单进程承载量就越低,因此开发者们一定要突破进程的限制,才能支撑更复杂的游戏。一旦走上多进程之路,开发者们还发现了多进程系统的其他一些好处:能够利用上多核CPU能力;利用操作系统的工具能更仔细的监控到运行状态、更容易进行容灾处理。多进程系统比较经典的模型是“三层架构”:在多进程架构下,开发者一般倾向于把每个模块的功能,都单独开发成一个进程,然后以使用进程间通信来协调处理完整的逻辑。这种思想是典型的“管道与过滤器”架构模式思想——把每个进程看成是一个过滤器,用户发来的数据包,流经多个过滤器衔接而成的管道,最后被完整的处理完。由于使用了多进程,所以首选使用单进程单线程来构造其中的每个进程。这样对于程序开发来说,结构清晰简单很多,也能获得更高的性能。

[图-经典的三层模型]
尽管有很多好处,但是多进程系统还有一个需要特别注意的问题——数据存储。由于要保证数据的一致性,所以存储进程一般都难以切分成多个进程。就算对关系型数据做分库分表处理,也是非常复杂的,对业务类型有依赖的。而且如果单个逻辑处理进程承载不了,由于其内存中的数据难以分割和同步,开发者很难去平行的扩展某个特定业务逻辑。他们可能会选择把业务逻辑进程做成无状态的,但是这更加加重了存储进程的性能压力,因为每次业务处理都要去存储进程处拉取或写入数据。除了数据的问题,多进程也架构也带来了一系列运维和开发上的问题:首先就是整个系统的部署更为复杂了,因为需要对多个不同类型进程进行连接配置,造成大量的配置文件需要管理;其次是由于进程间通讯很多,所以需要定义的协议也数量庞大,在单进程下一个函数调用解决的问题,在多进程下就要定义一套请求、应答的协议,这造成整个源代码规模的数量级的增大;最后是整个系统被肢解为很多个功能短小的代码片段,如果不了解整体结构,是很难理解一个完整的业务流程是如何被处理的,这让代码的阅读和交接成本巨高无比,特别是在游戏领域,由于业务流程变化非常快,几经修改后的系统,几乎没有人能完全掌握其内容。
三. 内存架构
由于服务器进程需要长期自动化运行,所以内存使用的稳定是首要大事。在服务器进程中,就算一个触发几率很小的内存泄露,都会积累起来变成严重的运营事故。需要注意的是,不管你的线程和进程结构如何,内存架构都是需要的,除非是Erlang这种不使用堆的函数式语言。
动态内存在需要的时候申请内存来处理问题,是每个程序员入门的时候必然要学会的技能。但是,如何控制内存释放却是一个大问题。在C/C++语言中,对于堆的控制至关重要。有一些开发者会以树状来规划内存使用,就是一般只new/delete一个主要的类型的对象,其他对象都是此对象的成员(或者指针成员),只要这棵树上所有的对象都管理好自己的成员,就不会出现内存漏洞,整个结构也比较清晰简单。

[图-对象树架构]
在Objective C语言中,有所谓autorealse的特性,这种特性实际上是一种引用计数的技术。由于能配合在某个调度模型下,所以使用起来会比较简单。同样的思想,有些开发者会使用一些智能指针,配合自己写的框架,在完整的业务逻辑调用后一次性清理相关内存。

[图-根据业务处理调度管理内存池]
在带虚拟机的语言中,最常见的是Java,这个问题一般会简单一些,因为有自动垃圾回收机制。但是,JAVA中的容器类型、以及static变量依然是可能造成内存泄露的原因。加上无规划的使用线程,也有可能造成内存的泄露——有些线程不会退出,而且在不断增加,最后耗尽内存。所以这些问题都要求开发者专门针对static变量以及线程结构做统一设计、严格规范。

预分配内存动态分配内存在小心谨慎的程序员手上,是能发挥很好的效果的。但是游戏业务往往需要用到的数据结构非常多,变化非常大,这导致了内存管理的风险很高。为了比较彻底的解决内存漏洞的问题,很多团队采用了预先分配内存的结构。在服务器启动的时候分配所有的变量,在运行过程中不调用任何new关键字的代码。
这样做的好处除了可以有效减少内存漏洞的出现概率,也能降低动态分配内存所消耗的性能。同时由于启动时分配内存,如果硬件资源不够的话,进程就会在启动时失败,而不是像动态分配内存的程序一样,可能在任何一个分配内存的时候崩溃。然而,要获得这些好处,在编码上首先还是要遵循“动态分配架构”中对象树的原则,把一类对象构造为“根”对象,然后用一个内存池来管理这些根对象。而这个内存池能存放的根对象的数目,就是此服务进程的最大承载能力。一切都是在启动的时候决定,非常的稳妥可靠。

[图-预分配内存池]
不过这样做,同样有一些缺点:首先是不太好部署,比如你想在某个资源较小的虚拟机上部署一套用来测试,可能一位内没改内存池的大小,导致启动不成功。每次更换环境都需要修改这个配置。其次,是所有的用到的类对象,都要在根节点对象那里有个指针或者引用,否则就可能泄漏内存。由于对于非基本类型的对象,我们一般不喜欢用拷贝的方式来作为函数的参数和返回值,而指针和应用所指向的内存,如果不能new的话,只能是现成的某个对象的成员属性。这回导致程序越复杂,这类的成员属性就越多,这些属性在代码维护是一个不小的负担。
要解决以上的缺点,可以修改内存池的实现,为动态增长,但是具备上限的模型,每次从内存池中“获取”对象的时候才new。这样就能避免在小内存机器上启动不了的问题。对于对象属性复杂的问题,一般上需要好好的按面向对象的原则规划代码,做到尽量少用仅仅表示函数参数和返回值的属性,而是主要是记录对象的“业务状态”属性为主,多花点功夫在构建游戏的数据模型上。

四. 进程间通讯手段
在多进程的系统中,进程间如何通讯是一个至关重要的问题,其性能和使用便利性,直接决定了多进程系统的技术效能。
Socket通讯TCP/IP协议是一种通用的、跨语言、跨操作系统、跨机器的通讯方案。这也是开发者首先想到的一种手段。在使用上,有使用TCP和UDP两个选择。一般我们倾向在游戏系统中使用TCP,因为游戏数据的逻辑相关性比较强,UDP由于可能存在的丢包和重发处理,在游戏逻辑上的处理一般比较复杂。由于多进程系统的进程间网络一般情况较好,UDP的性能优势不会特别明显。
要使用TCP做跨进程通讯,首先就是要写一个TCP Server,做端口监听和连接管理;其次需要对可能用到的通信内容做协议定制;最后是要编写编解码和业务逻辑转发的逻辑。这些都完成了之后,才能真正的开始用来作为进程间通信手段。

使用Socket编程的好处是通用性广,你可以用来实现任何的功能,和任何的进程进行协作。但是其缺点也异常明显,就是开发量很大。虽然现在有一些开源组件,可以帮你简化Socket Server的编写工作,简化连接管理和消息分发的处理,但是选择目标建立连接、定制协议编解码这两个工作往往还是要自己去做。游戏的特点是业务逻辑变化很多,导致协议修改的工作量非常大。因此我们除了直接使用TCP/IP socket以外,还有很多其他的方案可以尝试。

[图-TCP通讯]消息队列在多进程系统中,如果进程的种类比较多,而且变化比较快,大量编写和配置进程之间的连接是一件非常繁琐的工作,所以开发者就发明了一种简易的通讯方法——消息队列。这种方法的底层还是Socket通讯实现,但是使用者只需要好像投递信件一样,把消息包投递到某个“信箱”,也就是队列里,目标进程则自动不断去“收取”属于自己的“信件”,然后触发业务处理。
这种模型的好处是非常简单易懂,使用者只需要处理“投递”和“收取”两个操作即可,对于消息也只需要处理“编码”和“解码”两个部分。在J2EE规范中,就有定义一套消息队列的规范,叫JMS,Apache ActiveMQ就是一个应用广泛的实现者。在linux环境下,我们还可以利用共享内存,来承担消息队列的存储器,这样不但性能很高,而且还不怕进程崩溃导致未处理消息丢失。

[图-消息队列]
需要注意的是,有些开发者缺乏经验,使用了数据库,如MySQL,或者是NFS这类运行效率比较低的媒介作为队列的存储者。这在功能上虽然可以行得通,但是操作一频繁,就难以发挥作用了。如以前有一些手机短信应用系统,就用mysql来存储“待发送”的短信。
消息队列虽然非常好用,但是我们还是要自己对消息进行编解码,并且分发给所需要的处理程序。在消息到处理程序之间,存在着一个转换和对应的工作。由于游戏逻辑的繁多,这种对应工作完全靠手工编码,是比较容易出错的。所以这里还有进一步的改进空间。

远程调用有一些开发者会希望,在编码的时候完全屏蔽是否跨进程在进行调用,完全可以好像调用本地函数或者本地对象的方法一样。于是诞生了很多远程调用的方案,最经典的有Corba方案,它试图实现能在不同语言的代码直接,实现远程调用。JAVA虚拟机自带了RMI方案的支持,在JAVA进程之间远程调用是比较方便的。在互联网的环境下,还有各种Web Service方案,以HTTP协议作为承载,WSDL作为接口描述。
使用远程调用的方案,最大好处是开发的便捷,你只需要写一个函数,就能在任何一个其他进程上对此函数进行调用。这对游戏开发来说,就解决了多进程方案最大的一个开发效率问题。但是这种便捷是有成本的:一般来说,远程调用的性能会稍微差一点,因为需要用一套统一的编解码方案。如果你使用的是C/C++这类静态语言,还需要使用一种IDL语言来先描述这种远程函数的接口。但是这些困难带来的好处,在游戏开发领域还是非常值得的。

[图-远程调用]

五. 容灾和扩容手段
在多进程模型中,由于可以采用多台物理服务器来部署服务进程,所以为容灾和扩容提供了基础条件。
在单进程模型下,容灾常常使用的热备服务器,依然可以在多进程模型中使用,但是开着一台什么都不做的服务器完全是为了做容灾,多少有点浪费。所以在多进程环境下,我们会启动多个相同功能的服务器进程,在请求的时候,根据某种规则来确定对哪个服务进程发起请求。如果这种规则能规避访问那些“失效”了的服务进程,就自动实现了容灾,如果这个规则还包括了“更新新增服务进程”的逻辑,就可以做到很方便的扩容了。而这两个规则,统一起来就是一条:对服务进程状态的集中保存和更新。
为了实现上面的方案,常常会架设一个“目录”服务器进程。这个进程专门负责搜集服务器进程的状态,并且提供查询。ZooKeeper就是实现这种目录服务器的一个优秀工具。

[图-服务器状态管理]
尽管用简单的目录服务器可以实现大部分容灾和扩容的需求,但是如果被访问进程的内存中有数据存在,那么问题就比较复杂了。对于容灾来说,新的进程必须要有办法重建那个“失效”了的进程内存中的数据,才可能完成容灾功能;对于扩容功能来说,新加入的进程,也必须能把需要的数据载入到自己的内存中才行,而这些数据,可能已经存在于其他平行的进程中,如何把这部分数据转移过来,是一个比较耗费性能和需要编写相当多代码的工作。——所以一般我们喜欢对“无状态”的进程来做扩容和容灾。

作者:JumboWu
链接:https://www.jianshu.com/p/6dc22d5de649

FairyGUI中常用的方法,对比UGUI[转]

素材管理
可以直接将图片(Gif)、声音(mp3)、动画、文字等素材从资源浏览器拖动到库中。
资源Url

UIPackage.getItemURL(“包名“,“资源名”)
AudioClip clip = (AudioClip)UIPackage.GetItemAsset(“包名称”,”声音名称”);

菜单”编辑”->“创建位图字体”,(输入字符,显示对应图片)
多信息文本(GRichTextField)支持链接和图文混排。
用例: aTextField.text = “请去找王大锤”;

列表 (GList)
AddChild : 增加一个项目。
AddChildAt :在指定的位置增加一个项目。
RemoveChild : 删除一个项目。
RemoveChildAt : 删除一个指定位置的项目。
RemoveChildren : 删除一个范围内的项目,或者全部删除。
GList内建了对象池。
使用对象池后的方法:
AddItemFromPool : 从池里取出(如果有)或者新建一个对象,添加到列表中
GetFromPool : 从池里取出(如果有)或者新建一个对象
ReturnToPool : 将对象返回池里
RemoveChildToPool : 删除一个列表项目,并将对象返回池里
RemoveChildToPoolAt : 删除一个指定位置的项目,并将对象返回池里
RemoveChildrenToPool:删除一个范围内的项目,或者全部删除,并将删除的对象都返回池里
添加对象时不使用池,对象池将不断增大。
正确的做法:从池中创建对象。即使用AddItemFromPool或GetFromPool。

虚拟列表 GList.SetVirtual
使用GList.numItems设定列表项目的数量。注意与GList.numChildren区分,后者是当前列表容器的显示对象数量。
但要注意显示对象和列表项目的数量在数量上和顺序上都是不一致的,也就是GetChildAt(0)获得的显示对象并不等于列表的第一条项目。
列表滚动到目标位置(第500个),调用GList.AddSelection(500)
虚拟列表只能通过numItems改变列表项目的数量,不允许使用AddChild或RemoveChild增删对象。例如如果要清空列表,必须要通过设置numItems=0,而不是RemoveChildren。
循环列表 GList.SetVirtualAndLoop()。

GList.ensureBoundsCorrect()通知GList立刻重排。(手动触发重新排列)

装载器 GLoader
运行时设置装载器内容的方式是:
aLoader.url = “ui://xxxxx”;
aLoader.url = “demo/aimage”; //这里加载的是路径为Assets/Resources/demo/aimage的一个贴图
例如,你希望从AssetBundle中获取资源,那么你可以扩展GLoader。首先编写你的Loader类,例如:

这是一个egret中使用到的自定义loader,使用getResByUrl这个API加载外部资源。
然后我们就可以用fairygui.UIObjectFactory.setLoaderExtension(MyGLoader);注册我们要使用的Loader类。注册完成后,游戏中所有装载器都是由MyGLoader实例化产生。
组件
点击穿透 默认情况下,组件的矩形区域将拦截点击,勾选后,点击事件可以穿透组件中没有内容的空白区域。
控制器 Controller
Controller c1 = aComponent.GetController(“c1”)
c1.selectedIndex = 1;//1是页面索引

c1.selectedPage = ‘pageName’;//pageName就是页面名称

说明:
对所有参与的页面,元件将分别保存不同的坐标值;对所有没有参与的页面,元件将保存同一个坐标值。
缓动功能 (位移的插值?)
按钮控制器 Button
单选组(RadioGroup)
在程序中,要获得或设置哪个按钮被选中也非常简单,使用控制器的selectedIndex或者selectedPage就可以了。

设置关联 ( 类似锚点,相对位置的设置 )

这里有一个垂直中线的关联,下面会说明,暂且不表。置可以看到,在文本内容发生变化时,文本的中线位置没有发生变化,位所以问号图标的置不变;但文本的右侧位发生了变化,所以叹号图标随之发生了移动,保持了与文本右侧的距离。
在代码中设置关联
(比如浏览器窗口被玩家拖大拖小),组件依然保持在右侧位置,那么可以这样调用:
aComoponet.addRelation(GRoot.inst, RelationType.Right_Right);

又例如希望一个动态添加到舞台的组件始终保持满屏大小,可以这样调用
aComoponet.setSize(GRoot.inst.width, GRoot.inst.height);
aComoponet.addRelation(GRoot.inst, RelationType.Size);

RelationType.Size相当于RelationType.Width_Width和RelationType.Height_Height的组合。这里强调一下,使组件变为满屏大小这个操作必须由你完成,也就是上面代码中的setSize调用。关联并不能完整这项任务,因为关联是不管元件当前的大小的,它只会在目标变化时保持两者大小的差别。

A:和容器组件”垂直中线“关联
B:和容器组件”右->右”关联
C:和容器组件“右->右”,”底->底“关联
D:和容器组件”底->底”,“垂直中线%”关联
E:和容器组件“底->底”关联
然后运行时把这个界面设置为满屏就可以了。
aComponent.SetSize(GRoot.inst.width, GRoot.inst.height);
aComoponet.addRelation(GRoot.inst, RelationType.Size);//当屏幕改变时仍然保持全屏

FairyGUI教程:(九)组件的扩展
FairyGUI提供的控件有:
图片(GImage)、动画(GMovieClip)、图形(GGraph)、文本(GTextField)、多信息文本(GRichTextFIeld)、列表(GList)、装载器(GLoader)、组件(GComponent)。这些都是非常基础的控件,他们是UI制作中的最小粒度。但仅靠这些基础控件是不足以制作出各种复杂的UI界面的。我们通过”扩展“功能,从组件(GComponent)中扩展出来以下这些复合组件:按钮(GButton),标签(GLabel),下拉框(GComboBox),进度条(GProgressBar),滑动条(GSlider),滚动条(GScrollbar)。

可以看到有六种“扩展”选择。组件可以随意在这些“扩展”中切换。选择哪种“扩展”,组件就有了哪个扩展的属性和行为特性。
指定统一点击音效
如果希望游戏中所有按钮的点击都有声音反馈,你并不需要每个按钮都设置一次声音属性,因为在游戏中可以使用代码UIConfig.buttonSound=’xxx’为所有按钮设置一个点击声音。
滚动条
运行时使用的滚动条需要通过以下代码设置:
UIConfig.horizontalScrollBar = ‘xxx’;
UIConfig.verticalScrollBar = ‘yyy’;
这里xxx和yyy就是滚动条资源的url。
UIConfig.defaultScrollBarDisplay = ScrollBarDisplayType.Auto; // 设置为,滚动时显示滚动条

9、自定义扩展
当基础组件、扩展组件都不能满足你的需求时,你可以编写自定义的扩展。使用API UIObjectFactory.setPackageItemExtension完成定义。例如:
UIObjectFactory.setPackageItemExtension(UIPackage.getItemURL(“包名“,”组件A”), MyComponent );
public class MyComponent extends GComponent
{
override protected function constructFromXML(xml:XML):void
{
super.constructFromXML(xml);
//在这里继续你的初始化
}
}
这样就为组件A指定了一个实现类MyComponent 。以后所有组件A创建出来的对象(包括在编辑器里使用的组件A)都为MyComponent 类型。例如:
var obj:MyComponent = UIPackage.createObject(“包名“, ”组件A”) as MyComponent ;
注意:如果组件A只是一个普通的组件,没有定义“扩展”,那么基类是GComponent,如上例所示;如果组件A的扩展是按钮,那么MyComponent的基类应该为GButton,如果扩展是进度条,那么基类应该为GProgressBar,等等。这个不要弄错。

控制器Tween效果
动效的播放在代码中启动,例如:
someComponent.GetTransition(“peng”).Play();
Play有多种原型,例如可以重复播放一定次数,可以在播放结束时回调等。要中途停止动效的播放,可以调用:
someComponent.GetTransition(“peng”).Stop();
Stop方法也可以带参数,原型是
public void Stop(bool setToComplete, bool processCallback);
setToComplete表示是否将组件的状态设置到播放完成的状态,如果否,组件的状态就会停留在当前时间。processCallback是否调用Play设定的播放完成回调函数。

注意:UI动效播放完毕后,组件的状态将停留在最后一帧,而不是回到第一帧,如果你希望动效播放完后组件的状态复原到播放前,你可以最后添加一帧重新设置组件的状态。

高级用法:
public void SetValue(string label, params object[] aParams)
改变指定帧的数值,例如某帧Label为aa,这帧是设置某个元件的XY值的,那么调用setValue(aa, 100,200)就可以将原来此帧设置XY的数值改为100,200。
public void SetHook(string label, TransitionHook callback)
可以设定运行到某帧时发生一个调用。

多国语言支持
2、运行时动态加载语言文件。这种方法相对比较灵活。
Unity代码片段:
string fileContent; //自行载入语言文件,这里假设已载入到此变量
FairyGUI.Utils.XML xml = new FairyGUI.Utils.XML(fileContent);
UIPackage.SetStringsSource(xml);

(十二)UI适配策略 (分辨率 设置)
GRoot.inst.setContentScaleFactor(设计分辨率宽度,设计分辨率高度,适配策略);
someComponent.setSize(GRoot.inst.width, GRoot.inst.height);// 满屏

GRoot是FairyGUI的根组件,它的大小与屏幕分辨率的关系为
GRoot.inst.width = 屏幕宽度/GRoot.contentScaleFactor;
GRoot.inst.height = 屏幕高度/GRoot.contentScaleFactor;

(十三)显示架构API
FairyGUI在原生的渲染引擎上封装了一层显示对象结构。
基础类显示对象:
GObject:显示对象的基类。
GGraph:图形对象。对应于编辑器中显示的一个图形。
GImage:图片对象。对应于编辑器中显示的一个图片。
GMovieClip:动画对象。对应于编辑器中显示的一个动画。
GLoader:装载器对象。对应于编辑器中显示的一个装载器。
GTextField:文本对象。对应于编辑器中显示的一个文本。
GRichTextField:多媒体文本。对应于编辑器中显示的一个多媒体文本。
GTextInput:输入文本对象。对应于编辑器中显示的一个文本,且文本类型被设置为“输入”。
容器类显示对象:
GComponent:组件对象。对应于编辑器中创建的一个组件。
GList:列表对象。对应于编辑器中显示的一个列表。
容器的扩展:
GLabel:标签对象。当一个组件的扩展为“标签”时,即为此类型。
GButton:按钮对象。当一个组件的扩展为“按钮”时,即为此类型。
GComboBox:组合框对象。当一个组件的扩展为“组合框”时,即为此类型。
GScrollBar:滚动条对象。当一个组件的扩展为“滚动条”时,即为此类型。
GProgressBar:进度条对象。当一个组件的扩展为“进度条”时,即为此类型。
GSlider:滑动条对象。当一个组件的扩展为“滑动条”时,即为此类型。
FairyGUI和Flash/Cocos类似,采用树状的结构组织显示对象。容器可以包含一个或多个基础显示对象,也可以包含容器。这个树状结构称为显示列表。如下图:

处于最前面的且元件范围包含点击位置的元件将捕获鼠标或触摸事件,并且开始冒泡传递(请参考事件系统 Flash/Starling/Egret/Unity)
对于组件(GComponent),宽度x高度的范围内点击检测都是有效的,无论这个范围内是否有子元件。举个例子说明。组件A和组件B分别为:

将B先添加进舞台,然后再添加A到舞台,也就是说,A显示B的前面,效果如下图:

可以看到,虽然A在B的上面,但红色方块是可见的,因为A在此区域并没有内容。当点击图中绿色点的位置时,点击事件将在A上面触发,而B是点击不了的。这是因为在A的范围内,点击是不能穿透的。
如果希望A能被穿透应该怎样?可以通过GComponent.opaque属性设定。当设定为false时,这个组件将能被穿透。例如A.opaque=false,这时,只有点击4个白块时,A才接收到点击事件,如果点击绿色点位置,B将接收到点击事件。这个特性在设计一些全屏界面时尤其要注意。也可以在编辑器里直接设定:

滚动支持
你可以在编辑器里很方便的对一个组件添加滚动特性。如果一个组件在编辑器里设置为滚动,我们可以通过GComponent.scrollPane获得滚动控制对象。
ScrollPane提供了多个API访问和控制滚动:
ScrollPane.percX/ScrollPane.percY:获得或设置当前滚动的位置,以百分比来计算,取值范围是0-1。如果希望滚动条从当前值到设置值有一个动态变化的过程,可以使用ScrollPane.setPercX和ScrollPane.setPercY,这两个API提供了一个是否使用缓动的参数。
ScrollPane.posX/ScrollPane.posY:获得或设置当前滚动的位置,以像素来计算。取值范围决定于当前显示的内容大小与视口大小的差别。例如,一个垂直滚动的组件,如果视口大小为100像素,实际内容大小为300像素,那么posY的取值范围是0~200像素,当posY=200时,滚动条滚动到最下方。posX/posY与percX/percY不同在于,除非开发者自己设置或者用户拖动滚动条,percX/percY是不变的,举个例子,当前某滚动容器的percX=0.1, posX=100,如果往容器里添加一定内容后,内容的宽度增大,percX的值仍将保持不变,依然是0.1,但posX的值会发生相应的改变。所以如果希望容器内增删内容后滚动条不发生滚动,可以先记录posX/posY的位置,添加完之后再设置posX/posY为此前记录的位置。
ScrollPane.scrollToView:调整滚动位置,使指定的元件出现在视口内。
窗口系统
窗口使用前首先要设置窗口中需要显示的内容,这通常是在编辑器里制作好的,可以直接使用Window.contentPane进行设置。建议把设置contentPane等初始化操作放置到Window.onInit方法中。
另外,FairyGUI还提供了一套机制用于窗口动态创建。动态创建是指初始时仅指定窗口需要使用的资源,等窗口需要显示时才实际开始构建窗口的内容。首先需要在窗口的构造函数中调用Window.addUISource。这个方法需要一个IUISource类型的参数,而IUISource是一个接口,用户需要自行实现载入相关UI包的逻辑。当窗口第一次显示之前,IUISource的加载方法将会被调用,并等待载入完成后才返回执行Window.OnInit,然后窗口才会显示。
调用Window.show显示窗口的流程:

如果你需要窗口显示时播放动画效果,那么覆盖doShowAnimation编写你的动画代码,并且在动画结束后调用onShown。
覆盖onShown编写其他需要在窗口显示时处理的业务逻辑。
调用Window.hide隐藏窗口的流程:

如果你需要窗口隐藏时播放动画效果,那么覆盖doHideAnimation编写你的动画代码,并且在动画结束时调用Window.hideImmediately(注意不是直接调用onHide!)。
覆盖onHide编写其他需要在窗口隐藏时处理的业务逻辑。
通常窗口会包括一个可用于拖动的标题栏,关闭按钮等。我们在编辑器创建窗口组件时,可以为它创建一个名称为frame的组件,frame组件的扩展应该选择为“标签”,这样外部组件能够为其设置图标和标题属性。frame组件中约定的内容还包括:
closeButton:一个名称为closeButton的按钮将自动作为窗口的关闭按钮。
dragArea:一个名称为dragArea的图形(类型设置为空白)将自动作为窗口的检测拖动区域,当用户在此区域内按住并拖动时,窗口随之被拖动。
contentArea:一个名称为contentArea的图形(类型设置为空白)将作为窗口的主要内容区域,这个区域只用于Window.showModalWait。当调用Window.showModalWait时,窗口会被锁定,如果设定了contentArea,则只锁定contentArea指定的区域,否则锁定整个窗口。如果你希望窗口在modalWait状态下依然能够拖动和关闭,那么就不要让contentArea覆盖标题栏区域。
注意以上的约定均为可选,是否含有组件frame,或者组件frame里是否含有约定的功能组件,并不会影响窗口的正常显示和关闭。
Popup管理
在UI系统中我们经常需要一些弹出一些组件,这些组件在用户点击空白地方的情况下就会自动消失,又或者由开发者控制消失。GRoot提供了几个API管理这些Popup组件。
GRoot.showPopup:弹出一个组件,如果指定了目标,则会调整弹出的位置到目标的下方,形成一个下拉的效果。同时提供了参数可以用来指定是向上弹出或者向下弹出。
GRoot.hidePopup: 默认情况下,用户点击空白地方就会自动关闭弹出的组件。也可以调用此API手工关闭。不指定参数时,所有当前的弹出都关闭。
FairyGUI会根据组件的大小自动计算弹出位置,以确保组件显示不会超出屏幕。

(十五)事件系统:Unity
发表回复
Unity平台参考了Flash的事件机制,设计了自己独特的事件系统。EventDispatcher是事件分发的中心,GObject就是一个EventDispatcher。每个事件类型都对应一个EventListener,接收事件并调用处理函数。例如需要编写某个元件单击的处理逻辑:
aObject.onClick.Add(aCallback);
void aCallback()
{
//some logic
}
事件回调函数
每个事件可以注册一个或多个回调函数。函数原型为:
public delegate void EventCallback0();
public delegate void EventCallback1(EventContext context);
函数可以不带参数或带一个参数。
EventContext
EventContext是回调函数的参数类型。
EventContext.sender:获得事件的分发者。
EventContext.initiator:获得事件的发起者。一般来说,事件的分发者和发起者是相同的,但如果事件已发生冒泡,则可能不相同。参考下面冒泡的描述。
EventContext.type:事件类型。
EventContext.inputEvent:如果事件是键盘/触摸/鼠标事件,通过访问inputEvent对象可以获得这类事件的相关数据。
EventContext.data:事件的数据。根据事件不同,可以有不同的含义。
事件冒泡和事件捕获
一些特殊的事件,比如鼠标/触摸事件,具备向父组件传递的特性,这个传递过程叫做冒泡。例如当手指接触A元件时,A元件触发TouchBegin事件,然后A元件的父组件B触发TouchBegin事件,然后B的父组件C也触发TouchBegin事件,以此类推,直到舞台根部。这个设计保证了所有关联的显示对象都有机会处理触摸事件,而不只是最顶端的显示对象。
冒泡过程可以被打断,通过调用EventContext.StopPropagation()可以使冒泡停止向父组件推进。
从上面的冒泡过程可以看出,事件处理的顺序应该是:A’s listeners->B’s listeners->C’s listeners,这里还有一种机制可以让链路上任意一个对象可以提前处理事件,这就是事件捕获。事件捕获是反向的,例如在上面的例子中,就是C先捕获事件,然后是B,再到A。所以所有事件处理的完整顺序应该是:
C’s capture listeners->B’s capture listeners->A’s capture listeners->A’s listeners->B’s listeners->C’s listeners
捕获传递链是不能中止的,冒泡传递链可以通过StopPropagation中止。
事件捕获的设计可以使父元件优于子元件和孙子元件检查事件。
并非所有事件都有冒泡设计,请参考下面关于各个事件的说明。并非只有冒泡事件才有捕获设计。在非冒泡事件中,capture的回调优于普通回调,仅此而已,可以作为一个优先级特性来使用。
InputEvent
对键盘事件和鼠标/触摸事件,可以通过EventContext.inputEvent获得此类事件的相关数据。InputEvent.x/InputEvent.y:鼠标或手指的位置;这是舞台坐标,因为UI可能因为自适配发生了缩放,所以如果要转成UI元件中的坐标,要使用GObject.GlobalToLocal转换。
InputEvent.keyCode:按键代码;
InputEvent.modifiers:参考UnityEngine.EventModifiers。
InputEvent.mouseWheelDelta:鼠标滚轮滚动值。
InputEvent.touchId:拖动使用手指;在PC平台,该值为0,没有意义。
InputEvent.isDoubleClick:是否双击。
EventListener
EventListener.Add/EventListener.Remove:添加或删除一个回调,回调函数可以带一个参数或者不带参数。参数的类型是object,它的实际含义随不同事件不同而不同;
EventListener.AddCapture/EventListener.RemoveCapture:添加或删除一个捕获期回调。
事件类型
GObject.onClick:单击。冒泡事件。事件数据为InputEvent对象。
GObject.onRightClick:右键单击。冒泡事件。事件数据为InputEvent对象。
GObject.onTouchBegin:鼠标或手指按下。冒泡事件。事件数据为InputEvent对象。
GObject.onTouchEnd:鼠标或手指释放。冒泡事件。事件数据为InputEvent对象。
GObject.onRollOver:鼠标移入元件。事件数据为InputEvent对象。
GObject.onRollOut:鼠标移出元件。事件数据为InputEvent对象。
GObject.onAddedToStage:元件被添加到舞台。无事件数据。
GObject.onRemovedFromStage:元件从舞台移出。无事件数据。
GObject.onKeyDown:元件接收到按键事件。只有获得焦点的情况下才能接收按键事件。冒泡事件。事件数据为InputEvent对象。
GObject.onClickLink:文本中的链接被点击。事件数据为href值,字符串类型。
GObject.onPositionChanged:元件的位置改变。无事件数据。
GObject.onSizeChanged:元件的大小改变。无事件数据。
GObject.onDragStart/GObject.onDragEnd:拖动是指玩家按住元件拖动然后释放的过程。注意只有设置了GObject.draggable属性的元件才会触发拖动事件。拖动过程中可以获得两个通知:开始和结束。当onDragStart中,调用EventContext.PreventDefault()可以立刻取消拖动。无事件数据。
GTextField.onFocusIn/GTextField.onFocusOut:只有输入类型的文本才会触发这个事件。当输入文本获得焦点时,在移动设备上会弹出小键盘。无事件数据。
GTextField.onChanged:只有输入类型的文本才会触发这个事件。无事件数据。
GMovieClip.onPlayEnd:动画设定的播放次数已经播放完毕。无事件数据。
GList.onClickItem:当GList容器内的元件被点击时触发的事件类型;事件数据为当前点击的GObject对象。
GComponent.onScroll:如果容器是滚动类型容器,则滚动发生时产生该事件。
GComponent.onDrop:注意要和普通拖动区别,一个元件被拖动并释放后并不会触发Drop事件。Drop事件需配合DragDropManager使用。当DragDropManager拖动的图标在某个元件上释放时,这个元件就会触发onDrop。事件数据为DragDropManager.StartDrag中传递的source值。
GButton.onChanged:当单选或者多选按钮选中状态改变时会触发该事件(只有在用户点击后状态改变才会触发,如果是程序改变不会触发)。无事件数据。
GComboBox.onChanged:当用户从下拉列表中选择一项时触发该事件。无事件数据。
GSlider.onChanged:当用户拖动滑块改变Slider的值时触发该事件。无事件数据。
Controller.onChanged:当控制器页面改变会触发该事件(改变selectedIndex会触发该事件,setSelectedIndex则不会)。无事件数据。

(十八)在Unity项目中使用FairyGUI
1. 使用UIPanel
只需3步就可以使用将编辑器中制作好的界面放入到Unity的场景中。第一步,从GameObject菜单中选择FairyGUI->UIPanel:

第二步,在Inspector里点击PackageName或者ComponentName,将弹出选择组件的窗口:

第三步:这个窗口里列出了所有工程里能找到的UI包,选择一个包和组件,然后点击OK。

可以看到,UI组件的内容显示出来了。(注意:Unity4版本目前不支持显示内容,只能显示线框)
如果UI包修改了,或者其他一些情况导致UIPanel显示不正常,可以使用下面的菜单刷新:

当运行后,获得UIPanel的UI的方式是:
UIPanel panel = gameObject.GetComponent();
GComponent view = panel.ui;
与其他UIPackage.CreateObject创建出来的界面不同,UIPanel在GameObjec销毁时(手动销毁或者过场景等)时会一并销毁。
UIPane只保存了UI包的名称和组件的名称,它不对纹理或其他资源产生任何引用,也就是UI使用的资源不会包含在场景数据中。
在编辑状态下,无论UI组件引用了哪些UI包的资源,包括放置在Resources目录下的和不放置在Resources下的,都能够正确显示。但当运行后,UIPanel只能自动载入放置在Resources目录或其子目录下的UI包,也只会载入自身所在的UI包,其他情况的UI包(例如引用到的UI包或打包到AssetBundle的UI包)不能自动载入。你需要在UIPanel创建前使用UIPackage.AddPackage准备好这类UI包。UIPanel在Start事件或者第一次访问UIPanel.ui属性时创建UI界面,你仍然有机会在Awake里完成这些操作。
下面是UIPanel的一些属性说明:
Render Mode: 有三种:
Screen Space Overlay (默认值),表示这个UI在屏幕空间显示,这时Transform的Scale将被锁定,而且不建议修改Transform中的其他内容(让他们保持为0)。如果要修改面板在屏幕上的位置,使用UI Transform(参考下面关于UI Transform的说明)。
Screen Space Camera 表示这个UI在屏幕空间显示,但不使用FairyGUI默认的正交相机,而是使用指定的正交相机。
World Space 表示这个UI在世界空间显示,由透视相机渲染。默认的使用场景的主相机,如果不是,那么设置Render Camera。当使用这种模式时,使用Transfrom修改UI在世界空间中的位置、缩放、旋转。但你仍然可以使用UI Transform。
注意:Render Mode只定义了FairyGUI对待这个UI的方式,通常是坐标相关的操作(如点击检测等),但和渲染无关。UI由哪个相机渲染是由GameObject的layer决定的。所以如果发现UI没有显示出来,可以检查一下GameObject的layer是否正确。例如如果是Screen Space,GameObject应该在UI层,如果是WorldSpace,则是在Default层或者其他自定义的层次。
Render Camera:当Render Mode是Screen Space Camera或者World Space时可以设置。如果不设置,默认为场景的主相机。
Sorting Order:调整UIPanel的显示顺序。越大的显示在越前面。
Fairy Batching:是否启用Fairy Batching。关于Fairy Batching请参考下面的说明。切换这个值,可以在编辑模式下实时看到DrawCall的变化(切换后点击一下Game,Stat里显示的内容才会更新),这可以使你更加容易决定是否启用这项技术。
Touch Disabled:勾选后,将关闭点击检测。当这个UI没有可交互的内容时可以勾选以提高点击检测时的性能。例如头顶血条这些类型的UI,就可以勾选。
UI Transform:当Render Mode是Screen Space时可以使用这里的设置调整UI在屏幕上的位置。你仍然可以调整Transform改变UI的位置,但我不建议你这样做,因为Transform中的坐标位置是没有经过不同分辨率自适应的调整的。当Render Mode是World Space时,建议使用Transform设置UI的位置,你仍然可以调整UI Transform改变UI的位置,但调整的效果可能不那么直观。同时你可以使用Scene视图中下图所示的原点调整UI Transform的位置属性:

Fit Screen:这里可以设置UIPanel适配屏幕。
Fit Size:UI将铺满屏幕。
Fit Width And Set Middle:UI将横向铺满屏幕,然后上下居中。
Fit Height And Set Center:UI将纵向铺满屏幕,然后左右居中。
这里提供的选项不多,因为FairyGUI推荐的是在FairyGUI编辑器中整体设计,而不是在Unity里摆放小元件。例如如果需要不同的UI在屏幕上的各个位置布局,你应该在FairyGUI编辑器中创建一个全屏大小的组件,然后在里面放置各个子组件,再用关联控制布局;最后将这个全屏组件放置到Unity,将Fit Screen设置为Fit Size即可。错误的做法是把各个子组件放置到Unity里再布局。
HitTest Mode:这里可以设置UIPanel处理鼠标或触摸事件的方式。
Default: 这是默认的方式。FairyGUI会用内置的机制检测鼠标或触摸动作,不使用射线,UIPanel也不需要创建碰撞体,效能比较高。
Raycast: 在这种方式下,UIPanel将自动创建碰撞体,并且使用射线方式进行点击检测。这种方式适合于UIPanel还需要和其他3D对象互动的情况。
2. 动态载入UI界面
在很多情况下,你并不需要将UI界面放到场景中。使用代码载入编辑器制作好的界面也非常简单:
GComponent view = UIPackage.CreateObject(“包名”, “组件名”) as GComponent
动态载入的界面不会自动销毁,例如一个背包窗口,你并不需要在每次过场景都销毁。如果要销毁界面,调用Dispose方法即可,例如
view.Dispose();
也可以动态创建UIPanel为任意游戏对象挂接UI界面,方法为:
UIPanel panel = yourGameObject.AddComponent();
panel.packageName = “包名”;
panel.componentName = “组件名”;
panel.CreateUI();
UIPanel的生命周期将和yourGameObject保持一致。再次提醒,注意yourGameObject的layer。
3. 载入UI包
Unity项目载入UI包有以下几种方式,开发者可以根据项目需要选择其中一种或者多种混搭使用:
1)将打包后的文件直接发布到Unity的Resources目录或者其子目录下,

然后在代码中调用UIPackage.AddPackage(“demo”), demo就是发布时填写的文件名。如果在子目录下,调用UIPackage.AddPacakge(“路径/demo”)即可。
2)将发布后的文件打包为两个AssetBundle,即定义文件和资源各打包为一个bundle(desc_bundle+res_bundle)。这样做的好处是一般UI的更新都是修改元件位置什么的,不涉及图片资源的更新,那么只需要重新打包和推送desc_bundle就行了,不需要让玩家更新通常体积比较大的res_bouble,节省流量。打包程序由开发者按照自己熟悉的方式自行实现。以demo为例,请遵循以下规则打包:
a)demo.bytes单独打包为desc_bundle;
b)其他资源(demo@atlas0.png等),打包到res_bundle(在此例中就是atlas0和sprites)
然后在代码中调用UIPackage.AddPackage(desc_bundle, res_bundle)。bundle的载入由开发者自行实现。
3)将发布后的文件打包为一个AssetBundle。打包程序由开发者按照自己熟悉的方式自行实现。以demo为例,将demo.bytes和其他资源(demo@atlas0.png等),都放入bundle。然后在代码中调用UIPackage.AddPackage(bundle, bundle)。bundle的载入由开发者自行实现。
在使用AssetBundle的载入方案中,将由FairyGUI接管bundle并负责bundle资源的释放。
4. UI适配
可以通过两种方式设置UI自适应,第一种方式是在游戏的启动创建里任意对象挂一个FairyGUI/UIContentScaler组件:

这里选项的含义可以参考教程里关于UI适配的说明。
另外一种方式是通过代码,可以参考教程里关于UI适配的说明。
5.图集的处理
FairyGUI编辑器发布到Unity的资源通常包含一个或多个UI图集,以demo工程为例,这里demo@atlas0.png就是一个图集

图集是由UI编辑器自动生成的,但在Unity里可以改变图集的属性,常用的设置有:
1)Generate Mip Maps
不勾选。UI不使用Mip Maps功能。
2)Filter Mode
使用Bilinear,这样图像在缩放时能产生比较平滑的过渡效果,副作用是会产生一定的模糊。而且单色的图像缩放会产生不必要的渐变边缘。而使用Point,则图像在缩放时会块状化。

一般UI图集使用Bilinear即可。你也可以在UI编辑器里将图片安排到不同图集,然后每个图集设置不同的Filter Mode以满足特殊需求。
3)Max Size
一般设置到2048。
4)Format
UI图集一般都是PNG格式,并带有透明通道。同时,UI对画质的要求比较高,所以建议选择AutoMatic TrueColor。但TrueColor有一个最大的问题是文件大,而且占用内存较高,例如1024×1024的图集,将占用4MB的内存,2048×2048则达到16MB。
如果对内存使用比较敏感,也可以选用压缩格式,即AutoMatic Compressed。在桌面平台上即相同于DXT5,在Android平台上相当于ETC1,在IPhone平台则为PVRTC。这些格式能够大大降低内存占用,也因为它们是显卡直接支持的格式,所以Unity在载入时省去了解码位图的步骤,能够加快载入速度。但它们都是属于有损压缩,在显示质量上肯定不如TrueColor,特别是图集颜色十分丰富,或者有颜色渐变时,失真会比较厉害。特别重要的是,ETC1是不支持透明通道的,PVRTC对透明通道的支持也比较弱,所以并不适合带透明通道的图集。FairyGUI提供了ETC1/PVRTC+A的解决方案。首先,在发布时勾选“为Alpha通道创建单独的贴图”,如下图:

这样,就产生了两个不含透明通道的贴图,一张去除了原图透明通道的贴图,和一张将原贴图透明通道数值转换为等价灰度的贴图。这两张贴图都可以设置为Automatic Compressed。(一定要注意,不能再将主贴图设置为True Color)

FairyGUI提供了特制的着色器处理两张贴图的合并。开发者并不需要编写额外的代码就可以使用这项技术。
TIPS
你可以将本身就不含透明通道的位图(例如一些大型的背景图)安排到一张图集上。如果一张图集内的所有图片都不包含透明通道,那么最终输出的图集也不包含透明通道。不含透明通道的图集可以选用Automatic 16bits格式。
6. 字体的处理
FairyGUI使用Unity的动态字体技术渲染文字。只需以下几个简单的步骤就可以完成设置:
1)拷贝一个字体文件到项目的Resources目录或Resources/Fonts目录。字体文件可以随意使用一个,例如arial.ttf,或simhei.ttf等,这个ttf是什么字体并不影响最终显示字体的选择。
2)在Unity中点击字体文件,在inspector中修改字体属性

注意在Font Names中填写的是字体名称,标准的字体名称可以从这里找到: 中文字体的英文名称对照表。例如Droid Sans Fallback是Android平台支持中文的内置默认字体之一。多个字体用逗号隔开,Unity会使用第一个在系统中能找到的字体。
3)设置UIConfig.defaultFont=”字体文件名称”即可,注意这里使用的是文件名称,也就是说,如果放置在Resources目录的是arial.ttf,则UIConfig.defaultFont=”arial”,不需要带.ttf后缀。
因为我们没有勾选Include Font Data,所以无论这个字体文件有多大,最终并不会包含在我们的发布包中,也就是说不会增大发行包的体积。Unity会在实际运行的系统中查找与Font Names匹配的第一个字体,并使用此字体进行动态渲染。
如果你是在Unity5.x平台开发,除了上述方式外,得益于Unity5.x引入的新的字体管理API,也可以不放置字体文件到Resources目录,你只需要直接设置UIConfig.defaultFont=”字体名称“即可,同样,多个字体名称用逗号隔开。例如:UIConfig.defaultFont=”Droid Sans Fallback, LTHYSZK, Helvetica-Bold, Microsoft YaHei, SimHei”;
4)如果你的界面使用了多种字体,比如对单独的文字设置了字体:

这里用到了“黑体”这个名字的字体,这是与UIConfig.defaultFont里设置的不同的字体,我们也需要注册这种字体。方法是,首先做好上面1)和2),假如字体文件名称是HeiTi.ttf,然后
FontManager.RegisterFont(“黑体”, FontManager.GetFont(“HeiTi”));
RegisterFont的第一个参数对应编辑器里使用的字体名称;第二个参数,是Unity中放入的字体文件资源。如果文件带路径,这也需要把路径填上。
5)当你使用部分字体的粗体效果时,你会发现粗体的效果在Unity中的显示不正确,这是因为有些字体不带粗体效果的,这时候Unity就会用拉宽来实现,就像变扁了。fairygui可以用额外的mesh来解决粗体的显示。方法是:
FontManager.GetFont(“字体路径”).customFold = true;
这里字体路径与UIConfig.default里设置的内容应该完全一样。
6)某些字体,unity渲染有粗体效果,但当设置成斜体时,粗体效果又丢失(例如雅黑)。fairygui在这种情况取消unity默认渲染粗体的效果,改为增加额外的面渲染粗体。激活这个功能的方法是
FontManager.GetFont(“字体路径”).customBoldAndItalic = true;
如果已经设置了customBold,不需要再设置customBoldAndItalic。
备注1
动态字体要求玩家的运行系统环境中有你设定的字体,如果没有,实际使用的字体可能并不是你想要的效果。因此,你可以选择嵌入整个字体文件。方法是把你要用的字体文件放到Resources目录,并把Include Font Data勾选,这样整个字体文件就会包含到最终的发布包中,坏处就是会大大增加发行包的体积。
备注2
在实际游戏制作过程中发现在桌面平台下Unity对中文字体的渲染稍显模糊和暗淡,因此FairyGUI使用了特制的着色器解决了这个问题。以下是Unity默认的字体渲染效果和FairyGUI的字体渲染效果的比较:

可以看见经过FairyGUI的特殊处理,中文文字更清晰更亮。
只有在桌面平台下FairyGUI才会开启这种技术,移动平台永远不会开启,因为在高DPI情况下,字体默认的渲染效果已经非常漂亮。
另外,如果你不喜欢这种显示效果,或者你使用的是全英文的文字,也可以手动把这种技术关闭:UIConfig.renderingTextBrighterOnDesktop = false;
7 在UI中穿插其他3D对象
FairyGUI底层使用Renderer.sortingOrder来决定对象的渲染顺序,利用这个特性,我们可以很容易的将UI对象与其他3D对象(例如例子)安排在一起。FairyGUI提供了封装类GoWrapper,可以直接包装其他GameObject插入到UI层次中。如下图,一个粒子特效被安排到了UI之间。

又例如,一个3D模型穿插在UI中间

详细实现方法可以参考FairyGUI-unity包中的Assets/FairyGUI/Examples/Particles和Assets/FairyGUI/Examples/Model。
8. 与RenderTexture配合
在UI上展现3D内容的另一种方式是使用RenderTexture,特别是需要进行剪裁的情况下(如果不需要剪裁,推荐直接放置3D内容,免除RenderTexture性能消耗。参考6. 在UI中穿插其他3D对象)。在FairyGUI中,可以将Image.texture设置为一个RenderTexture,然后就可以像使用普通图片一样使用这个RenderTexture了,可以出现在任何地方,包括滚动容器。特别地,FairyGUI还能支持将RenderTexture所在位置的背景图片影射到RenderTexture渲染相机的背景上,这样就不用担心透贴的问题了。如下图,NPC使用RenderTexture渲染到UI窗口中。

详细实现方法可以参考FairyGUI-unity包中的Assets/FairyGUI/Examples/RenderTexture。
9. Drawcall优化
在Unity中,每次引擎准备数据并通知GPU的过程称为一次Draw Call(DC)。Draw Call次数是一项非常重要的性能指标。UI系统一般包含数量众多的物体,有效控制DC是衡量一个UI系统是否实用的关键因素,特别是在移动设备上。
我们先来看看NGUI是怎么做的,NGUI把UIPanel中的Widget按depth排序,然后将相同材质的Widget进行Mesh合并,例如使用相同图集的图片,或者文字。Mesh合并的优点是合并后这些Widget就只产生一个DC。但这个合并过程需要计算所有Widget坐标相对于Panel的变换,而且如果Widget行为改变,例如平移,缩放等,都会触发Mesh重新合并,这会带来一定的CPU消耗,这就需要开发者谨慎组织UI元素到各个UIPanel,并且对深度需要细致安排,否则达不到减少DC效果的同时更可能带来比较大的CPU消耗。
FairyGUI没有采取合并Mesh的策略,原因有两个:
● FairyGUI使用的是树状显示对象结构,各个元件之间的层次关系非常复杂;
● FairyGUI编辑器给予用户最大的设计自由度,加上动效的引入,各个元件的状态都可能非常动态;
FairyGUI基于Unity的Dynamic Batching技术,提供了深度调整技术进行 drawcall优化 。FairyGUI能在不改变最终显示效果的前提下,尽可能的把相同材质的物体调整到连续的renderingOrder值上,以促使他们能够被Unity Dynamic Batching优化。Dynamic Batching是Unity提供的Draw Call Batching技术之一。如果动态物体共用着相同的材质,那么Unity会自动对这些物体进行批处理。但Dynamic Batching的一个重要的前提是这些动态物体是连续渲染的。先来看看FairyGUI中物体的渲染顺序,例如:

这里有4个按钮,每个按钮都是一个组件,每个组件里包含一个图片和一个文字对象。FairyGUI是树状的显示对象结构,那么他们按深度排序应该是:

因为文字和图片的材质并不相同,所以每次从文字到图片都产生上下文切换,所以产生了6个DC。
FairyGUI的深度调整技术可以优化这种情况。观察一下,其实四个按钮之间并不相交,所以FairyGUI智能地将渲染顺序调整为:

因为FairyGUI使用了图集,而且动态文字也使用了相同的贴图,这样,DC就降低到了2个,达到了优化的目的。实际情况会比这个复杂很多,但FairyGUI能在不改变最终显示效果的前提下,尽可能的把相同材质的物体调整到连续的renderingOrder值上,以促使他们能够被Unity Dynamic Batching优化。而对开发者来说,这些底层上的调整是透明的,也就是不会影响原来的显示对象层次。从效率上考虑,这种技术仅比较物体之间的显示矩形区域(一个Rect)是否相交,所以速度是非常快的,不会带来过多的CPU负荷。
FairyGUI提供了一个开关控制组件是否启用深度调整,API是:
GComponent someComponent;
someComponent.fairyBatching = true;
如果某个组件设置了fairyBatching,那么无需在子组件和孙子组件再启用fairyBatching。一般只在顶层组件打开这个功能,例如主界面,加载界面等。注意,Window这个类已经自动打开了fairyBatching,这符合我们的使用习惯,因为一般我们都是以窗口为单位安排功能的。如果界面不复杂,Draw Call本来就不高的情况下,开发者也可以忽略这个功能,从10个DC优化到8个DC并没有什么意义。在实际使用过程中,
对于打开了fairyBatching的组件,当开发者动态改变子元件或者孙子元件的位置或大小时,并不会自动触发深度调整,例如一个图片原来显示在一个窗口里的顶层,你用Tween将它从原来的位置移到另外一个位置,这个图片就有可能被窗口里的其他元素遮挡。这时开发者可以手动触发深度调整,API是
someObject.InvalidateBatchingState();
这个API并不需要由开启了fairyBatching的组件调用,它可以用任何一个内含的元件发起。对于UI动效(Transitions),FairyGUI已经自动调用了这个API,所以开发者不必处理。
下载并运行Demo,可以观察fairyBatching的实际效果。例如这个Demo的首页:

设置了fairyBatching后由42个DC减少到了6个DC,另外,可以看到Saved by batching: 27的字样。

与ULUA配合
一、安装
1、将以下语句添加到Assets\uLua\Editor\WrapFile.cs适当的位置,然后调用Lua的菜单Gen Lua Wrap Files,重新生成绑定文件。
_GT(typeof(EventContext)),
_GT(typeof(EventDispatcher)),
_GT(typeof(EventListener)),
_GT(typeof(InputEvent)),
_GT(typeof(DisplayObject)),
_GT(typeof(Container)),
_GT(typeof(Stage)),
_GT(typeof(Controller)),
_GT(typeof(GObject)),
_GT(typeof(GGraph)),
_GT(typeof(GGroup)),
_GT(typeof(GImage)),
_GT(typeof(GLoader)),
_GT(typeof(PlayState)),
_GT(typeof(GMovieClip)),
_GT(typeof(TextFormat)),
_GT(typeof(GTextField)),
_GT(typeof(GRichTextField)),
_GT(typeof(GTextInput)),
_GT(typeof(GComponent)),
_GT(typeof(GList)),
_GT(typeof(GRoot)),
_GT(typeof(GLabel)),
_GT(typeof(GButton)),
_GT(typeof(GComboBox)),
_GT(typeof(GProgressBar)),
_GT(typeof(GSlider)),
_GT(typeof(PopupMenu)),
_GT(typeof(ScrollPane)),
_GT(typeof(Transition)),
_GT(typeof(UIPackage)),
_GT(typeof(Window)),
_GT(typeof(GObjectPool)),
_GT(typeof(Relations)),
_GT(typeof(RelationType)),
2、拷贝FairyGUI.lua到你的lua文件存放目录。
二、使用
1、普通方法的侦听和删除侦听
require ‘FairyGUI’
function OnClick() –也可以带上事件参数,OnClick(context)
print(‘you click’)
end
UIPackage.AddPackage(‘Demo’)
local view = UIPackage.CreateObject(‘Demo’, ‘DemoMain’)
GRoot.inst:AddChild(view)
view.onClick:Add(OnClick)
–view.onClick:Remove(OnClick)
2、类方法的侦听和删除侦听
require ‘FairyGUI’
TestClass = class(‘TestClass’, {})
function TestClass:ctor()
UIPackage.AddPackage(‘Demo’)
self.view = UIPackage.CreateObject(‘Demo’, ‘DemoMain’)
GRoot.inst:AddChild(self.view)
self.view.onClick:Add(TestClass.OnClick, self)
–self.view.onClick:Remove(TestClass.OnClick, self)
end
function TestClass:OnClick() –也可以带上事件参数,TestClass:OnClick(context)
print(‘you click’)
end
TestClass.New()
3、如果要使用Tween,你可以直接使用GObject.TweenXXXX系列函数,免除了Wrap DOTween的麻烦。

Unity3D占用内存太大的解决方法[转]

Unity3D 里有两种动态加载机制:一个是Resources.Load,另外一个通过AssetBundle,其实两者区别不大。 Resources.Load就是从一个缺省打进程序包里的AssetBundle里加载资源,而一般AssetBundle文件需要你自己创建,运行时 动态加载,可以指定路径和来源的。

其实场景里所有静态的对象也有这么一个加载过程,只是Unity3D后台替你自动完成了。

详细说一下细节概念:
AssetBundle运行时加载:
来自文件就用CreateFromFile(注意这种方法只能用于standalone程序)这是最快的加载方法
也可以来自Memory,用CreateFromMemory(byte[]),这个byte[]可以来自文件读取的缓冲,www的下载或者其他可能的方式。
其实WWW的assetBundle就是内部数据读取完后自动创建了一个assetBundle而已
Create完以后,等于把硬盘或者网络的一个文件读到内存一个区域,这时候只是个AssetBundle内存镜像数据块,还没有Assets的概念。
Assets加载:
用AssetBundle.Load(同Resources.Load) 这才会从AssetBundle的内存镜像里读取并创建一个Asset对象,创建Asset对象同时也会分配相应内存用于存放(反序列化)
异步读取用AssetBundle.LoadAsync
也可以一次读取多个用AssetBundle.LoadAll
AssetBundle的释放:
AssetBundle.Unload(flase)是释放AssetBundle文件的内存镜像,不包含Load创建的Asset内存对象。
AssetBundle.Unload(true)是释放那个AssetBundle文件内存镜像和并销毁所有用Load创建的Asset内存对象。

一个Prefab从assetBundle里Load出来 里面可能包括:Gameobject transform mesh texture material shader script和各种其他Assets。
你 Instaniate一个Prefab,是一个对Assets进行Clone(复制)+引用结合的过程,GameObject transform 是Clone是新生成的。其他mesh / texture / material / shader 等,这其中些是纯引用的关系的,包括:Texture和TerrainData,还有引用和复制同时存在的,包括:Mesh/material /PhysicMaterial。引用的Asset对象不会被复制,只是一个简单的指针指向已经Load的Asset对象。这种含糊的引用加克隆的混合, 大概是搞糊涂大多数人的主要原因。
专门要提一下的是一个特殊的东西:Script Asset,看起来很奇怪,Unity里每个Script都是一个封闭的Class定义而已,并没有写调用代码,光Class的定义脚本是不会工作的。其 实Unity引擎就是那个调用代码,Clone一个script asset等于new一个class实例,实例才会完成工作。把他挂到Unity主线程的调用链里去,Class实例里的OnUpdate OnStart等才会被执行。多个物体挂同一个脚本,其实就是在多个物体上挂了那个脚本类的多个实例而已,这样就好理解了。在new class这个过程中,数据区是复制的,代码区是共享的,算是一种特殊的复制+引用关系。
你可以再Instaniate一个同样的Prefab,还是这套mesh/texture/material/shader…,这时候会有新的GameObject等,但是不会创建新的引用对象比如Texture.
所以你Load出来的Assets其实就是个数据源,用于生成新对象或者被引用,生成的过程可能是复制(clone)也可能是引用(指针)
当你Destroy一个实例时,只是释放那些Clone对象,并不会释放引用对象和Clone的数据源对象,Destroy并不知道是否还有别的object在引用那些对象。
等到没有任何 游戏场景物体在用这些Assets以后,这些assets就成了没有引用的游离数据块了,是UnusedAssets了,这时候就可以通过 Resources.UnloadUnusedAssets来释放,Destroy不能完成这个任 务,AssetBundle.Unload(false)也不行,AssetBundle.Unload(true)可以但不安全,除非你很清楚没有任何 对象在用这些Assets了。
配个图加深理解:

Unity3D占用内存太大怎么解决呢?

虽然都叫Asset,但复制的和引用的是不一样的,这点被Unity的暗黑技术细节掩盖了,需要自己去理解。

关于内存管理
按照传统的编程思维,最好的方法是:自己维护所有对象,用一个Queue来保存所有object,不用时该Destory的,该Unload的自己处理。
但这样在C# .net框架底下有点没必要,而且很麻烦。
稳妥起见你可以这样管理

创建时:
先建立一个AssetBundle,无论是从www还是文件还是memory
用AssetBundle.load加载需要的asset
加载完后立即AssetBundle.Unload(false),释放AssetBundle文件本身的内存镜像,但不销毁加载的Asset对象。(这样你不用保存AssetBundle的引用并且可以立即释放一部分内存)
释放时:
如果有Instantiate的对象,用Destroy进行销毁
在合适的地方调用Resources.UnloadUnusedAssets,释放已经没有引用的Asset.
如果需要立即释放内存加上GC.Collect(),否则内存未必会立即被释放,有时候可能导致内存占用过多而引发异常。
这样可以保证内存始终被及时释放,占用量最少。也不需要对每个加载的对象进行引用。

当然这并不是唯一的方法,只要遵循加载和释放的原理,任何做法都是可以的。

系统在加载新场景时,所有的内存对象都会被自动销毁,包括你用AssetBundle.Load加载的对象和Instaniate克隆的。但是不包括AssetBundle文件自身的内存镜像,那个必须要用Unload来释放,用.net的术语,这种数据缓存是非托管的。

总结一下各种加载和初始化的用法:
AssetBundle.CreateFrom…..:创建一个AssetBundle内存镜像,注意同一个assetBundle文件在没有Unload之前不能再次被使用
WWW.AssetBundle:同上,当然要先new一个再 yield return 然后才能使用
AssetBundle.Load(name): 从AssetBundle读取一个指定名称的Asset并生成Asset内存对象,如果多次Load同名对象,除第一次外都只会返回已经生成的Asset 对象,也就是说多次Load一个Asset并不会生成多个副本(singleton)。
Resources.Load(path&name):同上,只是从默认的位置加载。
Instantiate(object):Clone 一个object的完整结构,包括其所有Component和子物体(详见官方文档),浅Copy,并不复制所有引用类型。有个特别用法,虽然很少这样 用,其实可以用Instantiate来完整的拷贝一个引用类型的Asset,比如Texture等,要拷贝的Texture必须类型设置为 Read/Write able。

总结一下各种释放
Destroy: 主要用于销毁克隆对象,也可以用于场景内的静态物体,不会自动释放该对象的所有引用。虽然也可以用于Asset,但是概念不一样要小心,如果用于销毁从文 件加载的Asset对象会销毁相应的资源文件!但是如果销毁的Asset是Copy的或者用脚本动态生成的,只会销毁内存对象。
AssetBundle.Unload(false):释放AssetBundle文件内存镜像
AssetBundle.Unload(true):释放AssetBundle文件内存镜像同时销毁所有已经Load的Assets内存对象
Reources.UnloadAsset(Object):显式的释放已加载的Asset对象,只能卸载磁盘文件加载的Asset对象
Resources.UnloadUnusedAssets:用于释放所有没有引用的Asset对象
GC.Collect()强制垃圾收集器立即释放内存 Unity的GC功能不算好,没把握的时候就强制调用一下

在3.5.2之前好像Unity不能显式的释放Asset

举两个例子帮助理解
例子1:
一个常见的错误:你从某个AssetBundle里Load了一个prefab并克隆之:obj = Instaniate(AssetBundle1.Load(‘MyPrefab”);
这个prefab比如是个npc
然后你不需要他的时候你用了:Destroy(obj);你以为就释放干净了
其实这时候只是释放了Clone对象,通过Load加载的所有引用、非引用Assets对象全都静静静的躺在内存里。
这种情况应该在Destroy以后用:AssetBundle1.Unload(true),彻底释放干净。
如果这个AssetBundle1是要反复读取的 不方便Unload,那可以在Destroy以后用:Resources.UnloadUnusedAssets()把所有和这个npc有关的Asset都销毁。
当然如果这个NPC也是要频繁创建 销毁的 那就应该让那些Assets呆在内存里以加速游戏体验。
由此可以解释另一个之前有人提过的话题:为什么第一次Instaniate 一个Prefab的时候都会卡一下,因为在你第一次Instaniate之前,相应的Asset对象还没有被创建,要加载系统内置的 AssetBundle并创建Assets,第一次以后你虽然Destroy了,但Prefab的Assets对象都还在内存里,所以就很快了。

顺便提一下几种加载方式的区别:
其实存在3种加载方式:
一是静态引用,建一个public的变量,在Inspector里把prefab拉上去,用的时候instantiate
二是Resource.Load,Load以后instantiate
三是AssetBundle.Load,Load以后instantiate
三种方式有细 节差异,前两种方式,引用对象texture是在instantiate时加载,而assetBundle.Load会把perfab的全部assets 都加载,instantiate时只是生成Clone。所以前两种方式,除非你提前加载相关引用对象,否则第一次instantiate时会包含加载引用 assets的操作,导致第一次加载的lag。

例子2:
从磁盘读取一个1.unity3d文件到内存并建立一个AssetBundle1对象
AssetBundle AssetBundle1 = AssetBundle.CreateFromFile(“1.unity3d”);
从AssetBundle1里读取并创建一个Texture Asset,把obj1的主贴图指向它
obj1.renderer.material.mainTexture = AssetBundle1.Load(“wall”) as Texture;
把obj2的主贴图也指向同一个Texture Asset
obj2.renderer.material.mainTexture =obj1.renderer.material.mainTexture;
Texture是引用对象,永远不会有自动复制的情况出现(除非你真需要,用代码自己实现copy),只会是创建和添加引用
如果继续:
AssetBundle1.Unload(true) 那obj1和obj2都变成黑的了,因为指向的Texture Asset没了
如果:
AssetBundle1.Unload(false) 那obj1和obj2不变,只是AssetBundle1的内存镜像释放了
继续:
Destroy(obj1),//obj1被释放,但并不会释放刚才Load的Texture
如果这时候:
Resources.UnloadUnusedAssets();
不会有任何内存释放 因为Texture asset还被obj2用着
如果
Destroy(obj2)
obj2被释放,但也不会释放刚才Load的Texture
继续
Resources.UnloadUnusedAssets();
这时候刚才load的Texture Asset释放了,因为没有任何引用了
最后CG.Collect();
强制立即释放内存
由此可以引申出论坛里另一个被提了几次的问题,如何加载一堆大图片轮流显示又不爆掉
不考虑AssetBundle,直接用www读图片文件的话等于是直接创建了一个Texture Asset
假设文件保存在一个List里
TLlist<string> fileList;
int n=0;
IEnumerator OnClick()
{
WWW image = new www(fileList[n++]);
yield return image;
obj.mainTexture = image.texture;

n = (n>=fileList.Length-1)?0:n;
Resources.UnloadUnusedAssets();
}
这样可以保证内存里始终只有一个巨型Texture Asset资源,也不用代码追踪上一个加载的Texture Asset,但是速度比较慢
或者:
IEnumerator OnClick()
{
WWW image = new www(fileList[n++]);
yield return image;
Texture tex = obj.mainTexture;
obj.mainTexture = image.texture;

n = (n>=fileList.Length-1)?0:n;
Resources.UnloadAsset(tex);
}
这样卸载比较快

 

 

Hog的评论引用:

感觉这是Unity内存管理暗黑和混乱的地方,特别是牵扯到Texture
我最近也一直在测试这些用AssetBundle加载的asset一样可以用Resources.UnloadUnusedAssets卸载,但必须先AssetBundle.Unload,才会被识别为无用的asset。比较保险的做法是
创建时:
先建立一个AssetBundle,无论是从www还是文件还是memory
用AssetBundle.load加载需要的asset
用完后立即AssetBundle.Unload(false),关闭AssetBundle但不摧毁创建的对象和引用
销毁时:
对Instantiate的对象进行Destroy
在合适的地方调用Resources.UnloadUnusedAssets,释放已经没有引用的Asset.
如果需要立即释放加上GC.Collect()
这样可以保证内存始终被及时释放
只要你Unload过的AssetBundle,那些创建的对象和引用都会在LoadLevel时被自动释放。

 

全面理解Unity加载和内存管理机制之二:进一步深入和细节
Unity几种动态加载Prefab方式的差异:
其实存在3种加载prefab的方式:
一是静态引用,建一个public的变量,在Inspector里把prefab拉上去,用的时候instantiate
二是Resource.Load,Load以后instantiate
三是AssetBundle.Load,Load以后instantiate
三种方式有细节差异,前两种方式,引用对象texture是在instantiate时加载,而assetBundle.Load会把perfab的全部 assets都加载,instantiate时只是生成Clone。所以前两种方式,除非你提前加载相关引用对象,否则第一次instantiate时会 包含加载引用类assets的操作,导致第一次加载的lag。官方论坛有人说Resources.Load和静态引用是会把所有资源都预先加载的,反复测试的结果,静态引用和Resources.Load也是OnDemand的,用到时才会加载。

几种AssetBundle创建方式的差异:
CreateFromFile:这种方式不会把整个硬盘AssetBundle文件都加载到 内存来,而是类似建立一个文件操作句柄和缓冲区,需要时才实时Load,所以这种加载方式是最节省资源的,基本上AssetBundle本身不占什么内 存,只需要Asset对象的内存。可惜只能在PC/Mac Standalone程序中使用。
CreateFromMemory和www.assetBundle:这两种方式AssetBundle文件会整个镜像于内存中,理论上文件多大就需要多大的内存,之后Load时还要占用额外内存去生成Asset对象。

什么时候才是UnusedAssets?
看一个例子:
Object obj = Resources.Load(“MyPrefab”);
GameObject instance = Instantiate(obj) as GameObject;
………
Destroy(instance);
创建随后销毁了一个Prefab实例,这时候 MyPrefab已经没有被实际的物体引用了,但如果这时:
Resources.UnloadUnusedAssets();
内存并没有被释放,原因:MyPrefab还被这个变量obj所引用
这时候:
obj  = null;
Resources.UnloadUnusedAssets();
这样才能真正释放Assets对象
所以:UnusedAssets不但要没有被实际物体引用,也要没有被生命周期内的变量所引用,才可以理解为 Unused(引用计数为0)
所以所以:如果你用个全局变量保存你Load的Assets,又没有显式的设为null,那 在这个变量失效前你无论如何UnloadUnusedAssets也释放不了那些Assets的。如果你这些Assets又不是从磁盘加载的,那除了 UnloadUnusedAssets或者加载新场景以外没有其他方式可以卸载之。

一个复杂的例子,代码很丑陋实际也不可能这样做,只是为了加深理解

IEnumerator OnClick()

{

Resources.UnloadUnusedAssets();//清干净以免影响测试效果

yield return new WaitForSeconds(3);

float wait = 0.5f;

//用www读取一个assetBundle,里面是一个Unity基本球体和带一张大贴图的材质,是一个Prefab

WWW aa = new WWW(@”file://SpherePrefab.unity3d”);

yield return aa;

AssetBundle asset = aa.assetBundle;

yield return new WaitForSeconds(wait);//每步都等待0.5s以便于分析结果

Texture tt = asset.Load(“BallTexture”) as  Texture;//加载贴图

yield return new WaitForSeconds(wait);

GameObject ba = asset.Load(“SpherePrefab”) as  GameObject;//加载Prefab

yield return new WaitForSeconds(wait);

GameObject obj1 = Instantiate(ba) as GameObject;//生成实例

yield return new WaitForSeconds(wait);

Destroy(obj1);//销毁实例

yield return new WaitForSeconds(wait);

asset.Unload(false);//卸载Assetbundle

yield return new WaitForSeconds(wait);

Resources.UnloadUnusedAssets();//卸载无用资源

yield return new WaitForSeconds(wait);

ba = null;//将prefab引用置为空以后卸无用载资源

Resources.UnloadUnusedAssets();

yield return new WaitForSeconds(wait);

tt = null;//将texture引用置为空以后卸载无用资源

Resources.UnloadUnusedAssets();

}

这是测试结果的内存Profile曲线图

Unity3D占用内存太大怎么解决呢?

图片:p12.jpg

很经典的对称造型,用多少释放多少。

这是各阶段的内存和其他数据变化

说明:
1        初始状态
2        载入AssetBundle文件后,内存多了文件镜像,用量上升,Total Object和Assets增加1(AssetBundle也是object)
3        载入Texture后,内存继续上升,因为多了Texture Asset,Total Objects和Assets增加1
4        载入Prefab后,内存无明显变化,因为最占内存的Texture已经加载,Materials上升是因为多了Prefab的材质,Total Objects和Assets增加6,因为 Perfab 包含很多 Components
5        实例化Prefab以后,显存的Texture Memory、GameObjectTotal、Objects in Scene上升,都是因为实例化了一个可视的对象
6        销毁实例后,上一步的变化还原,很好理解
7        卸载AssetBundle文件后,AssetBundle文件镜像占用的内存被释放,相应的Assets和Total Objects Count也减1
8        直接Resources.UnloadUnusedAssets,没有任何变化,因为所有Assets引用并没有清空
9        把Prefab引用变量设为null以后,整个Prefab除了Texture外都没有任何引用了,所以被UnloadUnusedAssets销毁,Assets和Total Objects Count减6
10        再把Texture的引用变量设为null,之后也被UnloadUnusedAssets销毁,内存被释放,assets和Total Objects Count减1,基本还原到初始状态

从中也可以看出:
Texture加载以后是到内存,显示的时候才进入显存的Texture Memory。
所有的东西基础都是Object
Load的是Asset,Instantiate的是GameObject和Object in Scene
Load的Asset要Unload,new的或者Instantiate的object可以Destroy

原文地址