ACE2的优点与缺点孰是孰非
[size=4]ACE2 已是如日中天, 世界范围内受到着众多用户追捧. 然而在开发者眼中并不是那么统一, 前一阵Mop上[/size][url=http://bbs.game.mop.com/viewthread.php?tid=1531891&extra=&page=1][size=4]一个帖子[/size][/url][size=4]引起了众多开发者的广泛争论, 本来是件好事, 但可惜随着一些作者言语方式的不当, 这个争论越来越偏离技术主题, 以致于引发了混乱. 此次重提此话题, 希望广大技术人员提出自己的看法, 相信每个人都能看到不同的一面, 集思广益, 对大家都会有所帮助, 也能更好的引导用户.[/size]参与讨论, 您需要注意的是:
1. 仅限汉化开发者参与, 如果您是用户非常想参与讨论, 那么请标明你是用户的身份.
2. 因果论断需要明确, 不要仅仅给出一个结果, 无病呻吟. 如果你不懂, 就不要参与了.
3. 仅限技术讨论, 请勿发表任何(潜在)挑衅话题.
[color=red]为了保证讨论主题不会偏离, 请严格遵守以上注意事项, 一旦违反, 严肃处理.[/color] ace的库太大了
别的没什么 我只粗看过ACE2 OO部分的代码, 其他地方了解不多.
从学术角度来讲, ACE2 对于OO的封装是非常完美, 几乎实现OO一切的特性, 这是个了不起的工作, 绝对是一个脚本语言实现OO机制的优秀示例.
而站在wow面前的实用角度来讲, ACE2这样的OO封装有些过了.
1. lua语言本身非OO, 依靠上层封装出一套OO, 效率与内存占用与原生语言相比肯定是低下的. 很多特性开发者用不到或很少用到, 比如interface, 在这样的动态弱类型语言中基本是不需要的, 再比如, 多继承, 传统语言用的都不多, 可代替方式很多. 这样太追求于形式的完美化, 反而造成了不少负担与冗余. 另一点由于是用语言本身封装的OO, 无法创建新语法, 导致这OO语法用的别别扭扭, 给学习造成了一定难度.
2. wow插件开发属于中小规模的高层应用开发, 使用基于对象方式结合契约式编程不仅可以做到很好的维护与复用而且能够带来更高的效率.
ACE似乎在尝试一种组件化的开发方式, 把常见的应用都封装为功能组件, 这是个好思路, 也是软件行业发展的趋势, 而在wow中做到这样很难, wow的api是个很不稳定的东西, 使用wow api来构建库, 构建组件, 会让库和软件都变的很不稳定. 最让我想不通的就是做为一个库和本地化的不少特性结合的那么紧密, 要使用还需要做大量本地化工作, 没见哪个库是这么设计的(MFC, java, .net), 库作出来就是为了通用, 不能通用的部分就不要封装进去.
3. 东西多自然会变的很大.
总体感觉就是, ACE2做的太高级了太理想化了, 有用没用的东西都往里塞, 高级的脱离现状了.
加上我机器不太好, 因此我不喜欢ACE2, 也不用相关的插件. 从一个汉化作者角度来说ACE的库依赖这个问题其实是很难取舍的，比如烦了人很久的babble冲突，如果仅仅用于某一客户端还好，但是考虑到多语言环境的话locale库的问题就必须加以注意 目前 ace2 的优势在于对公用数据的封装, 其他运行库在脚本语言中来看是多余的了, 但同时一些库的封装对于非资深编程人员来说, 仅通过设置属性便能实现很多功能, 又是非常方便的. 也有利于整合功能的统一编写, 实在是优点缺点都很明显 毕竟WOW是个游戏 UI要面向大众 不能把ACE当软件工程折腾 不用对ACE要求太高 呵呵 此贴么, 技术讨论贴, 从市场角度来讲, 无需争论ace2是无可辩驳的最好.
只希望能从技术角度得到更多的信息, 不完全是为了wow插件, 也是为了自己技术水平的提高. 需要平衡的东西很多。但就个性而言，ACE有点像WinCE 5的蹩脚状况，太多无关的功能然后真正该被关注的东西被忽略了 Ace的初衷是什么？我们对于Ace的理解是否偏离了他的定位？
[quote]
Ace2 is a collection of libraries intended to: improve modularity, improve performance, and simplify the addon and library creation process.
[/quote]
由于紧贴主题，最初的Ace是近乎完美的，功能也非常强大，但是随着!!!StandaloneLibrary等整合库的出现，随着各种功能库（比如Sink、Soar、Threat等）的出现，Ace变的渐渐臃肿起来，似乎偏离了“improve performance”的路线。
这时，一部分人开始思念当初的Ace，于是有了Dongle（不知道Eva是不是由此产生的）等追求简约的东西出现。
当然，对很多人来说，Ace的功能才是重点。看看PerfectRaid处理选项的代码(PerfectRaid_Frames.lua)，我真切地体会到Waterfall的优势。有些类似于对.NET framework的热衷，我对这类东西非常喜欢。通过建立一个标准化的插件框架，改进用户和程序员体验才是Ace的最大贡献。Windows对于统一用户习惯的作用有多大？Dewdrop、Waterfall、Tablet和FuBar-Plugin正在自己的领域作出贡献。MSDN的作用有多大？WoWAce提供了一个[url=http://www.wowace.com/wiki/Category:API_Documentation]Ace API 的Wiki[/url]来干这个。至于Babble和PeriodicTable ？我们所需要的仅仅是和SVN的同步更新而已……
PS：(quote from [url=http://www.wowace.com/wiki/What_is_Ace]http://www.wowace.com/wiki/What_is_Ace[/url] )
[list=1][*][b]Ace is not ACE, ACE2 or any other weird acronym.[/b][*][b]Being "Aced" does not make an addon "better".[/b][list=1][*]The [i]code[/i] and the [i]author[/i] make it better.[*]Choose the addon that best fits you. [b]Try before you buy.[/b] If it's not Ace, then so be it![*]A smaller addon is not always the best. Ace [i]can[/i] be misused.[*]Efficiency is often a major philosophy of the Ace community - naturally, this may not always be achieved - again, it is a good idea to try several addons.[/list][*][b]Using Ace does not prevent you from using other addons.[/b][*][b]Ace will not magically make your crap computer non-crap.[/b] Sorry.[*][b]Ace is not very complicated for the end-user.[/b] Older libraries should not normally cause problems.[*][b]Ace is not a religion.[/b] Non-adherents should never be persecuted. Unless their addon is awful - but even then, [i]help[/i], don't insult.[/list] 外围组件,控件的丰富,这对开发者是个极大的诱惑, 但这与库本身的技术优缺点关系不大, 只能说明社区支持性良好. 如同mfc, 不是一个设计很好的库, 却应用广泛有相当多的支持. 关键不在于Ace本身的好坏，在于人，有人制定了Ace思想，组建了网站，Wiki，论坛，社群，SVN，files等等页面，制定了完整的发布，更新，下载制度。
吸引了优秀的作者参与Ace系列插件的创作，因此不断更新修正着的插件就是最好的插件。即使不是最好，也将成为最好。 虽然偶不懂什么程序
但是可以作为使用者来说几句吧
ACE的缺点就是裤子太大太大……
想当初就是为了脱离整合插件而自己去找单体插件
就是为了脱离那一大堆无用的插件文件夹，现在已经成功脱离啦 －。－
但是，却迎来了一个更占用内存的插件——ACE整合库
个人觉得，作为程序员开发，也要为低端用户着想，512M内存，低端显卡低端CPU的热爱WOW的玩家大有人在
以前有一个叫做魔力宝典的东西（魔力宝贝资料库，不是天空魔力宝典），也为了低端用户，一直限制再640*480的分辨率下做……
有时候真的为了一个很喜欢的ACE插件而不得不塞进一个超大的整合库，却是让人颇费脑筋的问题（高端机器的用户请略过，全用ACE插件的也请略过）
偶个人就是为了PHRAID和ATLASLOOT而塞了一个大裤子...
偶玩游戏的时候喜欢打开任务管理器，在1.123的时候装了很多很多插件，插件内存占用高达70-80M
但是打开任务管理器来开，如果偶从奥格瑞玛飞到希利苏斯
wow.exe这个程序的占用从500M跳到700M，虚拟内存也差不多550M跳到750M
但是现在 2.0 的时候，清掉了以前的插件自己重新组合，插件内存使用只有13M-15M
wow.exe 内存占用一般在350-400M这样 虚拟内存也是 350
就算从冬泉谷飞到希利苏斯，内存占用最多也就450M，其中的原因偶也不是很清楚...
只知道应该是插件的原因吧...
语无伦次的说了几点……见谅了
回复 #12 西行寺 的帖子
哎明显是wow自己为了能让你玩得high把资源优化做好了，和插件没太大关系，以前插件是这样写现在还是这样写，只是 Wow性能变好了而已回复 #12 西行寺 的帖子
如果你只用1两个ACE类插件为什么要用整合库呢? 作为开发者，曾经考虑过使用ACE，不过很快放弃了，原因simon大也说过，"ACE2做的太高级了太理想化了, 有用没用的东西都往里塞, 高级的脱离现状了." 。 使用ACE2，首先就让我的精力从插件开发上转移到ACE2的学习上。我承认开发出来的代码很漂亮，但是漂亮的代价是对底层代码的模糊和执行效率的低下（C与java的对比)。ACE2的体系结构更适合开发大的系统，在大系统中，ACE2的可维护性和稳定性都不错。如果说他们最初的目的是开发各个组件，然后组成一个大的插件系统的话，的确没问题。但对于个人开发者，使用ACE2就像杀鸡用牛刀一样。
事实上，普通开发者或者UI初学者需要的不是一个完美的整合库。而是一个规范而有效的制作工具。WoW UI Designer 是我见过的目前最好的一款工具，不过问题还是很多。而且代码开发方面也没有做出规范。 有一句，oo的东西向来都是低效率的，oo的目的压根就不是效率，而是彻底背离效率，也许ace2不应该追求彻底oo，因为暴雪明天就可能倒闭:)，但是ace2并没有错，只是它的社区现在太大了，需求太多了，正如windows，他的效率是最低下的，我们还不是在用他看这个页面么:| 我梦想一个应用框架标准，学会这个标准，任何地方都可以使用，但是没有这样的东西。java失败了，.net也没成功，ace更是wow里的一个玩具。（搞笑的是学术界的ACE框架和WOW里的ace居然一样的名字，而很有意思的是，大ACE和小ace居然这么相似，都是一个小区域的东西）
我们做技术的在不断的学这个框架，学那个框架。永远都是花80％的时间学习别人的思维，20％的时间创造自己的价值。我只想呼吁框架设计者，我们需要更多时间创造，而不是学习。 随便说说感受
这个应该可以认为是一个标准化的过程,也就是需要稳定，需要开发者的认同。
现在有的汉化插件带着所有库发布,或者特殊库和标准库混在一起,甚至加载embeds.xml而里面的库一个都没有，在frameXML.log里留下一大片error。
标准需要确立，需要认同。如果默认需要标准库，建议发布插件时就不要带着库，或者toc里带着标准库的加载纪录，只加载非标准库。
说得不对的地方请批评指正，谢谢！ 其实ace的库并不需要这么大的
有些实现相当偏僻纯粹用不到，有些是重复实现
有些代码的效率也有问题 库的存在, 开发者的天堂, 普通用户的噩梦
插件的作者们纷纷倒向ACE2的光环
而对用户来说, 只是不得不接受而已... [quote]原帖由 [i]zjfeiye[/i] 于 2007-8-13 10:36 发表 [url=http://bbs.cwowaddon.com/redirect.php?goto=findpost&pid=13345&ptid=1310][img]http://bbs.cwowaddon.com/images/common/back.gif[/img][/url]
如果你只用1两个ACE类插件为什么要用整合库呢? [/quote]
问题就在这里，我们普通用户根本无权选择，因为现在有些ace类插件找不到替代品，至少找不到质量比较好的替代品，大部分开发者都把精力花在ace类插件的开发上，看看mop的插件区，现在还有几个前面没+ace的。有时为了一两个自己喜欢的插件，不得不装上这么大个库。 一两个的可以去下载内嵌库版本的。
我记得很久以前看到一句话说ACE的开发组支持内嵌库哦。
如果找不到汉化版的内嵌库，那就额外下载一个英文版的，看看需要什么库自己加进去就OK了，不需要什么编程、语言的知识，解压、复制、粘贴而已。 我比较赞同simonw的观点，ACE2的代码我也看了一些，事实上，并没有多少亮点。尤其是当我看到babble的时候我便喷了，作为一个Library，是不该将耦合度如此高以及实效性如此强的模块放入Library中的。况且还那么大，究其原因，就是因为初期设计的底层以及接口的不合理，才导致日后版本的混乱，造成了类似DLL HELL的结果。
当然，ACE2也并不是没有可取之处，他建立了一些GUI控件，相对于WOW原始Interface中毫无控件概念而言，已经是以一种进步了。
至于ACE2之所以为何这么流行，我觉得是在于开发模式的变革。因为他首先将协同开发融入进WOW插件开发，合理的开发方式导致了一系列优秀的插件的诞生，自然也就助长了它的名气。而实际上，ACE2的名气远比它的实际作用（技术角度）要高。 用ACE插件并不一定要用一整套ACE库，需要什么就用什么，但是整合库在方便了懒人的同时也模糊了ACE的所需应变性质。Babble并不是一个必须安装的库，但是其出现大大便利了插件的本地化，省去了太多太多的单调重复劳动，对于CWoW乃至除enUS以外的WoWer绝对是一大福音。 [quote]原帖由 [i]Seazon[/i] 于 2007-8-16 01:58 发表 [url=http://bbs.cwowaddon.com/redirect.php?goto=findpost&pid=13944&ptid=1310][img]http://bbs.cwowaddon.com/images/common/back.gif[/img][/url]
库的存在, 开发者的天堂, 普通用户的噩梦
插件的作者们纷纷倒向ACE2的光环
而对用户来说, 只是不得不接受而已... [/quote]
对于普通用户而言，裤子是不能不穿的，删除了裤子，发现一堆的无用插件。我也是为了一，二个插件用了裤子，后来为了精简内存去看裤子帖下面的单体库列表，一片茫然啊....很多库，普通用户是不知道如何取舍的，万一出现了报错如何处理？ 一个框架一个库根本上是要简化插件开发，让编码更易读但决不是用另一套更加复杂的API去封装一套复杂的API 所以从来就不用ACE开发学着用就要耗费大量的时间精力实在不合适。
既然是真正意义上的库就需要做到最大程度的共用性，但是ACE现在发展得已经包含了太多需求 整合了太多适用范围窄的库这样一点都不好 [url=http://www.wowace.com]www.wowace.com[/url]对于ace的描述是一个轻量级的强大的工具，它的存在是为了简化插件开发者的工作。如果从这点上来说，它达到了大部分的目标。
ACE发展到现在，已经包含了大量的lib。这些lib本身就提供了强大的功能，例如AceOO和AceLocale。它们的存在的确简化了开发者大部分的基础功能编码工作，且使得代码简洁易于维护。当然，使用任何工具都有学习成本，但这是值得的。个人认为从一个开发者的角度，即使你现在不用ace，你也需要学习和了解它，你需要知道它适合做什么。
对于这么大量的lib，如何使用是对于开发者的挑战。我们可以使用整合库，也可以仅内嵌需要的库。所以我认为“轻量”、“重量”这样的说法并不适合ace，这取决于如何使用lib。但如果从狭义的角度仅指ace的核心代码的话，可以说它是轻量的。我一直觉得ace在指导开发人员使用方面做的工作还不够，这也造成了很多人觉得上手困难或者觉得ace属于重量级。
从最终用户的角度，ace插件的部署和维护的确是一件头疼的事情，整合库的出现也就是为了方便用户使用。就如同看电影是用暴风影音还是用MPC加上独立的解码器一样，用户需要在资源占用和使用方便这两者之间权衡。部署和维护同样也是技术活，普通用户使用不便是可以理解的。好在已经有人意识到了这个问题，出现了ace插件的更新器，加以完善应该可以解决部署和维护的问题（个人认为库的使用不规范是最大的挑战，ace最好能规范它）。随着插件生命周期各环节的完善，相信ace的使用还是能为用户接受的。 1，可能和创造初期的初衷发生了些偏移吧
2，实用至上最好，ACE2掺杂了太多浮躁和华丽，比例少许失调
3，插件的目的是什么 ；魔兽世界的窗口有多少的空间；我们的目的是什么；这些也许是该思考的吧
我是个使用者~！ 看了上面的帖子, 能真正从技术角度分析ace优缺点的人真是不多. 不少人的分析都是基于用户角度, 市场角度来说的, 其实这里的结果不用讨论也已经很明显了.
ace的不少lib的封装定位是有问题的, 他至少没有抽象出哪些是稳定的东西哪些是不稳定的东西, wow的api是不稳定的, 而这些lib的封装却是基于这些不稳定的api, 根基摇摆何以建高楼. 每次的更新自己都不能做到兼容以前, 这是个很严重的问题.
更为理想的情况是增进封装级别, 以用户最终需求为标准进行组件级别的封装, 把那些api不确定性都封装在其中, 外部向开发者留有简单的配置级别的接口. 纵观wow游戏的用户需求, 这点是要比api稳定的多的. 考察一个框架或库的技术优秀性的主要特征一点就是看他能多大程度上的把握实际需求中的稳定及不稳定因素进行封装. ace在这点上做的不足. wow提供的api还不够成熟，毕竟BLZ只是一游戏公司。从2.0的api大幅更改来看，虽然有一定进步，但BLZ也只是为了维护游戏操作平衡这一目的。维护一套稳定成熟的api是需要时间和精力的，好的例子是Flash的AS，从最初简单的控制脚本发展到现在强大的OO脚本语言。BLZ可能还没有意识到这点，或者是基于自身定位而没有去做。可以说wow的api还处于雏形阶段，它的发展要视BLZ的目标而定了。
而ace，其核心库的封装是良好的，其主要是基于lua的语言特性和小部分相对稳定的wow api进行的封装，相当于一个简单的底层framework，提供给插件开发者基础的功能，例如事件机制、数据持久化、本地化等。但是其扩展库（除核心库以外的libs）的确存在simonw所说的问题。除了wow api本身的不稳定因素外，各个lib作者对于抽象封装的理解和目标各不相同，封装的内容和程度不一致，lib接口的稳定性不够理想。
从总体逻辑架构的角度来说，ace的核心库处于底层的位置，扩展库位于中间层，对于wow的功能逻辑进行抽象封装，插件则是上层建筑。ace的扩展库如果能够做到统一规划设计，分离出常用功能需求，分别进行抽象封装，技术角度上是能够解决以上问题的。
从管理角度，现在ace开发团队仅致力于核心库的开发，对ace扩展库的开发管理模式是松散的，如果开发团队能够加强对扩展库的规范管理，上面提到的开发模式才能够实施。不过，对于这样一个短时间里自发形成的开发团队而言，这样的要求也许是苛求了点吧。 对于一些比较常用的插件ACE2是否可以搞个单独库，因为要是电脑配制差的话为了一个插件搞那么大一个库占那么多资源有点不值得！ [quote]原帖由 [i]孤狼葬月[/i] 于 2007-8-17 22:23 发表 [url=http://bbs.cwowaddon.com/redirect.php?goto=findpost&pid=14218&ptid=1310][img]http://bbs.cwowaddon.com/images/common/back.gif[/img][/url]
问题就在这里，我们普通用户根本无权选择，因为现在有些ace类插件找不到替代品，至少找不到质量比较好的替代品，大部分开发者都把精力花在ace类插件的开发上，看看mop的插件区，现在还有几个前面没+ace的。有时为了一两个自己喜 ... [/quote]
是啊！我就是为了那么大的一个库，电脑本身配制不是很高，而放弃了月色狼影的那款很经典的团队BOSS报警插件！ 我也说几句。
首先，一个优秀的底层框架库是必要的。性能、内存占用这些的确很重要的，但是一个开放的可扩展的架构，可以激发整个开源社区的热情，这一点同样重要甚至更加重要。必要的时候，可以为了开源在性能方便做少许牺牲。所以，大家首先不应该质疑我们需要一个优秀的底层库。
其次，从一个底层库的角度，ACE的设计远谈不上优雅，充其量也就是由于社区的贡献变得大而全而已，架构总体来说扩展性也并不算好，但最核心的组件的能力总体说来还过得去而已。但我们知道，当一个库变得很大，当有越来越多的人以各种形式影响它的开发，尤其的开源的东西，从产品的源代码质量角度来看，就几乎不可避免的会变得很差。所以，初步的评估，如果按100分是满分，ACE的全部库加在一起的架构设计的平均水平也就30分，性能设计的水平其实还算有点优化，大致可以到50分的样子，技术规格的开放性达到100分，开源项目的管理水平基本在80-90分。所以这样子综合来看，ACE仍然是目前影响力比较大的基础库。
第三，既然ACE在技术上还有被替代和超越的空间，我们为什么不开发另外一个库替代他？开发另外一个库并非不可能，但普及、推广、持续发展一个库就需要有一个有号召力的开发社区的支持。以中国人的智慧，技术上超越当前的ACE完全是小菜一碟；但以中国人的团队作战能力，对产品品质的态度，要全面持续的领先ACE并不容易。所以我鼓励但不看好开发一个新库。
总结，我们应该尝试做点什么。ACE从技术趋势上并非在走上坡路，而只是在他自己的那个既定路线上继续走下去而已，即可能是前进也可能是后退或绕圈，后来者有机会。 即便熟悉了ace 也还是有必要熟悉 wowapi 和 ui，那何不直接用wowapi ui呢？ 说实在的 并不喜欢ACE2 但是他的功能又太好 不得不用
不喜欢的原因是 库文件太多 太大 库文件做不到合理的优化和分配 作为基本库，ACE变更速度过快，基本库个人认为应该尽量摆脱BLZ更新的影响。并且不涉及逻辑业务。我心目中的基本库就只是个控件集合，其他功能大部分都很容易自己实现，只要在此基础上有一个统一style的编辑器，就能够很容易实现统一的管理和开发。另一方面,wow提供的环境，实现这个编辑器也是可能性很大的。 准备开始支持Rock！ 库太大，这个绝对是ACE2的重点，存储起来也不方便，携带网盘都费劲，低端机器，承受不起了 [quote]原帖由 [i]孤狼葬月[/i] 于 2007-8-17 22:23 发表 [url=http://bbs.cwowaddon.com/redirect.php?goto=findpost&pid=14218&ptid=1310][img]http://bbs.cwowaddon.com/images/common/back.gif[/img][/url]
问题就在这里，我们普通用户根本无权选择，因为现在有些ace类插件找不到替代品，至少找不到质量比较好的替代品，大部分开发者都把精力花在ace类插件的开发上，看看mop的插件区，现在还有几个前面没+ace的。有时为了一两个自己喜 ... [/quote]
所以为了库布白占内存我都尽量使用ACE插件，只要ACE能代替的单体就用ACE 其实ace的库并不需要这么大的
页:
[1]
2