naive客户端,naive 中文

naive ui 适合移动端么

适合

WaveUI在Vue3发布后进行了良好的定位，WaveUI的开发是在Vue3仍处于alpha阶段时就开始了，其目标是在其API稳定后立即支持它，使其成为首批Vue3UI框架之一

什么叫oo编程，oo是哪两个英语单词缩写，rss标志是什么意思

OO(Object-Oriented)

什么是OO?

就是面向接口编程。无论你是用vtable, 或gp的function object, 或就是C的函数指针，正交分解也好，各种pattern也罢，都是面向接口编程思想的一种实现。

为什么要面向接口编程？

为了解耦。

什么是解耦？

就是把程序中互相不相关或有限相关的模块分割开来。就象收拾屋子，你希望把不同的东西放到不同的地方。把酱油和醋倒进不同的瓶子里去。

这里，对完全不相关的功能，可以简单地分开实现。

但事实上，很多情况下，不同模块之间是有互相之间的关系的。这时，就需要接口。用接口准确定义模块之间的关系。解耦前，两个模块之间共享所有信息（这个信息包括数据，也包括各自的实现细节）。解耦后，需要共享的信息被准确地定义在接口中。同时，信息的流向也被确定。

解耦的好处是什么呢？

首先，程序变得清晰了。

其次，不该暴露的实现细节被隐藏了。代码的修改变容易了。

再次，结构灵活了，通过静态多态(function object)或动态多态(vtable), 一个模块可以和任意实现接口的模块协作。原来类A只能与类B协作，解耦后可以和所有实现接口IB的类如B1, B2, ... 协作了。扩展性大大增强。自然而然就代码重用了。

编译依赖也没有了。你可以专心写和编译一个模块，不用等待其它模块的完成。

调试容易了。只要模块对一个接口调试成功，其它的接口也没有问题。于是，甚至可以用一个simple naive的实现该接口的dummy类来调试。（这点，使用template的gp不适用）

那么解耦的坏处是什么呢？

接口的定义变得很关键。解耦就是隐藏一些信息，定义一些需要共享的信息。如果接口定义的不好，隐藏了不该隐藏的信息，那么对某些需要这些信息的复杂情况来说，这个解耦就失败了。

而如果没有隐藏一些应该隐藏的信息，那么不该有的耦合仍然存在。

那么怎样解耦，又怎样定义接口呢？

这是一个纯粹业务逻辑的思考过程。这里，对编程语言的知识变得无关紧要。事实上，只要精确掌握需求，严密地分析需求和模块内部子模块之间的需求，任何一个会逻辑思考的人都可胜任这个工作。就象歌星郑智化一样，虽然不识谱，但一样写歌，只不过最后要懂谱的人把歌纪录下来。

解耦的原则很简单：精确定义需求，仔细分析需求。不要隐藏任何“需求”也许会需要的信息。不要放过任何“需求”明显不需要的信息。

而对需求不清楚的情况，宁可错放一千，不能错杀一个。总而言之，决不能隐藏可能需要的信息。

不考虑重用，重用是解耦后的自然结果。不能倒因为果！

RSS是2004年最热门的互联网词汇之一，不过，相对于博客（BLOG）来说，RSS的知名度相应会低很多，而且至今还没有一个非常贴切的中文词汇，也许以后无需中文名，大家都习惯于直接叫RSS了。RSS之所以同BLOG一样会被认为是热门词汇的一个原因，个人推测，应该是许多分析人士认识到RSS将要对互联网内容的浏览方法所产生的巨大影响。

什么是RSS呢？RSS(Really Simple Syndication)是一种描述和同步网站内容的格式，是目前使用最广泛的XML应用。RSS搭建了信息迅速传播的一个技术平台，使得每个人都成为潜在的信息提供者。发布一个RSS文件后，这个RSS Feed中包含的信息就能直接被其他站点调用，而且由于这些数据都是标准的XML格式，所以也能在其他的终端和服务中使用。

如果从RSS阅读者的角度来看，完全不必考虑它到底是什么意思，只要简单地理解为一种方便的信息获取工具就可以了。RSS获取信息的模式与加入邮件列表（如电子杂志和新闻邮件）获取信息有一定的相似之处，也就是可以不必登录各个提供信息的网站而通过客户端浏览方式（称为“RSS阅读器”）或者在线RSS阅读方式这些内容。例如，通过一个RSS阅读器，可以同时浏览新浪新闻，也可以浏览搜狐或者百度的新闻（如果你采用了RSS订阅的话）。

在许多新闻信息服务类网站，会看到这样的按钮 ,有的网站使用一个图标，有的同时使用两个，这就是典型的提供RSS订阅的标志，这个图标一般链接到订阅RSS信息源的URL。当然，即使不用这样的图标也是可以的，只要提供订阅RSS信息源的URL即可，如网上营销新观察提供的RSS订阅URL是：

使用RSS获取信息的前提是，先安装一个RSS阅读器，然后将提供RSS服务的网站加入到RSS阅读器的频道即可。大部分RSS阅读器本身也预设了部分RSS频道，如新浪新闻、百度新闻等。

RSS基础知识：

如何利用RSS阅读器订阅RSS新闻内容？如何免费下载RSS阅读器？

常用的RSS阅读器：周博通RSS阅读器 看天下网络资讯浏览器

【RSS实用知识】：关于RSS订阅与RSS阅读的常见问题解答(网上营销新观察 冯英健)

为了进一步了解RSS及其发展历程的有关背景知识，下面摘录了2003年10月平文胜为时代营销撰写的有关RSS的介绍文章。仅供参考。网上此类介绍文章也不少，有兴趣的请到网上检索更多信息。例如维基百科对于RSS的定义、RSS规范、RSS专用阅读器和RSS在线阅读器、中文RSS搜索引擎等等（）

RSS及其发展历程简介 （时代营销 平文胜 2003-10-10）

RSS是一种描述和同步网站内容的格式，是目前使用最广泛的XML应用。RSS应用在国外已经非常普遍，从个人博客（Blog）栏目、企业站点到世界级的门户都提供基于RSS的服务，如IBM公司站点的中文新闻RSS ，YAHOO站点的 ，微软MSDN站点的 等等。

1、 RSS的历史

那么RSS究竟代表什么呢？比较普遍的有两种说法，一种是“Rich Site Summary”或“RDF Site Summary”，另一种是“Really Simple Syndication”，之所以有这些分歧，需要从RSS发展的历史说起。

最初的0.90版本RSS是由Netscape公司设计的，目的是用来建立一个整合了各主要新闻站点内容的门户，但是0.90版本的RSS规范过于复杂，而一个简化的RSS 0.91版本也随着Netscape公司对该项目的放弃而于2000年暂停。

不久，一家专门从事博客写作软件开发的公司UserLand接手了RSS 0.91版本的发展，并把它作为其博客写作软件的基础功能之一继续开发，逐步推出了0.92、0.93和0.94版本。随着网络博客的流行，RSS作为一种基本的功能也被越来越多的网站和博客软件支持。

在UserLand公司接手并不断开发RSS的同时，很多的专业人士认识到需要通过一个第三方、非商业的组织，把RSS发展成为一个通用的规范，并进一步标准化。于是2001年一个联合小组在0.90版本RSS的开发原则下，以W3C新一代的语义网技术RDF（Resource Description Framework）为基础，对RSS进行了重新定义，发布RSS1.0，并将RSS定义为“RDF Site Summary”。但是这项工作没有与UserLand公司进行有效的沟通，UserLand公司也不承认RSS 1.0的有效性，并坚持按照自己的设想进一步开发出RSS的后续版本，到2002年9月发布了最新版本RSS 2.0，UserLand公司将RSS定义为“Really Simple Syndication”。

目前RSS已经分化为RSS 0.9x/2.0和RSS 1.0两个阵营，由于分歧的存在和RSS 0.9x/2.0的广泛应用现状，RSS 1.0还没有成为标准化组织的真正标准。

2、 RSS目前的版本和推荐

到目前为止，RSS共有七种版本，推荐使用的是RSS 1.0和RSS 2.0，对于一些基本的站点同步，也可以选用RSS 0.91。

3、 RSS的语法介绍

一个RSS文件就是一段规范的XML数据，该文件一般以rss，xml或者rdf作为后缀。下面我们选择中的一部分作为例子简单说（略）

4、 RSS的联合（Syndication）和聚合（Aggregation）

发布一个RSS文件（一般称为RSS Feed）后，这个RSS Feed中包含的信息就能直接被其他站点调用，而且由于这些数据都是标准的XML格式，所以也能在其他的终端和服务中使用，如PDA、手机、邮件列表等。而且一个网站联盟（比如专门讨论旅游的网站系列）也能通过互相调用彼此的RSS Feed，自动的显示网站联盟中其他站点上的最新信息，这就叫着RSS的联合。这种联合就导致一个站点的内容更新越及时、RSS Feed被调用的越多，该站点的知名度就会越高，从而形成一种良性循环。

而所谓RSS聚合，就是通过软件工具的方法从网络上搜集各种RSS Feed并在一个界面中提供给读者进行阅读。这些软件可以是在线的WEB工具，如 ， ， ， ， 等，也可以是下载到客户端安装的工具

5、 RSS的未来发展

随着越来越多的站点对RSS的支持，RSS已经成为目前最成功的XML应用。RSS搭建了信息迅速传播的一个技术平台，使得每个人都成为潜在的信息提供者。相信很快我们就会看到大量基于RSS的专业门户、聚合站点和更精确的搜索引擎。

参考资料：

(课程)基于HBase做Storm 实时计算指标存储

Hi，大家好！我是祝威廉，本来微博也想叫祝威廉的，可惜被人占了，于是改名叫·祝威廉二世。然后总感觉哪里不对。目前在乐视云数据部门里从事实时计算，数据平台、搜索和推荐等多个方向。曾从事基础框架，搜索研发四年，大数据平台架构、推荐三年多，个人时间现专注于集群自动化部署，服务管理，资源自动化调度等方向。

这次探讨的主题是：

*** 基于 HBase 做 Storm 实时计算指标存储 ***

HBase 实时指标存储是我入职乐视云后对原有的实时系统改造的一部分。部分分享内容其实还处于实施阶段。架构方案设计的话应该是仁者见仁智者见智，也会有很多考虑不周的地方，欢迎大家批评指正。说不定大家听完分享后好的提议我们会用到工程上，也为后面的实际课程做好准备。

我之前做过一次大数据的课，比较 Naive，但是也包含了我对数据平台的一些看法。

参看：

好了，步入正文，O(∩_∩)O~

乐视云内部用 Storm 做 CDN，点播，直播流量的计算，同时还有慢速比，卡顿比等统计指标。相应的指标会由指标名称，业务类型，客户，地域，ISP 等多个维度组成。指标计算一个比较大的问题是 Key 的集合很大。

举个例子，假设我们有客户 10w，计算指标假设 100 个，5 个 ISP，30 个地域，这样就有亿级以上的 Key 了，我们还要统计分钟级别，小时级别，天级别，月级别。所以写入量和存储量都不小。

如果采用 Redis/Memcached 写入速度是没有问题的，毕竟完全的内存操作。但是 key 集合太大，其实压力也蛮大的，我去的时候因为加了指标，结果导致 Memcache 被写爆了，所以紧急做了扩容。

首先是 Redis 查起来的太麻烦。客户端为了某个查询，需要汇总成千上万个 Key。。。业务方表示很蛋疼，我们也表示很蛋疼

其次，内存是有限的，只能存当天的。以前的数据需要转存。

第三，你还是绕不过持久化存储，于是引入 MySQL，现在是每天一张表。那 Redis 导入到 MySQL 本身就麻烦。所以工作量多了，查询也麻烦，查一个月半年的数据就吐血了。

鉴于以上原因，我们就想着有没有更合适的方案。

我们首先就想到了 HBase，因为 HBase 还是具有蛮强悍的写入性功能以及优秀的可扩展性。而事实上经过调研，我们发现 HBase 还是非常适合指标查询的，可以有效的通过列来减少 key 的数量。

举个例子，我现在想绘制某一个视频昨天每一分钟的播放量的曲线图。如果是 Redis，你很可能需要查询 1440 个 Key。如果是 HBase，只要一条记录就搞定。

我们现在上图：

这里，我们一行可以追踪某个指标一天的情况。如果加再加个维度，无非增加一条记录。而如果是 redis，可能就多了一倍，也就是 2880 个 key 了。

假设该视频是 A，已经在线上 100 天了。我们会记录这个视频所有的 1 分钟播放数，用 Redis 可能有 100*1440 个 key，但是 HBase只要获取 100 条记录就可以找出来，我们把时间粒度转化为了 hbase 的列，从而减少行 (Key)。

我们知道 HBase 是可以多列族，多 Column，Schemaless 的。所以这里，我们建了一个列族，在该列族上，直接建了 1440 个 Column。Column 的数目和时间粒度有关。如果是一分钟粒度，会有 1440 个，如果是五分钟粒度的会有 288 个，如果是小时粒度的，会有 24 个。不同的粒度，我们会建不同的表。

写入的时候，我们可以定位到 rowkey，以及对应的 column，这里一般不会存在并发写。当然 HBase 的 increment 已经解决了并发问题，但是会造成一定的性能影响。

查询的时候，可根据天的区间查出一条相应的记录。我们是直接把记录都取出来，Column 只是一个 Int/Long 类型，所以 1440 个 Column 数据也不算大。

Storm 计算这一块，还有一个比较有意思的地方。假设 A 指标是五分钟粒度的，也就是说我们会存储 A 指标每个五分钟的值。但是在实际做存储的时候，他并不是五分钟结束后就往 HBase 里存储，而是每隔(几秒/或者一定条数后)就 increment 到 HBase 中，然后清除重新计数。

这里其实我要强调的是，到 HBase 并不是覆盖某个 Rowkey 特定的 Cloumn 值，而是在它原有的基础上，做加法。这样做可以防止时间周期比较长的指标，其累计值不会因为有拓扑当掉了而丢失数据(其实还是会丢的，但可能损失的计数比较少而已)。

丢数据比如你 kill-9 了。

大家可以想象一下，如果我计算一个五分钟的指标，到第三分钟挂掉了，此时累计值是 1000，接着拓扑重启了，五分钟还没完，剩下的两分钟它会接着累计，此时是 500。如果是覆盖写，就会得到不正确的结果，实际上整个完整的计数是 1500。

防止拓扑当掉并不是这样设计的主要原因，还有一点是计算延时了，比如某个数据片段因为某个原因，延时了十分钟才到 Storm 实时计算集群，这个时候新得到的值还可以加回去，如果是覆盖，数据就错误了。

所以 HBase 存储这块就变成做加法操作而不仅仅是简单的更新了。目前 HBase 添加了计数的功能 (Increment)，而另外一个比较神奇的接口设计的地方是，竟然没有从名字上看的出是批量increment接口，一开始我以为没有，后面是去看源码，才发现是有的，就是batch接口，put,increment等都可以使用这种接口去批量提交，提高查询效率。

另外 HBase 的 Client 也是非常的奇特，比如 HTablePool 竟然是对象池而不是真实的Connection连接池，多个 HTable 对象是共享一个 Connection 链接的。当然，这里 HTable 的 Connection 会比较复杂，因为要连 Zookeeper 还有各个 Region。如果过多了，可能会对Zookeeper造成压力，这倒也问题不大。

如果不使用批量接口，客户端的写入量死活是上不去。16 台 32G，24 核的服务器，我做了预分区 (60个左右)，用了四十个进程，300 个左右的线程去写，也就只能写到 60000/s 而已。

但实际并发应该是只有 40 左右的。300 个线程并没有起到太多作用。

还有就是，HBase 的 incrementColumnValue 的性能确实不高。至少和批量 Put 差距很大。所以一定要使用Batch接口。性能可以提升很多倍。

我们的测试中，还是比较平稳的，整个写入状态。抖动不大。

在整个过程中，有两点要注意：

预分区是要看场景的，在我们这个场景下是预分区是非常重要的。否则一开始都集中在一台机器的一个 Regin 上写，估计很快写的进程就都堵住了。上线就会挂。

所以我事先收集了几天的 key，然后预先根据 key 的分布做了分区。我测试过，在我们的集群上，到了 60 个分区就是一个瓶颈，再加分区已经不能提升写入量。

写入我们也做了些优化，因为写的线程和 Storm 是混用的(其实就是 Storm 在写)。我们不能堵住了 Storm。这点我们是通过rowkey的设计来解决，保证写入和读取都能均匀的分布在HBase的各个Regin上。如果写入出现问题(比如HBase出现堵塞)，一个可选的方案是将数据回写到kafka,然后再起一个拓扑尝试重新写。第二个就是HBase的主从高可用，这个有机会以后再谈。

上面的设计稿中，大家可以看到Rowkey的组成。我的建议是这样

因为md5还是有可能碰撞，所以真实的key必须存在，这点很重要，否则一旦有碰撞，计费就出问题了。

我们总结下上面的内容：

我们再看看整个存储体系完整的拓扑图。

第五个圆圈是为了在实时计算出错时，通过 Spark/MR 进行数据恢复。

第二个圆圈和第四个圆圈是为了做维度复制，比如我计算了五分钟的值，这些值其实可以自动叠加到对应的小时和天上。我们称为分裂程序

第三个圆圈就是对外吐出数据了，由我们的统一查询引擎对外提供支持查询支持了。

我们对查询做一个推演。如果我要给用户绘制流量的一个月曲线图。曲线的最小粒度是小时，小时的值是取 12 个五分钟里最高的值，我们看看需要取多少条记录完成这个查询。

我们需要取 31 条五分钟的记录，每条记录有 288 个点，对这 288 个点分成 24 份(具体就是把分钟去掉 groupBy 一下)，求出每份里的最大值(每组 SortBy 一下)，这样就得到了 24 个值。

我取过两天的，整个 HTTP 响应时间可以控制 50ms 左右（本机测试）。

上面的整体架构中，分裂程序是为了缓解实时写入 HBase 的压力，同时我们还利用 MR/Spark 做为恢复机制，如果实时计算产生问题，我们可以在小时内完成恢复操作，比如日志的收集程序、分拣程序、以及格式化程序。格式化程序处理完之后是 kafka，Storm 对接的是 Kafka 和 HBase。

上面就是今天分享的内容了。

感谢大家。

Q：海量存储容灾备份怎么做？

Q：祝同学现在的工作主要是哪些？我也是做云服务器的，想请教下以后的职业发展。

Q：祝老师能介绍下架构中数据恢复的机制么？

Q：distinctcount，是该如何计算，比如在这一个月 ip 数？

Q：祝老师，您好，对于初学者进入打数据领域学习，有什么建议于指导，是否需要这么大量的支撑，平时可能遇不到您说的那种情况。

Q：老师我对您那个架构有一个问题既然有 1在计算为啥还要有 2 和 4？

Q：针对你们的一分钟设计，如果列值比较复杂，比如要分析用户数，用户来源，用户 ip 等等，这个时候怎么设计表结构？

Q：HBase 是否适合做实时统计分析，比如 group by 操作如何能够支撑高并发？

Q：祝老师您好，我最近要一个协处理器的功能，但是业务需要区别 hbase 的新增和更新，我在 Google 找到 incrementcolumnvalue 可以做到，但是目前并没有试成功，请问您有没有这方面的经验或者建议呢？谢谢！

如何利用大数据进行用户需求分析

1.可视化分析

大数据分析的使用者有大数据分析专家，同时还有普通用户，但是他们二者对于大数据分析最基本的要求就是可视化分析，因为可视化分析能够直观的呈现大数据特点，同时能够非常容易被读者所接受，就如同看图说话一样简单明了。

2. 数据挖掘算法

大数据分析的理论核心就是数据挖掘算法，各种数据挖掘的算法基于不同的数据类型和格式才能更加科学的呈现出数据本身具备的特点，也正是因为这些被全世界统

计

学家所公认的各种统计方法（可以称之为真理）才能深入数据内部，挖掘出公认的价值。另外一个方面也是因为有这些数据挖掘的算法才能更快速的处理大数据，如

果一个算法得花上好几年才能得出结论，那大数据的价值也就无从说起了。

3. 预测性分析

大数据分析最终要的应用领域之一就是预测性分析，从大数据中挖掘出特点，通过科学的建立模型，之后便可以通过模型带入新的数据，从而预测未来的数据。

4. 语义引擎

非结构化数据的多元化给数据分析带来新的挑战，我们需要一套工具系统的去分析，提炼数据。语义引擎需要设计到有足够的人工智能以足以从数据中主动地提取信息。

5.数据质量和数据管理。 大数据分析离不开数据质量和数据管理，高质量的数据和有效的数据管理，无论是在学术研究还是在商业应用领域，都能够保证分析结果的真实和有价值。

大数据分析的基础就是以上五个方面，当然更加深入大数据分析的话，还有很多很多更加有特点的、更加深入的、更加专业的大数据分析方法。

大数据的技术

数据采集： ETL工具负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。

数据存取： 关系数据库、NOSQL、SQL等。

基础架构： 云存储、分布式文件存储等。

数

据处理： 自然语言处理(NLP，Natural Language

Processing)是研究人与计算机交互的语言问题的一门学科。处理自然语言的关键是要让计算机地理解地自然语言，所以自然语言处理又叫做自然语言理

解也称为计算语言学。一方面它是语言信息处理的一个分支，另一方面它是人工智能的核心课题之一。

统计分析：

假设检验、显著性检验、差异分析、相关分析、T检验、 方差分析 、

卡方分析、偏相关分析、距离分析、回归分析、简单回归分析、多元回归分析、逐步回归、回归预测与残差分析、岭回归、logistic回归分析、曲线估计、

因子分析、聚类分析、主成分分析、因子分析、快速聚类法与聚类法、判别分析、对应分析、多元对应分析（最优尺度分析）、bootstrap技术等等。

数

据挖掘： 分类

（Classification）、估计（Estimation）、预测（Prediction）、相关性分组或关联规则（Affinity

grouping or association rules）、聚类（Clustering）、描述和可视化、Description and

Visualization）、复杂数据类型挖掘(Text, Web ,图形图像，视频，音频等)

模型预测 ：预测模型、机器学习、建模仿真。

结果呈现： 云计算、标签云、关系图等。

大数据的处理

1. 大数据处理之一：采集

大

数据的采集是指利用多个数据库来接收发自客户端（Web、App或者传感器形式等）的

数据，并且用户可以通过这些数据库来进行简单的查询和处理工作。比如，电商会使用传统的关系型数据库MySQL和Oracle等来存储每一笔事务数据，除

此之外，Redis和MongoDB这样的NoSQL数据库也常用于数据的采集。

在大数据的采集过程中，其主要特点和挑战是并发数高，因为同时

有可能会有成千上万的用户

来进行访问和操作，比如火车票售票网站和淘宝，它们并发的访问量在峰值时达到上百万，所以需要在采集端部署大量数据库才能支撑。并且如何在这些数据库之间

进行负载均衡和分片的确是需要深入的思考和设计。

2. 大数据处理之二：导入/预处理

虽然采集端本身会有很多数据库，但是如果要对这些

海量数据进行有效的分析，还是应该将这

些来自前端的数据导入到一个集中的大型分布式数据库，或者分布式存储集群，并且可以在导入基础上做一些简单的清洗和预处理工作。也有一些用户会在导入时使

用来自Twitter的Storm来对数据进行流式计算，来满足部分业务的实时计算需求。

导入与预处理过程的特点和挑战主要是导入的数据量大，每秒钟的导入量经常会达到百兆，甚至千兆级别。

3. 大数据处理之三：统计/分析

统

计与分析主要利用分布式数据库，或者分布式计算集群来对存储于其内的海量数据进行普通

的分析和分类汇总等，以满足大多数常见的分析需求，在这方面，一些实时性需求会用到EMC的GreenPlum、Oracle的Exadata，以及基于

MySQL的列式存储Infobright等，而一些批处理，或者基于半结构化数据的需求可以使用Hadoop。

统计与分析这部分的主要特点和挑战是分析涉及的数据量大，其对系统资源，特别是I/O会有极大的占用。

4. 大数据处理之四：挖掘

与

前面统计和分析过程不同的是，数据挖掘一般没有什么预先设定好的主题，主要是在现有数

据上面进行基于各种算法的计算，从而起到预测（Predict）的效果，从而实现一些高级别数据分析的需求。比较典型算法有用于聚类的Kmeans、用于

统计学习的SVM和用于分类的NaiveBayes，主要使用的工具有Hadoop的Mahout等。该过程的特点和挑战主要是用于挖掘的算法很复杂，并

且计算涉及的数据量和计算量都很大，常用数据挖掘算法都以单线程为主。

整个大数据处理的普遍流程至少应该满足这四个方面的步骤，才能算得上是一个比较完整的大数据处理。

Quasar 中使用 Naive UI

Naive UI 这个组件库配色和交互做得比较用心，尝试在项目开发中引入。但肯定不能抛弃项目用的前端框架Quasar，毕竟Quasar在开发效率上带来的便利不是一个组件库能够替代的。

那么，怎么在Quasar工程中方便的使用 Naive UI呢？

这里推荐一个插件 —— unplugin-vue-components , 能够按需加载第三方组件库。

如果不用 unplugin-vue-components ， 我们在编写每个页面时，都要手动引入组件，非常麻烦。

或者是全局引入，那么打包出来的体积比较大，造成资源浪费和用户体验下降。

用了 unplugin-vue-components 插件之后，就可以在模板中直接使用Naive UI 组件，无需手动引入。同时，它依然是按需引入，打包体积不会变大。

unplugin-vue-components 插件直接支持Naive UI组件，开箱即用。

直接在Quasar配置文件的vite插件上注册即可使用。