首页

vue项目刷新当前页面的几种方式

seo达人

在vue项目中,经常会遇到需要刷新当前页面的需求。

因为vue-router判断如果路由没有变化,是不会刷新页面获取数据的。



方式1:go(0)和reload()

通过location.reload()或是this.$router.go(0)两种强制刷新方式,相当于按F5,会出现瞬间白屏,体验差,不推荐。



方式2:定义一个空白路由页面,路由跳转到该空白页后立马跳回当前页,实现路由刷新。

在router路由表中定义一个空白路由,



 // 强制刷新当前页所用的中间跳转页

   {

        path: '/redirect/:path*',

        component: () => import('@/views/redirect/index')

  }



写一个空白路由组件



//redirect/index

<script>

export default {

  created() {

    const { params, query } = this.$route

    const { path } = params

    this.$router.replace({ path: '/' + path, query })

  },

  render: function(h) {

    return h() // avoid warning message

  }

}

</script>





在需要刷新的页面使用



refresh() {

      // 刷新当前路由

      const { fullPath } = this.$route

      this.$router.replace({

        path: '/redirect' + fullPath

      })

    }



这种方式,基本上能够应付绝大多数情况,推荐使用。

但是,有时候,有一些极端情况下,这种刷新不起作用,而又不想用第一种那种毛子般的简单粗暴的方式的话,下面的方式可以选择使用。



方式3:provede/inject 方式

vue官方文档说了,这个依赖注入方式是给插件开发使用的,普通应用中不推荐使用。

但是,效果却很好。

app.vue修改



<template>

  <div id="app">

    <router-view v-if="isRouterAlive" />

  </div>

</template>

<script>

export default {

  name: 'App',

  provide() {

    return {

      reload: this.reload

    }

  },

  data() {

    return {

      isRouterAlive: true

    }

  },

  methods: {

    reload() {

      this.isRouterAlive = false

      this.$nextTick(function(){

        this.isRouterAlive = true

      })

    }

  }

}

</script>





使用的时候:

demo.vue



<template>

  <div class="container">

  xxx

  </div>

</template>



<script>

export default {

  inject: ['reload], // 依赖注入

  name: 'Demo',

  computed: {

    message() {

      return '抱歉,您访问的页面地址有误或者该页面不存在...'

    }

  },

  methods: {

  handleReload() {

  this.reload() // 直接在需要刷新的方法中调用这个reload()

}

  }

}

</script>



<style lang="scss" scoped>

</style>



原理就是通过依赖注入的方式,在顶部app通过v-if的显示隐藏来强制切换显示,以此来让vue重新渲染整个页面,app中通过provide方式定义的reload方法,在它的后代组件中,无论嵌套多深,都能够触发调用这个方法。具体说明查看官方文档。


引导页设计浅析

分享达人

APP中的闪屏、启动页、引导页的区别,设计方法,个人案例分析,以及品牌解读

【什么是闪屏 / 引导页与闪屏的关系】

(部分引用观点)



引导页是闪屏的其中一种,一般出现在版本分布或大版本升级时。

我们先整体看一下闪屏页的大致类型:

(声明:以下图片来源于应用截图,仅作为学习交流使用)









一、常规闪屏


为什么叫常规闪屏?

因为这类闪屏比较普通,我没有想到什么更专业的词汇,暂且就叫常规闪屏吧。这类闪屏的使用国内的和国外有点不同,因为按照苹果官方的说法是,用户打开应用能立即使用是最好的体验,例如:系统自带的一些应用,是没有闪屏的。再甚者闪屏最好就是让用户感觉不到,和首页能有一个完美的融合和过渡。

这种体验也很棒,国外的instagram、facebook等就是使用这种设计,闪屏长得很像首页,更像是一张加载类的占位符








当然,因地制宜,国内的我们已经习惯了闪屏作为App品牌的宣传和推广手段,一般由logo+名称+slogan+品牌色组成,界面还是相对简洁明了的,但还是很明显的违背了苹果官方的指导说法,但是没办法,这就是商业需要。


这样设计也有利处,可以减少用户在打开App时的焦虑感,也可以让用户更直观的了解品牌,传递一些情怀、理念,多看一次闪屏,也是让用户强化品牌记忆的过程,只是不知道是好的记忆点还是坏的,就要我们自己斟酌了。








二、广告闪屏


广告闪屏,顾名思义就是产品本身为了进行流量变现从而获得盈利,给一些商家打广告或者进行合作设计的一类闪屏,这是无可厚非的。不过广告闪屏自带被“嫌弃”属性,应该很多用户看到这类闪屏的心理是比较排斥的。

至少对我来说,我是很少关注这类闪屏,除非闪屏设计的非常的酷炫,我愿意多看一下,否则的话我就想立刻把它关掉,所以在这类闪屏上加上“倒计时(loading)和跳过”就显得很必要,并且“跳过”的位置也要方便用户点击。

这类闪屏最好只出现每天第一次打开App时,避免让用户厌烦。不管出于何种目的,都需要在商业利益和用户体验之间保持一个平衡,不然用户会流失的很快,用户流失了,何谈盈利呢?

另外广告闪屏和下面要说的活动闪屏一样,会有一个模板:底部是闪屏图片,上面盖上一层logo模板。

App启动时会从服务器拉取闪屏数据,本地会保存logo模板。如果服务器更新了闪屏数据会拉取数据进行展示,如果没有更新或是网络不佳,就会默认展示缓存的闪屏数据,以免发生卡顿现象,以保证流畅的用户体验。







三、活动闪屏


活动闪屏和广告闪屏有点类似,出于产品运营方面的需要,它起到活动宣传的作用,每年的双十一、双十二期间,各大电商App的闪屏都会用到活动闪屏,还有一些商家自己造的一些节日:品牌周、年货节、会员日、狂欢周…相信大家已经见怪不怪了。


近期我留意到一个问题,就是我们在使用App时,经常会在应用之间进行切换使用。如果我们从其他应用再次返回时,最好不要再加载一次闪屏,会给用户很不好的用户体验。目前使用下来,淘宝、天猫等这类主流应用都有这种问题,但是我想这应该他们有意为之。







四、节日闪屏


每逢一些节假日,各大品牌都会推出一些当日的闪屏,那么为什么要设计节日闪屏?

我觉得有几点原因:

       长期看常规闪屏,用户很容易会有视觉上的一种疲劳,节日闪屏会给用户一种不经意的惊喜和新鲜感;

       可以蹭一蹭节日的热点,提升产品本身的品牌调性;

       在节日给用户以问候和关怀,和用户在情感上产生共鸣,从而更好的连接用户和产品,我想这应该是最重要的原因。


节日闪屏比较吸引用户的注意力,它不像广告类闪屏,我看见这类闪屏就会忍不住的多瞅几眼,所以设计这类闪屏的时候要非常重视,因为用户愿意等待,这是非常求之不得的,这就需要设计师具有比较强的表现能力了。

我们在设计的时候可以先进行思维上的发散,或者是逆向思维之类的,比如:春节将近,我们可以联想到是什么,理清一个思绪,要有节日的氛围,可以活泼、可爱、夸张…切忌呆板。

 







五、大版本升级闪屏(引导页)


在App进行了大版本升级后,要向用户展示产品新功能的操作方法。这类闪屏也可以称为引导页,页面数量控制在3-5页,每一页都有一个对应的主题,主题要精简,切忌文字过多。


而且每一页设计形式要类似,否则会给用户一种视觉落差感。页面上要加上“跳过”功能,因为用户更希望尽快体验新版本,而不是看你的这些教导,在最后一页要加上类似“立即体验”的button。







——分割线【品牌传达力】——










启动页面告诉用户“我是谁”“我是做什么的”,开头跟用户做了自我介绍,引导页的目的主要是告诉用户:“我该怎么使用”或者是“我有什么亮点”(重点宣传的功能),借用男女相亲例子,双方介绍完自己之后,开始展示自己有什么优势,好的引导页设计直接关系到用户是否“对你有兴趣”想一进“了解你”。

从上图可以看到,引导页在品牌传达力上居首位,其次应用市场说明图。








【引导页展示目的】

以下尽量列举了金融相关app截图,仅供学习使用



引导页定义比较广,往小了讲,我们一般会认为在用户初次打开应用时跳出的几张介绍应用功能的页面就叫做引导页;那往大了说,在用户使用某个功能前就能帮助用户降低学习成本的页面或存在引导属性的弹窗都可以称为引导页。

先从引导页展示的目的出发,再结合实际app情况去确定宣传标题,最后结合不同的设计展示方式以及动效。







一、产品特色介绍


多数时候,我们初次打开应用会看到下面这样的引导页:


可以看到一个共通点——即页面呈现的内容为该 App 的主功能或新功能推荐,或者是对刚迭代的功能做了哪些优化的说明。

理想情况是:用户能了解这次产品做了哪些优化,帮助用户更清晰地了解产品。







二、操作引导


这类引导会出现在内容页面,直接引导用户去操作相关功能

蒙版引导通常紧贴着界面流程进行而出现,使用透明色间隔形式加上简单指示性文字与图形,总是能够简洁明了地告知用户产品的功能或者使用方法,并且由于其轻量的属性会大大减少用户的阅读时间。设计得当的蒙版引导不仅可以与其他引导相辅相成,同时也能够增加用户对产品的好感度。

它的好处就是清晰明了,直接让用户知道你想表达什么。它的实际效果会比纯内容引导页好很多,但同时也会有一个问题,即打扰用户操作。

这样的方式已经解决了内容操作引导的问题,但其实这种方法也会使用户厌倦,所以内容不易过多。







三、理念传达


以传达态度理念,生活方式等为主,比较概念和意义上的东西,吸引用户达到某种程度的共鸣,从而产生吸引力。







四、侧面实力烘托


多用于有实力/特色的产品或者企业,展示自身优势,让用户对产品产生信赖感。










五、问题解决


指出用户所面临的问题,而你的产品正好可以解决。



结合自身app/企业所具有的优势;产品的功能特色;产品的定位;等相应的展示目的。也存在混合展示,不过要把握好标题的设定,在标题与设计上达到统一。








【引导页设计方法】


在确定了引导页展示目的之后,下面整理了在引导页设计过程中的方法。

目前比较常见的几类引导页的类型(电商除外),根据产品的特点来确定设计风格,总体没有固定规则。










一、图文结合


使用有关联性的图片,同种版式,优点是感情表达直观简单,画面冲击感强,缺点是泛表达,不能表达内容。









二、产品界面描述型


功能描述型,使用app画面说明,通常在版本更新时用来对新功能进行重点描述,是目前比较常见的引导页表达方法之一,比较通用。









三、模拟应用场景


通常用插画方式表现,通过图文结合的方式全方位阐述中心思想,插画风格具有丰富的多样性,同时又能贴切表达主题,所以在app中出现频率越来越高。

以下列举了百度金融的版本引导页,通过系列插图表现贴心、安心、用心、省心、随心,插画紧密契合主题,完美使用排比句的形式。











四、吉祥物的运用


一个成熟的app通常会吉祥物来表现,启动页是用户打开app第一眼看到的地方,吉祥物可以让用户在2-3秒时间内深刻体会到产品的核心价值观。












五、代交互 动效的


这类启动页通常是在页面切换中加入一些动效果的设计,使得在交互体验上更加突出,与静态页面间的切换显得更加生动有趣。

动画呈现方式趣味性更高一些,开发成本相对也会高一些。











六、视频类/动画类


这类的理论上不叫启动页,叫开篇动画更贴切,打开app通常为一小段视频或动画引入页面











【实际案例分析】


闪屏/引导页的设计方法很多,但要在设计之前充分考虑到产品定位和应用场景。

下面引用我自己的案例分析,因为对产品理解不够到位,设计过程比较坎坷,经历了几个版本的优化。








【引申思考】


对晋盈汇app来说:

1.用户层面上,在不同版本的情况下需要紧跟不同的用户引导页,尤其这类理财类等APP,使用操作都是比较繁琐,因此需要用户引导帮助用户玩好APP;

2.品牌形象上,可以深化品牌价值,比如提炼产品slogon,吉祥物等,启动页是用户打开app,第一眼看到的地方,需要让用户深刻体会到产品的核心价值观。

3.商业用途上,可以利用启动页配合营销事件,实现商业价值。

4.从技术层面,程序可以利用启动页的2~3秒内,预加载一些东西,使得后面的用户体验更好。


启动页更多的是在启动过程中的2~3秒内,体现app的核心的品牌价值,而品牌价值通常体现在产品的情感化设计上。


情感化设计基于三个基本层次水平:本能水平的设计、行为水平的设计、反思水平的设计。

本能水平的设计——外形(UI界面,整体视觉感受);
行为水平的设计——使用的乐趣和效率(把完成目标前的过程乐趣化,如何最便捷的触达相应功能,或达成某结果);
反思水平的设计——自我形象、个人满意、记忆(强化品牌传播,构建品牌形象,让品牌成为一种文化)。


情感化设计点:登陆界面、启动页、引导页、节日闪屏、404、刷新加载...




强化品牌标识,有利于品牌传播



上图是美团外卖的闪屏,以插画这种具有亲和力的表现手法去搭建一个场景,讲一个小故事隐喻一个情感。然后传递给用户一个主题。而插画下方,则是美团的品牌标识:袋鼠LOGO、文案“美团外卖,送啥都快”。


当你听到电脑发出“滴滴滴”的时候,你就知道这是QQ来消息了,声音也是一种品牌标识。



弥补产品在用户使用过程中发生的意外



上图是ofo共享单车在用户退押金时的三个提示页面,分别是告诉用户ofo的作用是让你便捷轻松出行,退押金后损失的优惠,最后是用利益诱惑你。从三个层面去打用户的痛点。不过确切来说只有第一个界面算是与用户情感化交流,后两个算是再利用人的贪欲。


关于文案的情感化设计要分情况,根据APP所分领域、调性和目标用户人群的特性而定。



转自:站酷-呜呜吉良斯基

如何设计企业级的UI组件库?

雪涛

产品:这次需求很简单,对比上期只有字段和操作项的差异,把上次的稿子直接复制一下应该不用很多时间吧?

交互:上次你是不是做过高级筛选组合?我这期需求要用到,你把那部分稿子发给我用用吧。

研发:这个组件我在其他模块里看到过已有样式,这次为什么用不一样的?不然又要重复开发呀,能不能统一一下。

视觉:同一个按钮在不同的模块颜色不一样诶,这次要和哪个模块一致啊?

……

通过以上对话不难看出,最常出现在需求沟通与研发过程中,由于缺少统一的规范和标准化体系,导致实施环节各方沟通成本高,造成设计成果与实现有一定差距,影响用户体验;通用组件和业务组件混用,导致设计模式和代码复用率低。尤其是当业务发展到一定体量时,对于复杂产品的大量重复且类似的需求场景,如果没有一种的工具和规范来协同工作,将大大影响团队的生产及沟通效率。

问题

  • 认知:产品、研发、设计师对于同一需求都有自己理解的解决方案,缺少统一规范的约束,难以达成共识。
  • 效率:设计效率低,交互原型的维护成本及上下游团队的沟通成本高,易造成不专业的印象。
  • 品质:认知和效率的局限性,最终导致实施落地的产品质量和用户体验难以得到保障。

解决

大家应该都知道乐高(LEGO)积木,它是一种可以互相嵌套组合的塑料积木,形状共有 1300 多种,每种形状都有 12 种不同的颜色,可以拼插出多种造型。其实组件库的工作方式就很像乐高,通过小元件的互相嵌套来产生多种组件或模块,多种组件模块结合生成页面结构。我们先来梳理一个概念,组件库是什么?

组件库是设计系统的一部分,是在我们常规界面设计过程中可以直接用来制作交互图例和搭建页面的组件集合,它可以作为单个组件独立存在,也可以通过多个组件组合而成的结构或模式来解决类似场景的设计问题。组件库是在约束条件下去构建解决方案的过程,所以组件的使用也需遵循一定的规范,按照一套标准化的体系复用于多个业务场景。

一个有效的组件库,可以帮助设计师和研发提高工作效率,提升设计专业度的同时让产品本身的体验更加一致、可学,品牌感更强,它所具备的基本特征一定是通用的、灵活的、复用的。

  • 通用性:意味着足够基础和常见且不带业务属性,参与设计环节的每个人都应该知道这个组件的功能及目的,同时具备一定扩展性。
  • 灵活性:要求元件的组合需灵活,可以在不同场景下通过互相组合来快速搭建交互框架原型图,并根据不同页面结构的演变来适应新的业务需求。
  • 复用性:指的是适用于多个业务或产品,在设计过程和研发过程中都可以高频复用。

那么用组件库这种标准化体系来完成设计方案时,到底能带来怎样的价值?

组件库的价值

保证产品体验的一致性:对于一个含有多业务系统的大型复杂产品,每个独立的业务系统虽然在功能上有一定区别,但整体的用户体验需要满足基本的一致性。比如,当我使用同一个产品中的业务系统 A 和业务系统 B 时,我能通过类似的页面结构、组件及样式的一致性、操作反馈乃至提示文案结构的一致性,来感知到我使用的A、B业务系统隶属于同一个产品。

提升设计师的效率:在需求量巨大且需求来自不同的业务线时,需要逐一绘制页面及组件,造成大量重复劳动,并且在评审及需求沟通环节还可能存在不断地细节调优。所以对于设计师而言,组件的高频复用能大大提升设计效率,使设计师更多的将精力聚焦于理解和解决用户的实际问题。

提升产研团队的效率:通用场景及普通需求直接按规范进行设计和研发,减少上下游对同一页面及组件使用方式的不同理解而产生的多余沟通成本。

利于沉淀设计规范:组件本身的设计和使用方式就可以直接作为交互和视觉规范的一部分,按照统一的设计规范来确定需要使用的主题色、组件样式、组合方式及页面结构,可以快速搭建出一个或多个产品的交互框架。

构建「FishDesign」企业级UI组件库

那么如何构建一个企业级 UI 组件库?

我将用前段时间参与的「FishDesign企业级UI组件库」项目为例,通过在网易七鱼产品中的应用,来介绍一个企业级 UI 组件库的设计原则,内容构成包含哪些类型和元素,每种组件类型在分类和设计过程中是如何考量的。本文侧重讲述构建一个组件库所涵盖的内容,而不是某组件类别本身的设计方法。

顾名思义,「企业级」意味着 FishDesign 所服务的业务都是具备一定体量的,可能是服务一个包含了多个独立子业务系统的大型复杂产品,比如网易七鱼;也可能是同时服务多款产品,比如网易七鱼和网易定位等。

组件库是帮助设计者及前端工程师快速构建业务系统的工具,除了最重要的组件内容,还需要设计原则、配色方案及布局规范来指导具体业务产品的设计有效落地。

1. 设计原则

基于 FishDesign 目前主要是帮助搭建 B 端企业级产品,而 B 端业务的产品目的决定了它所才采取的设计模式,所以我们将用以下四点作为塑造组件库的设计原则:

  • 简洁:如无必要,勿增实体,慎重筛选客户当前需要信息内容。
  • 直接:提供用户操作后的直接反馈,保证用户的操作结果符合预期。
  • 优雅:设计方案追求优雅,给使用者有质感的操作感受。
  • 适应性:设计方案需提供可扩展能力及适应性,以适应不同模式的企业使用。

2. 颜色

产品会根据自身的产品目标和受众群体去选定产品的配色方案。前文提到,一个有效的组件库需满足通用性、灵活性、复用性,像配色方案就应该能被灵活自定义来应对多样化的诉求。以网易七鱼为例(下文均以网易七鱼为例),设置了 1 种主色,4 种辅助色和 6 种中性色来搭建一致的外观感受。

  • 主色:选择蓝色系来传达智能服务、信任可靠、技术创新的品牌形象。
  • 辅助色:除了品牌主色调蓝色,在辅助色中也存在一样的蓝色,那是因为蓝色是相对泛用性较广的色系,用于产品中的主操作按钮、文字按钮或 icon 等。红色唤起注意并昭示危险,所以一般用于谨慎操作及错误提示。黄色则常用于警示信息,提示用户操作可能带来的风险及后果。绿色能传递安全和健康的情绪感受,用于正向反馈提示或成功操作的引导。
  • 中性色:一般采取黑灰色调来展示产品的文本信息、背景和边框色,用来表现层次结构。

3. 布局规范

为处理多业务中网页设计区域内的信息收纳问题,我们用规则的网格阵列来指导和规范版面布局以及信息分布,即栅格系统和页面布局。FishDesign 在 12 栅格系统的基础上,将整个设计区域按照 24 等分的原则进行划分,来增加页面的相似度,提升用户体验。

我们通过基本的配色及布局规范解决了产品风格及信息区块框架的设计,那组件库中重要的组件部分,是如何作用于产品搭建的?Brad Frost 提出的「原子化设计理论」可以帮助我们更好的理解,原子化设计的灵感来自于现实世界当中的分子结构,UI 中颗粒度最小的元素,即「原子」,组成了颗粒度较大的元件,即「分子」;而诸多分子又组成了更加复杂的组件与模块,即「有机体」。

组件库构建之初无法一应俱全,是需要后续不断的维护与迭代的。如何在最初海量组件中圈定适合的组件范围呢?最合适的切入点就是从身边的业务场景出发,从最基本、最简单、最小的元素入手。

4. 组件分类

我们根据当下已有的业务场景和对往后一段时期的业务发展方向进行规划,将组件库的组件类型分为通用组件和业务组件。一般业务组件库是不对外的(毕竟使用场景特殊也有限,放出来参考意义不大),所以在 FishDesign 官网只能看到通用组件部分。

  • 通用组件:指适用范围广、复用频次高,可复用于多个业务且不包含业务逻辑。比如导航栏、按钮、toast、弹窗等。
  • 业务组件:这类组件对比通用组件而言,最大的特点就是包含了较多业务属性,跟产品功能有较强的关联性,所以影响到适用范围可能仅限于 1~2 个业务系统或特殊场景,且复用频次不高。比如网易七鱼的在线和呼叫系统中的咨询分类组件。

一个大型复杂的业务产品通常有不止一位设计师或前端工程师参与设计,需要在多种处理方式中选择合适的设计模式来解决不同的场景问题,这要求根据组件属性的差异,需对通用组件做细分,那么如何确定通用组件中的子分类呢?

  • 竞品学习与研究,穷举该部分产品类型中的组件类型。
  • 遍历自己所负责产品内已有的业务场景,提取并整理业务场景中所用到的组件。
  • 将整理好的两部分组件进行筛选去重,保留高频通用的部分。比如同样是下拉筛选组件,由于缺少统一规范和组件,可能导致的后果就是在同一产品不同业务系统的相同场景下,使用的组件从样式到交互方式都不一致。我们要做的就是对这部分在类似业务场景中使用了多种表达形式的组件做合并去重,然后通过设计组内审来圈定最后通用组件的范围。
  • 基于组件的属性和使用场景,对圈定的组件范围进行归类。

由上述步骤,我们将通用组件继续细分为五个子类别:基础组件、导航、数据录入、数据展示、操作反馈。

  • 基础组件:即按钮、图标等,相较于其他组件的使用场景更通用,或其他组件在实现时依赖了这些组件来实现的组件类别。
  • 导航:即导航菜单、标签、面包屑等,可以帮助用户产品系统内快速找到所在页面层级或位置的组件类别。
  • 数据录入:即输入框、选择器、表单等,支持用户将数据信息录入到系统的组件类别。
  • 数据展示:即图表、表格、气泡卡片等,将录入到系统的数据信息多样化展示出来的组件类别。
  • 操作反馈:即对话框、警告提示(Alert)、全局提示(Toast)等,在用户操作前后,使系统状态得以合理反馈的组件类别。

用组件库设计「网易七鱼」示例

以网易七鱼为例,看下有组件库参与搭建的设计示例,以下页面中所用组件均出自 FishDesign 组件库。

「导航组件」使用示例:

「表格组件」使用示例:

「弹窗组件」使用示例:

「步骤组件」使用示例:

总结

组件库最大的价值在于提升整个团队的产研效率,使设计质量得以保障的同时,提升产品整体的用户体验。

我们对构建企业级 UI 组件库的步骤及要素做个简单回顾:

  • 首先,明确组件库所需解决的问题及存在的价值,这决定组件库的体量和服务范围是什么,以及构建的时机是否合适。
  • 其次,通过竞品分析并结合身边最熟悉或深耕的业务入手,通过产品目的来选择设计模式,从最小元素开始逐步整理,包括产品配色方案和栅格系统等布局规范。
  • 第三,需要对组件库的重要组成部分「组件」,进行圈定及合理分类。这里需要注意的是,组件范围的圈定,尤其在组件库搭建的初级阶段并不是越多越好,而是需要有效的覆盖那些经过规划的业务场景即可。
  • 最后,组件库并不是构建完就结束了,是需要在后续项目中逐步维护与更新的长期积累过程。

任何组件库的构建都离不开一个优秀的团队在整个设计过程中的协同,十分感谢参与的设计师与前端工程师们。上文仅是个人参与过程中的一些经验总结,还不够全面,同时篇幅有限,关于组件的具体设计考量无法一次详尽,欢迎一起讨论组件库及标准化设计体系相关的更多内容。

文章来源:优设

用three.js构建自己的后处理渲染器第一篇---抗锯齿的选择

seo达人

说到渲染引擎就不得不提到延迟渲染,基本上一个引擎如果没有实现延迟渲染就不能说是一个好的渲染引擎,不过可惜的是three.js并没有实现延迟渲染(ps:呼吁作者赶紧实现mrt吧)。由于没有mrt和延迟渲染,本来不打算写后处理的,但是即使没有,我们也希望能实现一些炫酷的效果,那就在现在的基础上对three.js进行简单的改造来实现一套高性能的后处理渲染器吧。

要实现后处理我们首先要考虑需求,是否要兼顾移动端,是否要兼顾大屏(4k),是否要支持webgl1,是否要在各种显卡中都有一个还算不错的性能。目前我主要考虑的是:性能要好,可以兼顾大屏,不打算完美支持webgl1,尽量多使用webgl2的特性。后面所有的性能测试为都以N卡作为性能测试指标,先不管AMD卡(AMD抗锯齿的处理性能会高些的,但是动态处理性能会偏低,这里有很多细节问题)

好了,我们关心的是好的性能,尽量多使用webgl2的特性,尽量能兼顾大屏(这里主要是要注意显存问题),现在开始准备我们的渲染器吧

要完成一个后处理渲染器,我们首先要考虑抗锯齿,常用的有超采样技术和多重采样技术,具体可以看这个介绍 添加链接描述

three.js已经实现了SSAA,SMAA,TAA这三种超采样技术,效果都还不错,具体实现three.js都有例子,就不详细说明了。SSAA抗锯齿效果是最好的,但是性能最差,现实情况下根本无法使用。SMAA性能会好一些,2000个物体差不多掉15帧吧(SMAA比FXAA计算稍微复杂一些,SMAA研究的少,不知道能不能解决line的锯齿问题,如果知道的欢迎留言)。SMAA效果基本可以接受,但是2000个物体掉的帧率还是有点多,这个也不是我们首选的。TAA效果很好,如果场景里面很少动的东西,它是个不错的选择,如果有运动的物体或者动画等等,基本上抗锯齿就没效果了,理论上应该可以实现动态的TAA,但是用目前的技术很难实现。所以TAA先不考虑加入我们的后处理渲染器(真实使用场景下一般都有动画或者贴图流动效果,所以TAA无法使用)。

SMAA:效果不错,开销15帧左右(2000物体)

SSAA:效果最好,开销太大 (2000物体基本已经没有了帧率)





TAA:效果基本和SSAA差不多,但目前只有静止的时候才有效果



再来看看多重采样MSAA,这个特性必须使用webgl2,是webgl提供的方式,和浏览器自身的抗锯齿原理一样,效果不错,和正常渲染的结果没有区别,性能开销也不是太大,前提是我们不要使用stencilbuffer。而且three.js MSAA这块的释放有些小问题,详细可以在deallocateRenderTarget这个接口中进行修改。现在我们可以把MSAA作为主要的抗锯齿技术。MSAA虽然性能开销不大,但是唯一的不足是比较吃显存,如果是大屏,而且显卡不好的话还是容易崩,无法开启。因此我们还要继续选择一个开销小不吃显存的抗锯齿(当然也可以考虑SMAA,目前由于帧率开销较大(2000物体掉了15帧左右),我们不考虑加入SMAA)

MSAA:基本没有帧率开销,效果不错,但是耗费显存(2000物体)



最后的备选方案就是FXAA了,FXAA可以参考这个文章:添加链接描述讲的很详细,FXAA性能开销很小,但是效果很一般,特别是细线的锯齿没法解决,转动摄影机边缘的闪动效果也无法解决,而且还有一个问题是由于FXAA就是靠边缘模糊抗锯齿,所以必然导致画面会略有模糊。但是它最大的好处是开销很小而且不耗费显存,并且集成到后处理渲染器中最简单。但是当显存不足显卡太差的时候它还是个不错的选择。因此需要加入FXAA。

FXAA:效果一般,开销很小,无法解决线的锯齿问题,带来模糊(2000物体)

我们看了下各大引擎,基本每个引擎都实现了FXAA,还有很多引擎实现了FXAA3,FXAA3效果会好一些,但是依然无法解决线的问题。cesium的抗锯齿就是完全采用FXAA3,效果还可以接受,所以目前我们把cesium的fxaa3_11拿过来用,最终引擎选择使用MSAA加FXAA3_11的抗锯齿策略(当然SMAA和TAA也可以选择)。


网页制作如何引入图标

seo达人

HTML中如何引入图标



在头部引用在HTML中里面引用一个东西,。在头部引用<script defer src="https://use.fontawesome.com/releases/v5.0.8/js/all.js"&gt;&lt;/script&gt;

然后在网上搜索font awesome。可以进那个官方(外国网站比较卡)。以下为点进那个中文网–字体图标



点击右上角图标库





3随便点一个进去





4复制<i class="fa fa-address-book-o" aria-hidden="true"></i>

引入你的代码中<span><i class="fa fa-address-book-o" aria-hidden="true"></i>></span>



<div><i class="fa fa-address-book-o" aria-hidden="true"></i>></div>

1

在div或span里引用,可以实现块状元素和行内元素的功能,不用管i标签,改变图标大小用font-size,调上下高度line-height,左右位置text-align。

部分图标可以引用不了,大致样式

3.完美是最无情的禁锢


js reduce()

seo达人

是什么

ES5提供的数组的方法。

reduce() 方法接收一个函数作为回调函数(accumulator),数组中的每个值(从左到右)开始缩减(其实就是从左往右开始对每个数执行回调函数),最终为一个值。



PS: 回调函数的返回结果类型和传入的初始值相同



语法以及参数

arr.reduce(  callback(accumulator, currentValue,index ,array ) ,initialValue )

1

initialValue 可选

如果有的话则作为,第一次调用 callback函数时的第一个参数的值。

如果没有提供初始值,callback则使用数组的第一个元素,作为第一次调用的初始值。

在没有初始值的空数组上调用 reduce 将报错。



accumulator

默认传入上一次调用回调函数的的返回值。

初始值: initialValue存在的话,则是initialValue 若没有则是数组的第一个元素



currentValue

数组中正在处理的元素。



index 可选

数组中正在处理的当前元素的索引。 如果提供了initialValue,则起始索引号为0,否则从索引1起始。



array可选

调用reduce()的数组



一个小小的例子

例1 无initialValue

var  arr = [1, 2, 3, 4, 5];

sum = arr.reduce(function(result, cur, index, arr) {

    console.log(result, cur, index,arr);

    return result+ cur;

})

console.log(sum) // 最后的结果是15



result cur index arr

第1次 1 2 1 [1, 2, 3, 4, 5]

第2次 3 3 2 [1, 2, 3, 4, 5]

第3次 6 4 3 [1, 2, 3, 4, 5]

第4次 10 5 4 [1, 2, 3, 4, 5]

例2 有initialValue 传入10

var  arr = [1, 2, 3, 4, 5];

sum = arr.reduce(function(result, cur, index, arr) {

    console.log(result, cur, index,arr);

    return result+ cur;

},10)

console.log(sum) // 最后的结果是25



result cur index arr

第1次 10 1 0 [1, 2, 3, 4, 5]

第2次 11 2 1 [1, 2, 3, 4, 5]

第3次 13 3 2 [1, 2, 3, 4, 5]

第4次 16 4 3 [1, 2, 3, 4, 5]

第5次 20 5 4 [1, 2, 3, 4, 5]

回调函数的返回值

上面的例子返回的都是一个整型数字,如果希望返回其他类型的数据呢?



这个就跟accumulator的初始值有关系了。

下面的例子我们传入的是一个object {sum: 0}



var items = [0,1,2,3,4];

var reducer = function add(sumT, item) {

  console.log(sumT)

  sumT.sum = sumT.sum + item;

  return sumT;

};

var total = items.reduce(reducer, {sum: 0});

console.log(total); // {sum:1130}



运行结果



 {sum: 0}

 {sum: 1}

 {sum: 3}

 {sum: 6}

 {sum: 10}



reduce()的应用

  1. 数组扁平化

    递归+reduce



    let arr = [1, 2, '3js', [4, 5, [6], [7, 8, [9, 10, 11], null, 'abc'], {age: 12}, [13, 14]], '[]'];



    function flatten(arr) {

      if(Array.isArray(arr)) {

        return arr.reduce((prev, cur) => {

           // 如果遍历的当前项是数组,递归调用flatten

          return Array.isArray(cur) ? prev.concat(flatten(cur)) : prev.concat(cur)

        }, [])

      } else {

        throw new Error(' 当前参数不是数组')

      }

    }

    console.log(flatten(arr));



    PS:这里的throw new Error只是用来判断一开始的arr,这是因为在递归只传入数组。


案例分享:RARRA模型下,如何做用户增长?

雪涛

本文作者结合实际案例,跟大家分享一下在RARRA模型下,如何做用户增长?

从AARRR到RARRA的运营思路转变

众所周知,AARRR经典的增长黑客体系,也称之为「海盗法则」,分别是获取、激活、留存、变现以及推荐。提出这个模型的 Dave McClure 认为,所有创新型、成长型的企业都应该按照这样的模型来做增长。

AARRR专注于获客(Acquisition),作为一个2007年提出的概念, AARRR模型可能已经不再适用互联网运营这个瞬息万变的场景。原因有二:

(1)获客成本增加

市场竞争激烈,用户获客成本已经不再便宜,一组数据显示:阿里线上获客的成本翻了 6 倍, 京东的获客成本翻了 1.5 倍,趣头条用户获取成本增加了 8 倍,百度的流量获取成本增长了 41%。在当前的情况下,以拉新获客为中心的增长模式意味着要比十年前这个模型提出时平均增加5倍以上的成本。

(2)流失率高

一组数据显示,现在平均每个App在安装后的情况:前3天内将流失掉77%的DAU。在30天内,它将流失90%的DAU。而到了90天,流失率跃升到95%以上。不管你是否心存怀疑,这就是目前众多创业公司所面对的现实窘境,它创造了Brian Balfour所说的“无意义成长之轮”。

因为以上两个原因,现在黑客增长的真正关键在于用户留存,而不是获客。所以我们需要一个更好的模型——就是RARRA模型。

AARRR与RARRA的区别

RARRA模型是托马斯·佩蒂特Thomas Petit和贾博·帕普Gabor Papp对于海盗指标-AARRR模型的优化,RARRA模型突出了用户留存的重要性。

简单的说,AARRR模型的核心在于获客,而在RARRA的模型下,专注用户的留存。

RARRA模型下,如何做用户增长?(成功案例分享)

分享一个我们前不久自己做的RARRA模型下用户增长的成功案例:

我们做的是一个在线教育平台,课程的分类包括:

  • 以拉新为目的的新用户免费体验课(0元);
  • 以转化为目的的低价专题课(50元以内);
  • 以盈利为目的的短期班课(999元以内)和系统课(1000-4000元)。

这样的课程显然是以拉新-留存-转化个流程进行的设计,也是现在很多在线教育平台通用的课程模式设计,其实本质上和其他行业的平台也是类似。

在RARRA的模型下,数据驱动更重要。因为如果专注获客,可以在渠道选择等方面凭借经验和主观判断来选择,但是专注留存,就必须用数据分析找出每个留存环节的差异因素,进而制定最的方案大幅度提升留存率。在在线教育平台的运营中,因为从推广到课程设计、课程质量、售前售后服务等,包含大量影响营收的因素,因此数据分析方法也相对复杂。

数据分析的第一步,也是关键点在于:构建指标体系。

对于一个平台来说,一般的数据指标都非常多,但必须确定唯一关键指标(OMTM),也是大家常说的北极星指标,作为驱动的方向。

回归商业本质,一切商业模式的终极目标当然是收入,但是收入这个指标并非北极星指标,而是决定北极星指标的上级因素。如下图所示,平台收入=有效听课用户数*客单价。因为课程的客单价有大致的市场标准,不会做太多变动。因此经过分析,我们认为直播课程运营的北极星指标是——有效听课用户数,也就是购买了课程并且有效听课的用户数量。

那么接下来,就要对北极星指标进行分解。

从指标拆解来看:

  • 有效听课用户中的新用户数=外部流量导入*转化率;
  • 有效听课用户中的老用户数=老用户数*续报率。

在最后分解的四个指标中,除了老用户数是直接由新用户转化率决定的之外,流量、转化率、续报率三个指标都是可以通过运营来提升和改善的。

但是由于时间和资源的限制,对于三个指标,运营策略上肯定会有侧重点和先后顺序。

一开始,我们采用的是AARRR模型,把重点放在提升流量和新用户转化率上。通过广告投放、拉新红包等大量引流,并在课程设计上做了很多设计促进新用户转化率。最后流量和转化率都提升了,但问题是,用户停留在0元免费课和低价转化课上,而续报高价课的有效用户很少,这样看似产品新增用户很多,热热闹闹,但整体的营收还是上不去。

团队分析后认为,AARRR模型可能并不适合我们。既然续课率出了问题,应该尝试采用RARRA模型,把运营重点放在留存上。

于是,数据组开始探索留存的问题点出现在哪里。

我们拉出不同维度用户数据进行对比,最后发现新用户和老用户的续课率差值竟高达53%。

也就是说,新用户进行初步低价课转化后,在从低价课到达正价课的留存续课阶段,是流失最严重的一块。

找到了最痛的点,问题其实已经解决了一半。

接下来,通过各种数据因素分析,我们判断出了影响新用户续课率的几个重点因素,分别是:用户来源、课前服务、课程质量。并且对每一个因素继续分解深挖。(标红为续课率效果最好)

  • 在课程质量方面,三个细分数据指标综合可以衡量课程质量。
  • 课前服务时间上,通过数据对比,我们发现课前两周进行服务的效果最好,续课率也最高。
  • 用户来源上,短期班课的用户续课率远高于其他两个来源。

根据以上的数据分析,给出了运营策略指导为:

  1. 教师和教研团队狠抓课程质量,改变以前主观评价模式。用出勤率、完课率和作业完成率三者综合考核教师KPI;
  2. 助教团队的课程服务时间前置,从以前的课前一周和课后进行服务,改为课前两周开始进行用户服务;
  3. 服务人群的重点转移到短期班课新用户上。

改进后的效果:

通过以上三个方向的运营策略调整,同样的团队,仅用了一个月的时间,就把新老用户续课率的差值从53%缩小到了9%!效果非常明显。同时平台整体收入也大幅增加,而运营成本却比以前大规模进行渠道投放大大节省了。

阶段性的成功,正是及时调整了用户增长模型,并采用系统的数据分析方法驱动用户增长。可以看出,数据驱动下,最终给出的运营策略非常简洁,但前面数据组背后付出的努力和精力是很难被看到的。这正是我们想要的结果,扎根稳且深入,但呈现的却是简洁明了的运营指令。

日历

链接

blogger

蓝蓝 http://www.lanlanwork.com

存档