ui源码下载

1. ui自动化需要源码吗

1、ui自动化需要源码。
2、UI设计（或称界面设计）是指对软件的人机交互、操作逻辑、界面美观的整体设计。UI设计师的日常工作是一个系统性的工作，所以使用到的软件各不相同。
3、UI设计软件在市面上早已成千上万令人眼花缭乱、应接不暇。比较好用易上手的设计协作工具可以尝试Pixso协同设计，
4、可以简单理解它为网页端的Sketch，不需要下载软件，用户打开网页就可以随时开始设计工作，也被人们称为中国版的Figma。

2. ios开发中怎么给uicollectionviewlayout布局类赋值

iOS 越来越人性化了，用户可以在设置-通用-辅助功能中动态调整字体大小了。你会发现所有 iOS 自带的APP的字体大小都变了，可惜我们开发的第三方APP依然是以前的字体。在 iOS 7 之后我们可以用 UIFont 的preferredFontForTextStyle: 类方法来指定一个样式，并让字体大小符合用户设定的字体大小。目前可供选择的有六种样式：
UIFontTextStyleHeadline UIFontTextStyleBody UIFontTextStyleSubheadline UIFontTextStyleFootnote UIFontTextStyleCaption1 UIFontTextStyleCaption2

iOS会根据样式的用途来合理调整字体。

问题来了，诸如字体大小这种“动态类型”，我们需要对其进行动态的UI调整，否则总是觉得我们的界面怪怪的：

我们想要让Cell 的高度随着字体大小而作出调整：

总之，还会有其他动态因素导致我们需要修改布局。

解决方案
UITableView
有三种策略可以调节Cell（或者是Header和Footer）的高度：

a.调节Height属性
b.通过委托方法tableView: heightForRowAtIndexPath:
c.Cell的“自排列”（self-sizing）

前两种策略都是我们所熟悉的，后面将介绍第三种策略。UITableViewCell 和 UICollectionViewCell 都支持 self-sizing。

在 iOS 7 中，UITableViewDelegate新增了三个方法来满足用户设定Cell、Header和Footer预计高度的方法：
- tableView:: - tableView:: - tableView::

当然对应这三个方法 UITableView 也 estimatedRowHeight、estimatedSectionHeaderHeight 和 estimatedSectionFooterHeight 三个属性，局限性在于只能统一定义所有行和节的高度。

以 Cell 为例，iOS 会根据给出的预计高度来创建一个Cell，但等到真正要显示它的时候，iOS 8会在 self-sizing 计算得出新的 Size 并调整 table 的 contentSize 后，将 Cell 绘制显示出来。关键在于如何得出 Cell 新的 Size，iOS提供了两种方法：

自动布局
这个两年前推出的神器虽然在一开始表现不佳，但随着 Xcode 的越来越给力，在iOS7中自动布局俨然成了默认勾选的选项，通过设定一系列约束来使得我们的UI能够适应各种尺寸的屏幕。如果你有使用约束的经验，想必已经有了解决思路：向 Cell 的 contentView 添加约束。iOS 会先调用 UIView 的 systemLayoutSizeFittingSize: 方法来根据约束计算新的Size，如果你没实现约束，systemLayoutSizeFittingSize: 会接着调用sizeThatFits:方法。

人工代码
我们可以重写sizeThatFits:方法来自己定义新的Size，这样我们就不必学习约束相关的知识了。

下面我给出了一个用 Swift 语言写的 Demo-HardChoice ，使用自动布局来调整UITableViewCell的高度。我通过实现一个UITableViewCell的子类DynamicCell来实现自动布局，你可以再GitHub上下载源码：
import UIKit class DynamicCell: UITableViewCell { required init(coder: NSCoder) { super.init(coder: coder) if textLabel != nil { textLabel.font = UIFont.preferredFontForTextStyle(UIFontTextStyleHeadline) textLabel.numberOfLines = 0 } if detailTextLabel != nil { detailTextLabel.font = UIFont.preferredFontForTextStyle(UIFontTextStyleBody) detailTextLabel.numberOfLines = 0 } } override func constraints() -> [AnyObject] { var constraints = [AnyObject]() if textLabel != nil { constraints.extend(constraintsForView(textLabel)) } if detailTextLabel != nil { constraints.extend(constraintsForView(detailTextLabel)) } constraints.append(NSLayoutConstraint(item: contentView, attribute: NSLayoutAttribute.Height, relatedBy: NSLayoutRelation.GreaterThanOrEqual, toItem: contentView, attribute: NSLayoutAttribute.Height, multiplier: 0, constant: 44)) contentView.addConstraints(constraints) return constraints } func constraintsForView(view:UIView) -> [AnyObject]{ var constraints = [NSLayoutConstraint]() constraints.append(NSLayoutConstraint(item: view, attribute: NSLayoutAttribute.FirstBaseline, relatedBy: NSLayoutRelation.Equal, toItem: contentView, attribute: NSLayoutAttribute.Top, multiplier: 1.8, constant: 30.0)) constraints.append(NSLayoutConstraint(item: contentView, attribute: NSLayoutAttribute.Bottom, relatedBy: NSLayoutRelation.GreaterThanOrEqual, toItem: view, attribute: NSLayoutAttribute.Baseline, multiplier: 1.3, constant: 8)) return constraints } }

上面的代码需要注意的是，Objective-C中的类在Swift中都可以被当做AnyObject，这在类型兼容问题上很管用。

别忘了在相应的 UITableViewController 中的 viewDidLoad 方法中加上：
self.tableView.estimatedRowHeight = 44

自适应效果如下：

UICollectionView
UITableView 和 UICollectionView 都是 data-source 和 delegate 驱动的。UICollectionView 在此之上进行了进一步抽象。它将其子视图的位置，大小和外观的控制权委托给一个单独的布局对象。通过提供一个自定义布局对象，你几乎可以实现任何你能想象到的布局。布局继承自 UICollectionViewLayout 抽象基类。iOS 6 中以 UICollectionViewFlowLayout 类的形式提出了一个具体的布局实现。在 UICollectionViewFlowLayout 中，self-sizing 同样适用：

采用self-sizing后：

UICollectionView 实现 self-sizing 不仅可以通过在 Cell 的 contentView 上加约束和重写 sizeThatFits: 方法，也能在 Cell 层面（以前都是在 contentSize 上进行 self-sizing）上做文章：重写 UICollectionReusableView 的: 方法来在 self-sizing 计算出 Size 之后再修改，这样就达到了对Cell布局属性（）的全面控制。

PS：: 方法默认调整Size属性来适应 self-sizing Cell，所以重写的时候需要先调用父类方法，再在返回的 对象上做你想要做的修改。

由此我们从最经典的 UICollectionViewLayout 强制计算属性（还记得 的一系列工厂方法么？）到使用 self-sizing 来根据我们需求调整属性中的Size，再到重写UICollectionReusableView（UICollectionViewCell也是继承于它）的 : 方法来从Cell层面对所有属性进行修改：

下面来说说如何在 UICollectionViewFlowLayout 实现 self-sizing：
首先，UICollectionViewFlowLayout 增加了estimatedItemSize 属性，这与 UITableView 中的 ”estimated...Height“ 很像（注意我用省略号囊括那三种属性），但毕竟 UICollectionView 中的 Item 都需要约束 Height 和 Width的，所以它是个 CGSIze，除了这点它与 UITableView 中的”estimated...Height“用法没区别。
其...没有其次，在 UICollectionView 中实现 self-sizing，只需给 estimatedItemSize 属性赋值（不能是 CGSizeZero ），一行代码足矣。

InvalidationContext
假如设备屏幕旋转，或者需要展示一些其妙的效果（比如 CoverFlow ），我们需要将当前的布局失效，并重新计算布局。当然每次计算都有一定的开销，所以我们应该谨慎的仅在我们需要的时候调用 invalidateLayout 方法来让布局失效。

在 iOS 6 时代，有的人会“聪明地”这样做：
- (BOOL):(CGRect)newBounds { CGRect oldBounds = self.collectionView.bounds; if (CGRectGetWidth(newBounds) != CGRectGetWidth(oldBounds)) { return YES; } return NO; }

而 iOS 7 新加入的 类声明了在布局失效时布局的哪些部分需要被更新。当数据源变更时，invalidateEverything 和 invalidateDataSourceCounts 这两个只读 Bool 属性标记了UICollectionView 数据源“全部过期失效”和“Section和Item数量失效”，UICollectionView会将它们自动设定并提供给你。

你可以调用invalidateLayoutWithContext:方法并传入一个对象，这能优化布局的更新效率。

当你自定义一个 UICollectionViewLayout 子类时，你可以调用 invalidationContextClass 方法来返回一个你定义的 的子类，这样你的 Layout 子类在失效时会使用你自定义的InvalidationContext 子类来优化更新布局。

你还可以重写 : 方法，在实现自定义 Layout 时通过重写这个方法返回一个 InvalidationContext 对象。

综上所述都是 iOS 7 中新加入的内容，并且还可以应用在 UICollectionViewFlowLayout 中。在 iOS 8 中， 也被用在self-sizing cell上。

iOS8 中 新加入了三个方法使得我们可以更加细致精密地使某一行某一节Item（Cell）、Supplementary View 或 Decoration View 失效：
invalidateItemsAtIndexPaths: :atIndexPaths: :atIndexPaths:

对应着添加了三个只读数组属性来标记上面那三种组件：
invalidatedItemIndexPaths

iOS自带的照片应用会将每一节照片的信息（时间、地点）停留显示在最顶部，实现这种将 Header 粘在顶端的功能其实就是将那个 Index 的 Supplementary View 失效，就这么简单。

新加入的 contentOffsetAdjustment 和 contentSizeAdjustment 属性可以让我们更新 CollectionView 的 content 的位移和尺寸。

此外 UICollectionViewLayout 还加入了一对儿方法来帮助我们使用self-sizing：
:withOriginalAttributes: :withOriginalAttributes:

当一个self-sizing Cell发生属性发生变化时，第一个方法会被调用，它询问是否应该更新布局（即原布局失效），默认为NO；而第二个方法更细化的指明了哪些属性应该更新，需要调用父类的方法获得一个InvalidationContext 对象，然后对其做一些你想要的修改，最后返回。

试想，如果在你自定义的布局中，一个Cell的Size因为某种原因发生了变化（比如由于字体大小变化），其他的Cell会由于 self-sizing 而位置发生变化，你需要实现上面两个方法来让指定的Cell更新布局中的部分属性；别忘了整个 CollectionView 的 contentSize 和 contentOffset 因此也会发生变化，你需要给 contentOffsetAdjustment 和 contentSizeAdjustment 属性赋值。

3. UI设计师，是时候了解一下组件库了

在开始这个话题之前，UI设计师先来回想一下自己的工作流程，当我们开始做一个界面时，不外乎两种情况，一种是新产品，一种是现有产品迭代界面重绘。对于前者，是不是先扒拉扒拉参考一下竞品的界面设计，然后套一套自己产品的功能，然后就可以开工了，这里需要放个导航条，嗯，这里用选项卡，再加个搜索框，搜索图标放里面好还是放外面好呢，就放外面吧，热门搜索要不要做成标签呢，不行，这事决定不了，去问问项目经理去，这里还需要一个文本输入框，限制200字，那就给它个高度300像素吧。而第二种情况，更简单，重新配配色，布布局，画画图标，就酱。不出意外的话，绝大多数UI不会脱离这个套路。（“大神级”UI自然也不会在看这篇文章，这一部分人就暂时忽略了）
如果作为UI设计师的你现在仍然停留在这个阶段的话，那从现在开始，你需要重新规划一下自己的设计思路了，并且，最最重要的是，你需要了解两个东东，“框架”和“库”。这两个概念我自己也比较模糊，从UI设计师的角度出发，我们需要知道的一点是和你们合作的前端极少极少不使用框架，而UI库是一些封装好的组件的样式，你发给攻城狮的设计稿，他们拿到后的第一反应就是赶快看看（咳咳，当我没说）有没有现成的可使用的组件样式，最好越接近你的设计越好，然后简单改改，攻城狮们的工作思路和我们是一样一样的，最好不改交互方式，只改样式。（什么控件、组件、插件的，我也不能严格区分，所以即使有错误的地方，也请勿纠正，哈哈）

说到这里，UI设计师又开始各种烦躁了，设计师到底为毛要掌握这些莫名其妙的知识？？举个例子先，我们都知道给响应不是那么快的页面设计一个加载动画，那作为设计师的你知不知道加载状态是和服务器存在数据交互时使用，如果是本地行为，则不需要加载状态。只有了解这个，你才会知道你的加载动画应该在哪些页面出现，进行什么操作时出现，以什么形式出现合适。（咦，这个例子似乎举得没有代表性，那么来看下面这个例子）
就说个最简单的tab选项卡吧，SUI组件库里的tab选项卡样式是下面这样子的：

样式似乎没有什么参考性，但你从中要得到的一个重要信息就是，作为选项卡而言，内容要和选中标签页看上去成为一个整体，也就是说你可以重新设计成下面这个样式

但如果你设计成了这种样式

那么请来告诉我，这神秘的横线我该如何理解呢？即使下面这种，仍然不是最佳方式，因为我们的选项卡需要“第一眼看上去就知道哪个tab页处于选中状态”。

目前广泛应用的UI组件库，包括easyUI、amazeUI、Bootstrap等等，我们可以从这些来入手，在设计时进行一下参考，如果它的按钮有四个状态，OK，你也来对应设计四个状态，如果它的input输入框有禁用状态，获得焦点状态，那同样你也要在自己的设计文档中予以体现。（当然，并非绝对，也要考虑项目的实际情况，灵活变通）
现在重新理一下工作流程，你要先咨询一下前端开发人员他们常用什么，或者项目中已经使用了什么，咱们来举例说明，如果前端攻城狮们已经使用了EasyUI，而碰巧你的项目中需要一个日期选择的功能，那正确的思路应该是怎样的呢？
首先，你需要先看一下EasyUI库里日期控件的样子。就是下面这样

然后试一下功能，再进行设计时，心里就有底了，比如可以改成下面这样

但这样就完了么？作为UI还需要考虑对于这个控件而言都提供了几种状态？默认加载的当前日期、选中其他日期后的当前日期、鼠标经过、周六/周日的日期颜色、非本月的日期的颜色，这些都需要一一体现在你的标注文档里，事无巨细，一旦疏忽了其中任何一个小细节，好点的情况是负责的前端开发人员会过来和你沟通，而有时可能攻城狮们一疏忽，那只有寄希望于视觉走查和测试了。这么简单的一个日期控件都需要考虑全面，所以，一个合格的UI还是需要多沉浸的。
如果你不没有看过UI库里日期组件的样式，而自作主张的设计成了下面的样子

还拿出很多理论来支持自己的设计，你看，年和月的选择都很方便快捷嘛，嗯，好想看你被开发人员暴打的样子……当然了，这里不是说不让你发挥你的创意，不过除非你有非常说服力的理由和让别人心服口服的设计理论支持，否则，不要做这种出力不讨好的事情，因为作为成熟的组件库，经过多年的发展，已经被很多人所认可和使用，也能更大程度上和其他用户经常使用的产品保持一致的交互。

对于移动端，Android SDK提供的界面UI基本没有看的必要，而绝大多数开源UI库源码在github，给设计师们直观的查看设置了门槛，比如GreenDroid等等，Android的UI框架和web的有个比较大的区别就是按组件分类，像Side-Menu分类侧滑菜单，Pull-to-Refresh下拉刷新，给UI设计师推荐一个awesome-android-ui，自带Demo， https://github.com/wasabeef/awesome-android-ui/blob/master/pages/Material.md ，包括一些动效，很直观。
比如这种水纹效果的样式。

还有这种汉堡菜单/关闭/返回按钮的变换

作为UI设计师，在做原型稿的时候基本不用费尽心思用AE来做什么特效，直接附上效果和库的源文件地址就好，方便自己也方便开发。

另外移动端的UI日常尤其要注意控件样式的积累，自己建好文件夹，分好类，按钮/编辑框/switch/文本控件/进度条/滚动条/对话框/日历/导航/图表/菜单/轮播广告位/搜索框/标签组等等，为了减轻开发人员的负担，在看到不错的效果时，可以把Demo动画和项目地址同时保存下来，因为你的天马行空的想象或者简单一句“在XXX上好像看过这种效果”会让开发人员非常抓狂。
多看UI库的另外一个好处是拓展自己的设计思路，像下面这种Floating Action Button

还有粘连效果的页面指示器

如果不是看到这种动效，或许我们自己也想不出可以做成这种样子。

iOS开发的话因为我本人也只涉及过寥寥数个项目，而且都是和Android用的同一套界面，所以未总结出足够的经验，最多看看最新版的HIG人机交互指南，参考过几个竞品，所以这里就不献丑了。

4. 谁知道有ui设计方面的素材网站么。提供几个。谢谢

创意派 设计网站导航——有很多关于创意设计的网站，栏目分的很细，里面包含了大量日本、韩国、欧美等地区的“ui界面设计”“源码素材”“视频教程”“分层素材资源”等网址大全，一定能满足你的需要，我自己一直在上面找资料。。。

网络可以搜到“创意派”，你可以去看看，网站很全。

5. 软件更新丨移动应用框架 Ionic 4正式版发布：Ionic for Everyone

流行的开源移动应用程序开发框架 Ionic 于今日发布了 4.0 正式版，代号 Neutronium。官方称 Ionic 4 为“Ionic for Everyone”。开发者现在可通过 Ionic 使用 Web 技术轻松构建高质量的原生和渐进式 Web 应用程序。

Ionic 4.0.0 Neutronium 源码下载：https://github.com/ionic-team/ionic/releases/tag/v4.0.0

毫无疑问，Ionic 4 是一个十分重要的版本。它饱含开发团队两年来的研究和努力，将 Ionic 从“mobile for Angular”的定位转变为强大的 UI 设计系统和移动应用程序框架 —— 每个 Web 开发者都可使用它。

简单说来就是因为前端界的变化实在太快了。Ionic 刚问世的时候，正是 AngularJS 流行之时，Ionic 当时的目标也只是打造丰富的由 JavaScript 驱动的组件，以使用 Web 技术构建高质量的移动应用程序。由于业界当时没有统一的标准方法可以实现这一目标，Ionic 便把目光瞄准了 AngularJS，开发者可以在 AngularJS 中构建自定义的指令，而由 Ionic 提供的原生组件可打包成易于使用的自定义 HTML 标记。任何使用该标记的 AngularJS 模板都可以引导组件并运行它，就像在浏览器中实现原生的支持。

即便到了 Angular 2 发布的时候，Angular 饱受争议，但做好移植工作的 Ionic 2 和 3 在彼时依然收获了不错的口碑，Ionic 3 甚至被认为是 Ionic 最成功的版本。

但到了最近两年，前端变化之快不但令人目不暇接，甚至让 Ionic 这样的框架也陷入了瓶颈。AngularJS 已被 Angular 取代，而引领前端发展的“三驾马车”，Ionic 表示其中的“两驾马车”与自身并无交集。

为此，Ionic 进行了反思，并在2017年开始尝试将 Ionic 转变为一组 Web 组件，他们判断这将是未来的趋势 —— 让世界上几乎每个 Web 开发者都可在他们的移动、桌面和渐进式 Web 应用程序中使用 Ionic 的组件 —— 只需在他们的应用程序中使用 Ionic 的自定义 HTML 标记即可。

最重要的是，Ionic 使用的是标准 Web API 而非第三方 API，所以开发者大可放心使用，Ionic 的组件 API 在未来许多年都会保持稳定，而不是成为前端和框架发展进程中的牺牲品。

性能

官方宣称 Ionic 4 是有史以来最快的版本，近 100 个 Ionic 组件均通过性能、定制性和外观方面的评估。每个组件均符合 iOS 和 Android 上的最新标准。

官方提供的性能对比 ↑↑↑

Ionic 4 开箱即用，而优异的性能则让 Ionic 成为了构建高性能 PWA 的最佳 UI 框架。官方表示，为了使 Ionic 达到 Google 规定的性能标准，需要使用新的异步组件加载和交付方法。为实现这一目标，Ionic 团队花了一年的时间使用 Stencil 构建一个 Web 组件管道来生成 Ionic 组件，确保它们封装紧密，可延迟加载。

支持 React 和 Vue

虽然目前对 React 和 Vue 的支持尚处于 alpha 状态，但终归让开发者在框架选择上有了更多样化的选择。

文档改进。官方对开发者文档进行了较大的改进。设计更简单、导航更清晰、内容更突出。

此外，还整合了 API 引用和组件引用方面的内容，减少了之前开发者必须多次跳转才得以获取所需信息的次数。

文档最新地址 >>> http://ionicframework.com/docs

路线图

Ionic 4 现在可用于生产环境，官方提供的 Roadmap 显示未来将改进对特定桌面的 UI 支持、改进键盘方案，提供更丰富的主题和动画。另外就是，提供对 React 和 Vue“一等公民”的支持。

↓↓↓

6. 魔兽世界插件

团队报警系统 RaidAlerter 20080902
发布者： 最后的季节
更新日期： 2008-09-02
界面语言： 简体中文
插件类型： 非库类

插件来源： wowar
运行环境： for WOW 2.4
插件等级： ★★★☆☆

使用说明：
2008-09-02]RaidAlerter团队报警系统（简、繁）——提供RAID和5人队伍的各种特色警报
插件语言：简体中文、繁体中文
适用版本：WOW 2.4.3
插件作者：原作者Oldhand
内存占用：初始内存占用约270K，超限会自动清理
资源占用：视战斗状况而定，在大规模战役中将占用较多的CPU资源。不需要的报警功能建议及时关闭。
插件简介：提供RAID和5人队伍的各种特色警报。

RaidAlerter的前身是RaidCompere，因RaidCompere占用资源过大，早已停止更新。后原作者Oldhand将RaidCompere功能做了大量精简，成为现在的RaidAlerter。
RaidAlerter现在主要提供TANK血量危急、嘲讽抵抗、OT、猎人宁神命中情况、被控制、打破控制、团队检查和5人小队警报等，这些绝大部分都是首领模块所不具备的功能。

【插件功能】
带"★"的功能需要在团队助手(oRA2或CTRA)里设置TANK顺序，否则无效。
◇TANK监视：
·血量监视。若低于设定值（默认30%）则在团队频道通知★；通报战士的盾墙、破釜沉舟技能。
·死亡监视。通报TANK死亡★。
·嘲讽监视。TANK的嘲讽技能如果失败则在团队频道通知。
◇OT报警：默认关闭，建议在需要时手动启用。BOSS锁定非TANK目标超过1秒则判定为OT（排除Boss快速切换目标施法的情况）
·团队消息方式
·M语方式
◇猎人监视：猎人标记怪物以及施放误导的时候进行通告。
◇宁神监视：通报宁神射击是否成功。
◇阵亡通报：战斗结束后若有人阵亡，则
·通报阵亡人数，同时视情况通报和法力和灵魂绑定状态，便于及时复活和RL决定是否稍息。
·在本机用白字显示最先进入战斗状态者（不会影响他人频道）。由于受诸多因素影响，此信息仅供参考。
◇精神控制监视：
·被控制警报。对当前被控制者作骷髅标记并在团队频道通知，此骷髅标记在战斗结束后会自动清除。
·解除控制警报。TANK被控制结束后若仍处于变羊状态，则在团队频道通知，以便及时解除。
◇魔法解除：通告玩家驱散怪物的魔法是否成功；30码内的打破控制技能通告（如开羊）。
◇打断监视：通告怪物正在施放的魔法被谁成功打断。
◇干涉监视：通告哪个QS干涉了谁
◇灵魂石监视：通告谁已被绑定灵魂石。
◇Boss血量通报：RAID Boss战，每10%（5人小队为20%）通报一次Boss血量；低于设定百分比（5人小队固定为5%）则开始逐一通报。
◇5人小队警报：提供组队（非团队）时的嘲讽抵抗、队友血量危急、猎人标记、魔法打断、打破控制通报等功能。此功能无需队长权限。
◇NEF战监视：
·堕落治疗。在团队频道通知堕落治疗者和累计造成伤害。
·狂野变形。如果点名FS把TANK变形则在团队频道通知。
◇TAQ双子战监视：提供AOE技能打到小虫的警报。根据惯用战术，只监控DZ、ZS和LR。
（上面两个功能现在已基本用不上...懒得删了...做个留念..反正不开就不占资源的）
◇生命危急自动喊话：当玩家自身血量过低（默认30%）时自动喊话请求治疗。需属于团队模式设置的正常队员。
此功能进游戏时均默认为关闭，退出游戏后不保存设置。请根据需要用命令/ral myhp开关。
◇战斗记录距离：自动将游戏默认的35码战斗记录距离增大至150码以获得更完全的报警，玩家可根据场合需要自行调整。
◇团队状态条：提供一个相当精简的团队状态条实时显示团队法力、治疗法力和死亡人数；同时能在提示中显示团队PvP、到位和灵魂石状态。

【使用说明】
◇状态条操作：
左键点击：开关警报
右键点击：打开选项菜单
右键拖动：调整团队状态条位置
Ctrl+左键：公布到位检查结果
Ctrl+右键：公布合剂检查结果
Alt+左键：公布PvP检查结果
Alt+右键：公布增强药剂检查结果
Shift+左键：公布团队状态详情
Shift+右键：立即清理插件内存
Ctrl+Alt+左键：血量危急自动喊话开关
◇发送团队警报需要团长L或者助理A权限，否则只在本机显示。多人启用RaidAlerter时，会自动选择一玩家作为报警发送方。若无需警报请及时关闭，可减少资源占用。
◇团队模式人数：比如，设定为25人团队模式，那么认为1-5队属于正常队员，其他则被判定为替补。替补成员不影响警报和实时数据。
◇内存清理界限，默认1024K，增大此设置可以降低内存自动清理频率。个人建议：≤1G内存设定为1000-2000K，1G以上内存建议2000-4000K。
◇战斗记录距离的设定同时对DBM/BigWigs/DamageMeters/Recount等依赖战斗记录的插件有效，但是如果玩家电脑性能太差的可能会导致游戏“卡”到难于接受，请自行降低警报距离（重置到游戏默认的35码）。
◇命令帮助：/raidalerter 或 /ral help

建议配合使用的插件：团队助手（oRA2或CT_RaidAssist） + 首领模块（DBM或BigWigs）

虽然所有的功能设定均有其用意，但众口难调，有些细节如果不合你意的话你可以DIY——用文本编辑工具（如Editplus或UltraEdit）打开RaidAlerter.lua文件：
◇警报方式
有的玩家想用喊话、说等不同的警报方式，找到比如：
RAL.SendMSG("**注意！"..re1.."的嘲讽被→"..re2.."←抵抗了!**", "RAID");
括号最后面""里的RAID就是指报警使用团队消息方式。可以改为：
SAY - 说
YELL - 喊
RAID_WARNING - 团队通知
◇警报声音
不喜欢报警声音？好吧，你把“PlaySoundFile”字串全部替换为“--PlaySoundFile”就能得到一个无声版的RaidAlerter

最后，关于插件语言：自原作者Oldhand开始RaidAlerter就是一个本土插件，只支持简体中文。
个人能力有限，我做的所有改动也只适用于国服简体中文客户端。
要支持其他语言，并不是简单的翻译一下就能用，而是要把所有名词和格式做到精准。
非国服玩家可自行尝试修改。

BTW：UI源码本来就是完全开放的，任何人都可以在尊重作者的前提下自己进行修改。
08-09-02：
1、Buff检查：加入太阳之井高地“基鲁的胜利之歌”Buff识别。
2、略微调整了一下设置界面和状态条的字体（效果见新图）。

08-07-30：
Buff检查：增加圣骑士的祝福检查。
仍然为一键式检查，检查项目由插件自动判定，无需设置。
偶实在厌倦了点完RAL还要再一个一个点XRS的自定义Buff检查...
虽然不够完美，但已经能满足多数情况。
08-07-23：
1、针对2.4.3修订。得益于BLZ对战斗记录的修正，开羊警报现在终于完整（之前不能报平砍开羊）。
2、团队战斗计时：
- 不再记录小于30秒的团队战斗时间；
- 修正了一个判定BUG。
3、控制警报优化，避免菲米丝战役讯息过量可能导致掉线的问题。
4、修正选择报警发送方存在的小问题。
5、其他一些完善和调整。
08-06-03：
1、简体中文、繁体中文两种语言文件整理完成。
繁体语言主要取自恰恰@语风的翻译，同时参考了spippen0的补充意见。
2、Buff检查：
- 现在不再检查离线玩家；
- 改进了通报格式。
3、若是宠物打破控制，则警报包含宠物主人。
4、状态条数值改为平滑着色。
5、冗余算法优化，提高了运行效率。
6、修正几处小BUG。
7、其他一些完善和调整。
08-05-14：
1、新的设置界面（如图）：更易于上手的操作，更详细的警报设定；
2、状态条上Shift+左键现在改为新增的Buff检查功能；
3、修正几处个别情况下出现的BUG。
08-05-05：
1、增加ZS成功反射法术的通报，归于TANK血量开关控制；
2、修正一处罕见情况下的报错；
3、其他一些完善和调整。
08-04-07：
1、修正了一些问题，诸如免疫报为抵抗；
2、报警文字：
- 增加2.4新支持的图形化图标；
- 去除了原“注意！”的前缀
3、对于打某些怪物需要一直刷羊的战术，开羊警报现在基本上不会再持续刷屏；
4、内存清理界限默认值下调为512KB。实测表明，RAID战中的内存占用比以前大为优化，个人建议设定为400～800KB即可。
5、其他一些修正和功能调整。
08-04-03：
1、全面支持CWOW2.4
2、RAID战的内存占用现在更少了。建议内存清理界限适当调低
3、取消了战斗距离设定。(BLZ已经把2.4游戏默认的战斗距离调整为150码)
4、其他一些修正和功能调整。
Milky、癫疯大宝、癫疯长的高、阿斯之光、罡霹、等协助进行测试，特此致谢。
由于2.4战斗事件的全面改变，对RaidAlerter的影响有好也有坏，目前已知的有
- LR标记现在又能报很远距离了，并且能报是哪个LR上的标记。
- 开羊通报，现在只能报技能开羊，若是平砍开羊则无据可查。估计是2.4战斗事件设计的缺陷...
08-03-28：
1、增加目标锁定检查：
- MT目标锁定检查，热键Alt+左键（此热键原为PvP检查，使用频率较低，现取消，需时可用/ral pvp命令）
- 命令：/ral tc 职业，可检查职业目标锁定。如/ral tc 法师 或 /ral tc FS
2、鼠标悬停于状态条时不再导致画面帧数持续降低
3、修正个别玩家的mod错误
4、其他一些调整
08-03-23：
1、改善了RAID战中的资源占用。
2、增加增强药剂检查功能，公布检查的组合键为Alt+右键（原合剂检查仍为Ctrl+右键）。
3、增加RAID战斗计时功能（见新图）。
4、系统资源占用显示，现在默认关闭。需者可使用命令开启。
5、OT密语通知：战斗中将自动屏蔽<BWS>的机器人回复，除非你启用了显示发送。
6、其他一些完善和优化调整。
08-03-11：
1、增加了合剂检查功能，可通过状态条新增的组合键或者命令/ral hjjc或/ral cb公布。
2、更多的状态条组合键操作，方便公布各种检查结果。
3、完善开羊通报：现在包括怪物的技能解羊。
4、其他一些完善和优化调整。
08-01-18：
1、增加战士盾墙、破釜沉舟技能的通报。此功能受TANK血量开关控制。
ps:善于运用宏通知的ZS实在不多...思考再三还是决定再增加此功能...
2、增加玩家生命危急自动喊话功能（/ral myhp）：当玩家自身血量过低（默认30%）时自动喊话请求治疗。
- 出于某些考虑，此功能只接受命令/ral myhp开关。进游戏时均默认为关闭，且退出游戏后不保存设置。
- 自身需属于团队模式设置的正常队员。
- /ral myhp <数值>可设定界限，比如/ral myhp 50即设定为低于50%HP自动喊话。
08-01-08：
1、修正了新增功能在特定情况下可能会出现的一些小问题。
2、调整了打破控制技能的报警声音以和TANK血量危急声音相区分。
3、5人小队的Boss血量通报功能：考虑到5人FB的Boss战持续时间的确很短，根据反馈意见，调整如下：
- 间隔通报血量报警间隔调整为20%
- 逐一通报界限固定为5%，不再受选项控制
4、重新修订了包内的“RaidAlerter说明.txt”文件。鉴于一些UI站点经常转载不完整，现声明：
- 相关截图和源文件以.TOC文件里注明的原始URL发布的为准
- 插件说明以包内文件“RaidAlerter说明.txt”为准
08-01-06：
1、在开羊通报的基础上，进一步增加了打破控制技能的通报：MS锁、XD睡，均由“魔法解除”开关控制。
2、增加了误导通报功能。原“猎人标记”开关改名为“猎人标记和误导”。
少爷西门、妖月猎手协助完成了误导测试，特此致谢。
3、现在和修改战斗记录格式的Recount插件能正常共同工作了，感谢ICEのSUN提供技术支持。
由于FixLogStrings算法的一致性，SW Stats未再做测试。
08-01-04：
1、新增开羊通报。谁动了我的羊？冒失鬼将无处藏身。限于游戏设定，只能监视在变羊范围内的羊（≤30码）。
原选项“魔法驱散”现在更名为“魔法解除”。打羊属于怪物的变形魔法被解除，归于此开关控制。
2、无L或A权限的玩家，现在仍然能在本机看到报警讯息。
3、当队伍中有多人启用RaidAlerter时，会自动选择一玩家作为报警发送方，避免重复报警刷屏现象。
4、增加了RAID人数的选项设定（如图）：替补成员不再影响警报和实时数据。
比如，设定为25人团队模式，那么1-5队属于正常队员，其他则被判定为替补。
5、其他一些修正和调整。
大支懒葩、罡霹参与了同步测试，特此致谢。
07-12-06：
1、增加QS的嘲讽抵抗判定，感谢[华丽的疯狂]提供战斗记录；
2、5人副本的血量和OT警报现在排除以下72级的精英小怪：
- 风暴锻铸护卫者，生态船
- 黑翼龙兽，禁魔监狱
个人精力有限，欢迎大家提供有必要的排除数据：副本名、怪物的准确名称
3、修正控制警报有时过于频繁的问题。
07-11-25：
1、增加熊D的嘲讽抵抗判定；
2、尝试修正个别玩家使用快捷键观察出现的nil错误；
3、增加了几个自己法术被抵抗的屏幕提示。
07-11-24修改说明：
1、修正灵魂石数量有时不能及时更新的问题；
2、在游戏ESC主菜单的按键设置里增加了观察目标等设定（如图）。现在观察装备和天赋是经常行为，绑定个快捷键会
比较方便。
07-11-19修改说明：
1、TOC版本已更改为2.3版；
2、状态条现在不再属于小地图按钮类型；
3、警报前缀已改为较温和的“**注意！...”
4、一些问题修正和调整。
07-10-08修改说明：
1、修正极个别情况下血量危急警报会不断刷屏的问题
2、修正不报自己做最后击杀的问题
3、修正非LA权限时状态条提示的灵魂石数始终显示为0的错误
07-10-02修改说明：
1、更改版本号以适应最新的WOW版本2.2；
2、增加了FS的变形抵抗和反制抵抗通报；
3、5人小队模块：
- 增加OT警报和控制警报；
- 增加72级怪物血量通报（主要针对70和英雄副本Boss）；
- 大多数警报现在受相应选项开关控制
4、其他一些调整和修正。
07-08-10修改说明：
1、由于新oRA2的TANK表名称已更改，之前检测不到oRA2的TANK设定，现已修正。
2、增加内存自动清理界限的选项设置，默认界限1024K，增大此设置可以降低内存自动清理频率。
个人建议：≤1G内存设定为1000-2000K，1G以上内存建议2000-4000K。
3、全面启用内存自动清理优化机制：内存占用超过界限则自动启动清理。
- RAID：仅在战斗结束时启用
- 非RAID：SOLO或小队状态，仅在非战斗状态时启用
**由于个别插件（已确认的比如Auctioneer）会导致RaidAlerter内存在非RAID状态也较快增长，故而决定全面启用。
4、调整了Boss血量通报功能。
07-08-06修改说明：本次修改主要是改写代码以优化资源占用
1、大幅减少状态条和监测报警功能的CPU和内存消耗
2、根据个人设置注册和注销Event，去除了部分冗余事件
3、改进Boss事件如OT警报、血量通报相关算法。
废除原表使用的庞大数据，所需Boss列表由当次RAID自动收集。
这样既可节约资源并能适应TBC及其以后的未知BOSS。
4、改进状态条鼠标悬停提示（如图）
- 增加团队状态下的到位和PvP检测简报（详细报告用Shift+左键或者/ral cp|pvp命令）
- 增加系统资源占用显示：显示内存和CPU占用状况。
CPU占用若是第一次使用需键入/ral cpustart开启。开启后可能会略微影响系统性能。
CPU占用只能提供“占用CPU时间/秒”格式供参考，此参数并非习惯上的百分比
- 鼠标悬停时每3秒自动刷新
5、新增内存自动清理优化机制
由于在L或A状态中RaidAlerter内存增长较快，故而此机制仅在RAID状态结束战斗时启用。
因此，在有的RAID战结束时，画面有时可能会略微卡一下。
由于是在战斗结束，应该不会有人介意这么卡一下吧：)
也可以随时在状态条上按Shift+右键强制进行清理。
6、其他一些调整和优化。

尽管资源占用已优化，但仍然建议及时关闭不需要的报警功能尤其是电脑性能稍差的玩家。
关于猎人标记过远不报的问题，已基本确认是因为CombatLogRangeCreature定义失效导致；目前无法解决。
其他如嘲讽抵抗、打断等仍然可正常设定警报距离。
07-07-05修改说明：
1、灵魂石检测通报功能现已正常。
2、Boss血量通报功能现已修复，工作正常。（之前为何失效？实在百思不得其解...）
3、增加命令：到位检测/ral cp；PvP检测/ral pvp。或者直接用Shift+左键点击状态条一次性公布检测结果。
战斗距离问题目前仍未解决，过远的警报无法触发（比如猎人标记了远方的怪现在无法触发标记警报）。期望高手给予指点...
07-06-27修改说明：
修改为TBC版本，小队模块和团队模块经初步测试，无错。
战斗距离问题目前尚未解决，过远的警报无法触发。TBC貌似对战斗记录限制了距离不能增大？待求证...

http://wowui.owan.com/html/AddOns/3/2/20070806/396.html

7. wemall多用户商城的UI在源码哪里

ui源码？应该是在源码包吧，你买他们的源码这些都是有的，但是是默认模板，源码没有加密，完全开源，你完全可以二开