FairyGUI和NGUI对比

一直在做Unity方面的游戏开发,经同事介绍了解到有这么一个GUI能提供跨平台的能力,有独立UI编辑器,而且功能强大,能够组合成复杂的UI界面,可以导出到Unity,Flash,Starling等,文档还说未来将支持UE4,Cocos2d-x,libgdx等。

做过Unity的同学都知道,Unity4.6以前的版本原生GUI运行效率是非常低的,在移动设备上基本被卡的嗷嗷的,4.6版本之后Unity开发了一套新的GUI,据说运行效率大大提升,非常好用,大有取代NGUI的意思,而且听说Unity的新版UI系统曾经hire过NGUI的作者,很多观点都和NGUI类似。在没有新版原生UI系统时大部分都用NGUI,可想而知NGUI的影响力。NGUI提供了多种控件和灵活的UI处理方式,但是NGUI也有明显缺点。

1.NGUI需要维护图集,做过项目的同学都知道,图集处理不好会造成资源的重复浪费,就是说要把UI图片预先打成包,以便界面使用,但是在实际项目中改动如果太过频繁,有些根本用不到的图片也不知道有没有用过,删了又担心造成资源丢失的情况,除非对这一块特别熟悉的人,一般人都不敢乱删图片资源。就算图集里面都是有用的资源,但是也会出现这样一种情况:同学1在Atlas A里面增加了一个图片P1运用到某个界面中,同学2不知道Atlas A里面新增了P1,于是他在Atlas B里面又增加了P1运用到另一个界面中,这时Atlas A和Atlas B里面就都包含有图P1,造成了浪费,不过这点浪费这时看可以忽略不计,但是假如图片P1需要更新,这时灾难来了,由于多个Atlas用到了P1,根本不知道要更新哪一个Atlas.而且只要增加图片或者更新图片都需要更新图集,维护起来比较麻烦。

2.NGUI的消息响应机制是利用sendmessage来实现,而sendmessage利用反射机制,本身NGUI组件的身上已经挂了很多默认组件,在运行时就需要先load这些映射关系,先缓存起来,调用的时候在通过安全检查,字符串匹配,参数匹配与转换,最后才去invoke方法。如果在项目开发中又新加一些自定义组件并定义了NGUI事件方法,对运行时的效率就会产生一些影响,反射这个不一定不好,要分具体情况,需要结合实际场景自行判断。

而对于FairyGUI,在图集方面相对好一点,它提供独立的UI编辑器,每个Atlas可以对应一个包也可以对应多个包,包里面的资源可以共用,不会因为包A里面的某资源更新了包B里面的资源没有更新,因为两个包之间可以共用资源,更新一个都可更新。同样,可以自行设置对应的Atlas. 
它的优点是UI独立出来了,可以自行组装,然后发布到需要的平台,然后对应的平台可以写独立的逻辑,实现了分层结构。而且UI编辑器功能强大,一般的效果基本都能满足。 
缺点是只能在UI编辑器里面制作动画,支持的动画工具比较少,导入到Unity里面运行时UI才能看到,不够直观并且无法修改,运行时的UI目录结构会跟在UI编辑器里面的目录结构不一致。 
优点可能也是缺点,缺点也可能是优点,对于拼UI的工作,由于提供了UI编辑器,完全可以由专门的美术来完成UI的拼接,但是沟通成本可能会比较大,因为涉及到功能编写,UI编辑器里面的节点命名和层次结构就需要程序和美术提前约定好。而由于在运行时才会有UI,程序猿在编写UI逻辑时不需要关心到底UI长什么样,只需要写逻辑即可,能够强制实现分层(UI层与逻辑层),方便日后做热更新。

时间: 2024-08-23 22:36:38

FairyGUI和NGUI对比的相关文章

用uGUI开发自定义Toggle Slider控件

一.前言 写完<Unity4.6新UI系统初探>后,我模仿手机上的UI分别用uGui和NGUI做了一个仅用作演示的ToggleSlider,我认为这个小小的控件已能体现自定义控件的开发过程.由于手头上没有mac版,暂时未能真机测试,PC上的效果如下: 二.制作过程 完整工程托管于github,分为uGui和NGUI两个project.考虑到版权问题,工程里不含NGUI,同学们需自行将NGUI导进工程.NGUI需要Unity 4.5,uGui需要Unity 4.6. 三.功能点 滑块可以拖动,从

Unity+NGUI多分辨率适配方案

说起unity的适配方案,网上可谓是一查一大堆,但是真正要应用到项目中的时候,总会出现各式各样的问题.由于最近自己要做一个小游戏,在开始做游戏之前,就想着先好好搞一搞适配这块,以后新起项目的时候也会用得着. NGUI应该是现在大部分开发者都会去选择的UI插件,虽然NGUI还存在着不少问题,像是相对来说,NGUI还是比较靠谱的,所以这里只是针对NGUI做适配方案. NGUI中对于每一个场景,都是以UIRoot为GameObject树的根的,UIRoot下面主要有这几种属性 1) Scaling S

Unity NGUI和UGUI与模型、特效的层级关系

目录 1.介绍两大UI插件NGUI和UGUI 2.unity渲染顺序控制方式 3.NGUI的控制 4.UGUI的控制 5.模型深度的控制 6.粒子特效深度控制 7.NGUI与模型和粒子特效穿插层级管理 8.UGUI与模型和粒子特效穿插层级管理 写在前面 这篇笔记是整理了之前做的记录,在做项目的过程中,遇到了各种各样的界面穿插问题,界面层级混乱,比如,手机卡了或点快了,就导致两个界面相互交叉.对于界面,这应该算是一个很严重的bug,很大部分原因是整个UI框架没有从整体上考虑这个,后来决心弄清楚层级

jquery和vue对比

jquery和vue对比 前言:很多人说jquey和vue没有什么可比的,应该和Angular,React来比吧,我到觉得他们倒没有多大的可比性,都是基于mvvm思想设计的框架,无非就是实现的方式不一样,在不同场景下性能上会有一些差异.然而从jquery到vue或者说是到mvvm的转变则是一个思想想的转变,是将原有的直接操作dom的思想转变到操作数据上去,难道不是一个根本性的改变吗? 1.jquery介绍:想必大家都用过jquery吧,这个曾经也是现在依然最流行的web前端js库,可是现在无论是

JAVA面试中问及HIBERNATE与 MYBATIS的对比,在这里做一下总结(转)

hibernate以及mybatis都有过学习,在java面试中也被提及问道过,在项目实践中也应用过,现在对hibernate和mybatis做一下对比,便于大家更好的理解和学习,使自己在做项目中更加得心应手. 第一方面:开发速度的对比 就开发速度而言,Hibernate的真正掌握要比Mybatis来得难些.Mybatis框架相对简单很容易上手,但也相对简陋些.个人觉得要用好Mybatis还是首先要先理解好Hibernate. 比起两者的开发速度,不仅仅要考虑到两者的特性及性能,更要根据项目需求

推荐系统中常用算法 以及优点缺点对比

推荐系统中常用算法 以及优点缺点对比 在 推荐系统简介中,我们给出了推荐系统的一般框架.很明显,推荐方法是整个推荐系统中最核心.最关键的部分,很大程度上决定了推荐系统性能的优劣.目前,主要的推荐方法包括:基于内容推荐.协同过滤推荐.基于关联规则推荐.基于效用推荐.基于知识推荐和组合推荐. 一.基于内容推荐 基于内容的推荐(Content-based Recommendation)是信息过滤技术的延续与发展,它是建立在项目的内容信息上作出推荐的,而不需要依据用户对项目的评价意见,更多地需要用机 器

hibernate和ibatis对比

Hibernate是当前最流行的O/R mapping框架,iBATIS是另外一种优秀的O/R mapping框架. Hibernate对数据库结构提供了较为完整的封装,Hibernate的O/R Mapping实现了POJO和数据库表之间的映射,以及SQL的自动生成和执行.程序员往往只需定义好了POJO到数据库表的映射关系,即可通过Hibernate提供的方法完成持久层操作.Hibernate/OJB会根据制定的存储逻辑,自动生成对应的SQL并调用JDBC接口加以执行. 而iBATIS的着力点

【非凡程序员】 OC第十五节课 (观察者模式和KVO进行对比)

今天主要学了观察者模式,以及回顾复习了KVO,两者进行对比 什么是观察者模式? 我们先打个比方,这就像你订报纸.比如你想知道美国最近放生了些新闻,你可能会订阅一份美国周刊,然后一旦美国有了新的故事,美国周刊就发一刊,并邮寄给你,当你收到这份报刊,然后你就能够了解美国最新的动态.其实这就是观察者模式,A对B的变化感兴趣,就注册为B的观察者,当B发生变化时通知A,告知B发生了变化.这是一种非常典型的观察者的用法,我把这种使用方法叫做经典观察者模式 KVO的全称是Key-Value Observer,

MongoDB命令及SQL语法对比

mongodb与mysql命令对比 传统的关系数据库一般由数据库(database).表(table).记录(record)三个层次概念组成,MongoDB是由数据库(database).集合(collection).文档对象(document)三个层次组成.MongoDB对于关系型数据库里的表,但是集合中没有列.行和关系概念,这体现了模式自由的特点. MySQL MongoDB 说明 mysqld mongod 服务器守护进程 mysql mongo 客户端工具 mysqldump mongo