292020-4

函數(shù)節(jié)流與函數(shù)防抖的區(qū)別

函數(shù)節(jié)流與函數(shù)防抖是我們解決頻繁觸發(fā)DOM事件的兩種常用解決方案，但是經(jīng)常傻傻分不清楚。。。這不，在項(xiàng)目中又用遇到了，在此處記錄一下

函數(shù)防抖 debounce

原理：將若干函數(shù)調(diào)用合成為一次，并在給定時(shí)間過(guò)去之后，或者連續(xù)事件完全觸發(fā)完成之后，調(diào)用一次(僅僅只會(huì)調(diào)用一次?。。。。。。。。。?。

舉個(gè)栗子：滾動(dòng)scroll事件，不?；瑒?dòng)滾輪會(huì)連續(xù)觸發(fā)多次滾動(dòng)事件，從而調(diào)用綁定的回調(diào)函數(shù)，我們希望當(dāng)我們停止?jié)L動(dòng)的時(shí)，才觸發(fā)一次回調(diào)，這時(shí)可以使用函數(shù)防抖。

原理性代碼及測(cè)試：

// 給盒子較大的height，容易看到效果

<style>

* {

padding: 0;

margin: 0;

}

.box {

width: 800px;

height: 1200px;

}

</style>

<body>

<div class="container">

<div class="box" style="background: tomato"></div>

<div class="box" style="background: skyblue"></div>

<div class="box" style="background: red"></div>

<div class="box" style="background: yellow"></div>

</div>

<script>

window.onload = function() {

const decounce = function(fn, delay) {

let timer = null

return function() {

const context = this

let args = arguments

clearTimeout(timer) // 每次調(diào)用debounce函數(shù)都會(huì)將前一次的timer清空，確保只執(zhí)行一次

timer = setTimeout(() => {

fn.apply(context, args)

}, delay)

}

}

let num = 0

function scrollTap() {

num++

console.log(看看num吧 ${num})

}

// 此處的觸發(fā)時(shí)間間隔設(shè)置的很小

document.addEventListener('scroll', decounce(scrollTap, 500))

// document.addEventListener('scroll', scrollTap)

}

</script>

</body>

此處的觸發(fā)時(shí)間間隔設(shè)置的很小，如果勻速不間斷的滾動(dòng)，不斷觸發(fā)scroll事件，如果不用debounce處理，可以發(fā)現(xiàn)num改變了很多次，用了debounce函數(shù)防抖，num在一次上時(shí)間的滾動(dòng)中只改變了一次。

調(diào)用debouce使scrollTap防抖之后的結(jié)果：

直接調(diào)用scrollTap的結(jié)果：

補(bǔ)充：瀏覽器在處理setTimeout和setInterval時(shí)，有最小時(shí)間間隔。

setTimeout的最短時(shí)間間隔是4毫秒；

setInterval的最短間隔時(shí)間是10毫秒，也就是說(shuō)，小于10毫秒的時(shí)間間隔會(huì)被調(diào)整到10毫秒。

事實(shí)上，未優(yōu)化時(shí)，scroll事件頻繁觸發(fā)的時(shí)間間隔也是這個(gè)最小時(shí)間間隔。

也就是說(shuō)，當(dāng)我們?cè)赿ebounce函數(shù)中的間隔事件設(shè)置不恰當(dāng)（小于這個(gè)最小時(shí)間間隔），會(huì)使debounce無(wú)效。

函數(shù)節(jié)流 throttle

原理：當(dāng)達(dá)到了一定的時(shí)間間隔就會(huì)執(zhí)行一次；可以理解為是縮減執(zhí)行頻率

舉個(gè)栗子：還是以scroll滾動(dòng)事件來(lái)說(shuō)吧，滾動(dòng)事件是及其消耗瀏覽器性能的，不停觸發(fā)。以我在項(xiàng)目中碰到的問(wèn)題，移動(dòng)端通過(guò)scroll實(shí)現(xiàn)分頁(yè)，不斷滾動(dòng)，我們不希望不斷發(fā)送請(qǐng)求，只有當(dāng)達(dá)到某個(gè)條件，比如，距離手機(jī)窗口底部150px才發(fā)送一個(gè)請(qǐng)求，接下來(lái)就是展示新頁(yè)面的請(qǐng)求，不停滾動(dòng)，如此反復(fù)；這個(gè)時(shí)候就得用到函數(shù)節(jié)流。

原理性代碼及實(shí)現(xiàn)

// 函數(shù)節(jié)流 throttle

// 方法一：定時(shí)器實(shí)現(xiàn)

const throttle = function(fn,delay) {

let timer = null

return function() {

const context = this

let args = arguments

if(!timer) {

timer = setTimeout(() => {

fn.apply(context,args)

clearTimeout(timer)

},delay)

}

}

}

// 方法二：時(shí)間戳

const throttle2 = function(fn, delay) {

let preTime = Date.now()

return function() {

const context = this

let args = arguments

let doTime = Date.now()

if (doTime - preTime >= delay) {

fn.apply(context, args)

preTime = Date.now()

}

}

}

需要注意的是定時(shí)器方法實(shí)現(xiàn)throttle方法和debounce方法的不同：

在debounce中：在執(zhí)行setTimeout函數(shù)之前總會(huì)將timer用setTimeout清除，取消延遲代碼塊，確保只執(zhí)行一次

在throttle中：只要timer存在就會(huì)執(zhí)行setTimeout，在setTimeout內(nèi)部每次清空這個(gè)timer，但是延遲代碼塊已經(jīng)執(zhí)行啦，確保一定頻率執(zhí)行一次

我們依舊可以在html頁(yè)面中進(jìn)行測(cè)試scroll事件，html和css代碼同debounce，此處不贅述，運(yùn)行結(jié)果是（可以說(shuō)是一場(chǎng)漫長(zhǎng)的滾輪滾動(dòng)了）：

最后再來(lái)瞅瞅項(xiàng)目中封裝好的debounce和throttle函數(shù)，可以說(shuō)是很優(yōu)秀了，考慮的特別全面，希望自己以后封裝的函數(shù)也能考慮的這么全面吧，加油！

/*

空閑控制返回函數(shù)連續(xù)調(diào)用時(shí)，空閑時(shí)間必須大于或等于 wait，func 才會(huì)執(zhí)行

@param {function} func 傳入函數(shù)，最后一個(gè)參數(shù)是額外增加的this對(duì)象，.apply(this, args) 這種方式，this無(wú)法傳遞進(jìn)函數(shù)

@param {number} wait 表示時(shí)間窗口的間隔

@param {boolean} immediate 設(shè)置為ture時(shí)，調(diào)用觸發(fā)于開(kāi)始邊界而不是結(jié)束邊界

@return {function} 返回客戶調(diào)用函數(shù)

/

const debounce = function(func, wait, immediate) {

let timeout, args, context, timestamp, result;

const later = function() {

// 據(jù)上一次觸發(fā)時(shí)間間隔

let last = Number(new Date()) - timestamp;

// 上次被包裝函數(shù)被調(diào)用時(shí)間間隔last小于設(shè)定時(shí)間間隔wait

if (last < wait && last > 0) {

timeout = setTimeout(later, wait - last);

} else {

timeout = null;

// 如果設(shè)定為immediate===true，因?yàn)殚_(kāi)始邊界已經(jīng)調(diào)用過(guò)了此處無(wú)需調(diào)用

if (!immediate) {

result = func.call(context, ...args, context);

if (!timeout) {

context = args = null;

}

}

}

};

return function(..._args) {

context = this;

args = _args;

timestamp = Number(new Date());

const callNow = immediate && !timeout;

// 如果延時(shí)不存在，重新設(shè)定延時(shí)

if (!timeout) {

timeout = setTimeout(later, wait);

}

if (callNow) {

result = func.call(context, ...args, context);

context = args = null;

}

return result;

};

};

/*

頻率控制返回函數(shù)連續(xù)調(diào)用時(shí)，func 執(zhí)行頻率限定為次 / wait

@param {function} func 傳入函數(shù)

@param {number} wait 表示時(shí)間窗口的間隔

@param {object} options 如果想忽略開(kāi)始邊界上的調(diào)用，傳入{leading: false}。

如果想忽略結(jié)尾邊界上的調(diào)用，傳入{trailing: false}

@return {function} 返回客戶調(diào)用函數(shù)

*/

const throttle = function(func, wait, options) {

let context, args, result;

let timeout = null;

// 上次執(zhí)行時(shí)間點(diǎn)

let previous = 0;

if (!options) options = {};

// 延遲執(zhí)行函數(shù)

let later = function() {

// 若設(shè)定了開(kāi)始邊界不執(zhí)行選項(xiàng)，上次執(zhí)行時(shí)間始終為0

previous = options.leading === false ? 0 : Number(new Date());

timeout = null;

result = func.apply(context, args);

if (!timeout) context = args = null;

};

return function(..._args) {

let now = Number(new Date());

// 首次執(zhí)行時(shí)，如果設(shè)定了開(kāi)始邊界不執(zhí)行選項(xiàng)，將上次執(zhí)行時(shí)間設(shè)定為當(dāng)前時(shí)間。

if (!previous && options.leading === false) previous = now;

// 延遲執(zhí)行時(shí)間間隔

let remaining = wait - (now - previous);

context = this;

args = _args;

// 延遲時(shí)間間隔remaining小于等于0，表示上次執(zhí)行至此所間隔時(shí)間已經(jīng)超過(guò)一個(gè)時(shí)間窗口

// remaining大于時(shí)間窗口wait，表示客戶端系統(tǒng)時(shí)間被調(diào)整過(guò)

if (remaining <= 0 || remaining > wait) {

clearTimeout(timeout);

timeout = null;

previous = now;

result = func.apply(context, args);

if (!timeout) context = args = null;

//如果延遲執(zhí)行不存在，且沒(méi)有設(shè)定結(jié)尾邊界不執(zhí)行選項(xiàng)

} else if (!timeout && options.trailing !== false) {

timeout = setTimeout(later, remaining);

}

return result;

};

};

評(píng)論(0) 瀏覽(2736)

282020-4

超簡(jiǎn)單入門(mén)Vuex小示例

seo達(dá)人

寫(xiě)在前面

本文旨在通過(guò)一個(gè)簡(jiǎn)單的例子，練習(xí)vuex的幾個(gè)常用方法，使初學(xué)者以最快的速度跑起來(lái)一個(gè)vue + vuex的示例。

學(xué)習(xí)vuex需要你知道vue的一些基礎(chǔ)知識(shí)和用法。相信點(diǎn)開(kāi)本文的同學(xué)都具備這個(gè)基礎(chǔ)。

另外對(duì)vuex已經(jīng)比較熟悉的大佬可以忽略本文。

生成基于vue的項(xiàng)目

基于vue-cli腳手架生成一個(gè)vue項(xiàng)目
常用npm命令：

npm i vue-vli -g vue --version vue init webpack 項(xiàng)目名

進(jìn)入項(xiàng)目目錄，使用npm run dev先試著跑一下。

一般不會(huì)出現(xiàn)問(wèn)題，試跑成功后，就可以寫(xiě)我們的vuex程序了。

使用vue完成的示例

使用vuex首先得安裝vuex，命令：

npm i vuex --save

介紹一下我們的超簡(jiǎn)單Demo，一個(gè)父組件，一個(gè)子組件，父組件有一個(gè)數(shù)據(jù)，子組件有一個(gè)數(shù)據(jù)，想要將這兩個(gè)數(shù)據(jù)都放置到vuex的state中，然后父組件可以修改自己的和子組件的數(shù)據(jù)。子組件可以修改父組件和自己的數(shù)據(jù)。

先放效果圖，初始化效果如下：

如果想通過(guò)父組件觸發(fā)子組件的數(shù)據(jù)，就點(diǎn)“改變子組件文本”按鈕，點(diǎn)擊后效果如下：

如果想通過(guò)子組件修改父組件的數(shù)據(jù)，就在子組件點(diǎn)擊“修改父組件文本”按鈕，點(diǎn)擊后效果如下：

代碼文件介紹

首先是Parent.vue組件

<template> <div class="parent"> <h3>這里是父組件</h3> <button type="button" @click="clickHandler">修改自己文本</button> <button type="button" @click="clickHandler2">修改子組件文本</button> <div>Test: {{msg}}</div> <child></child> </div> </template> <script> import store from '../vuex' import Child from './Child.vue' export default { computed: {
            msg(){ return store.state.testMsg;
            }
        }, methods:{
            clickHandler(){
                store.commit('changeTestMsg', '父組件修改自己后的文本')
            },
            clickHandler2(){
                store.commit('changeChildText', '父組件修改子組件后的文本')
            }
        }, components:{ 'child': Child
        },
        store,
    } </script> <style scoped> .parent{ background-color: #00BBFF; height: 400px;
    } </style>

下面是Child.vue子組件

<template> <div class="child"> <h3>這里是子組件</h3> <div>childText: {{msg}}</div> <button type="button" @click="clickHandler">修改父組件文本</button> <button type="button" @click="clickHandler2">修改自己文本</button> </div> </template> <script> import store from '../vuex' export default { name: "Child", computed:{
            msg(){ return store.state.childText;
            }
        }, methods: {
            clickHandler(){
                store.commit("changeTestMsg", "子組件修改父組件后的文本");
            },
            clickHandler2(){
                store.commit("changeChildText", "子組件修改自己后的文本");
            }
        },
        store
    } </script> <style scoped> .child{ background-color: palegreen; border:1px solid black; height:200px; margin:10px;
    } </style>

最后是vuex的配置文件

 import Vue from 'vue' import Vuex from 'vuex';

Vue.use(Vuex) const state = { testMsg: '原始文本', childText:"子組件原始文本" } const mutations = {
    changeTestMsg(state, str){
        state.testMsg = str;
    },
    changeChildText(state, str){
        state.childText = str;
    }

} const store = new Vuex.Store({ state: state, mutations: mutations
}) export default store;

后記

通過(guò)該vuex示例，了解vuex的常用配置及方法調(diào)用。希望對(duì)不怎么熟悉vuex的同學(xué)快速上手vuex項(xiàng)目有點(diǎn)幫助。

因?yàn)闆](méi)太多東西，我自己也是剛接觸，本例就不往GitHub扔了，如果嘗試了本例，但是沒(méi)有跑起來(lái)的同學(xué)，可以一起交流下。

評(píng)論(0) 瀏覽(2815)

282020-4

為何深色模式看起來(lái)不自然？

ui設(shè)計(jì)分享達(dá)人

為何深色模式看起來(lái)不自然？它的實(shí)用性到底怎么樣？深色模式是不是對(duì)眼睛更健康？結(jié)合文獻(xiàn)，我們一起來(lái)探究深色模式的種種！

在過(guò)去的幾年中，深色模式一直是用戶最期待的一個(gè)功能。你可以自由切換你喜歡的模式來(lái)適應(yīng)當(dāng)前的場(chǎng)景，iOS和Android也都在2019年布局了系統(tǒng)級(jí)的深色模式，深色模式可獲得出色的視覺(jué)體驗(yàn)，尤其是在弱光環(huán)境中……有助于你專(zhuān)注地開(kāi)展工作，因?yàn)閮?nèi)容會(huì)較為顯眼，而顏色加深的控制項(xiàng)和窗口則會(huì)隱入背景之中。但真是這樣嗎，或者只是一種實(shí)際上弊大于利的操作？

文章內(nèi)容：

1、什么是深色模式

2、從可用性角度看深色模式

3、為什么深色模式看起來(lái)不自然

4、從設(shè)計(jì)角度看深色模式

5、結(jié)論

什么是深色模式？

雖然各種軟件界面的色調(diào)和顏色會(huì)有所不同，但是對(duì)深色模式的處理方式都是在深色背景上顯示明亮文本和界面元素的配色方案。相比之下，在淺色背景上顯示深色文本和界面元素的配色方案，在這里我們稱之為淺色模式。

而事實(shí)上，深色模式比淺色模式早了幾十年。在其最初的階段，深色模式并不是一種有意的解決方案，而僅僅是當(dāng)時(shí)計(jì)算顯示設(shè)備是陰極射線管（CRT），且只能顯示單色的顯示，屏幕看上去就是黑的，黑底白字或者黑底綠字就是計(jì)算機(jī)行業(yè)的早期狀態(tài)。直到1980年代彩色顯示器發(fā)明后，微軟視窗系統(tǒng)上線之后，黑底顯示才退出主流。蘋(píng)果在1984年推出“麥金塔”個(gè)人電腦，第一次發(fā)布采用圖形用戶界面，由此開(kāi)啟了計(jì)算機(jī)屏幕白底顯示的主流之路。

ibm 5151單色監(jiān)視器

淺色模式出現(xiàn)的確切時(shí)間很難確定，但可以追溯到施樂(lè)Parc圖形用戶界面，它也極大地影響了早期蘋(píng)果的“麥金塔”和其他操作系統(tǒng)，該界面使用了以白色背景為主的深色文本和界面元素。它與顯示技術(shù)的進(jìn)步和現(xiàn)代圖形用戶界面的出現(xiàn)密切相關(guān)。這種能夠顯示色彩的且更先進(jìn)的RGB CRT顯示器拉開(kāi)了淺色模式的序幕。

1973年的施樂(lè)Alto是最早使用輕型接口模式的計(jì)算機(jī)之一

從可用性角度看深色模式

深色模式的實(shí)用性有多少，每個(gè)人看法也不一樣。盡管深色模式的界面可能不像淺色模式那樣觀感清晰，但深色模式的界面卻具有一定的魅力，可以讓你聯(lián)想到新穎，高端，精致，神秘，力量，奢華這些詞。但是，黑色也是一種會(huì)引起人們強(qiáng)烈的情感一個(gè)顏色，并且在過(guò)度使用時(shí)很容易使人無(wú)法承受。

2019年9月，蘋(píng)果公司上線深色模式（Dark Model）時(shí)，在官網(wǎng)上如是宣傳道。從iPhone到Mac，當(dāng)庫(kù)克決定在蘋(píng)果公司幾乎所有產(chǎn)品上線深色模式、甚至要求所有在AppStore上架的應(yīng)用都必須兼容深色模式時(shí)，安卓陣營(yíng)的谷歌、華為、三星等頭部公司也紛紛在其手機(jī)中推出了深色模式，相應(yīng)地從WhatsApp到微信等全球主流的應(yīng)用也都推出了深色模式。

但是，想要獲得良好的深色模式是相對(duì)比較難的。一方面，深色模式迫使放大瞳孔來(lái)捕獲必要的視覺(jué)信息，從而導(dǎo)致整體清晰度的降低。而同時(shí)界面中高亮的部分又迫使我們的瞳孔縮小去適應(yīng)亮度，以便提高清晰度。這也就能理解為什么白色背景上的黑色文本在你的眼睛中通常會(huì)顯得更清晰的原因。

擴(kuò)大的瞳孔讓光線更多，但感覺(jué)到的銳度受到損害

行業(yè)對(duì)深色模式追逐的群羊效應(yīng)，也進(jìn)一步加劇、放大了一個(gè)見(jiàn)解：深色模式對(duì)眼睛更友好更健康！

但是，事實(shí)并非如此。對(duì)于一些有散光的人來(lái)說(shuō)，在某種程度上深色模式對(duì)他們的眼睛來(lái)說(shuō)更糟糕，深色模式比淺色模式更友好更健康的科學(xué)仍有待討論。斯坦?！ぐ轄査寡劭蒲芯克难劭茖?zhuān)家對(duì)此表示：“鑒于文獻(xiàn)中的數(shù)據(jù)，我認(rèn)為深色模式對(duì)眼睛沒(méi)有任何的友好和健康?！?nbsp;這種深色模式對(duì)眼睛疲勞和潛在的眼睛健康的影響時(shí)，使用時(shí)間可能比設(shè)備的亮度或亮度更重要。

根據(jù)美國(guó)驗(yàn)光協(xié)會(huì)的說(shuō)法稱，大多數(shù)人的眼睛在某種程度上都患有散光，但通常不會(huì)引起注意。據(jù)美國(guó)眼科學(xué)院統(tǒng)計(jì)，每三個(gè)美國(guó)人中就一個(gè)存在散光的情況，1.5億美國(guó)人需要佩戴眼鏡來(lái)矯正視力；香港理工大學(xué)針對(duì)2700多人的臨床檢測(cè)發(fā)現(xiàn)，在21歲的30歲的香港人中，近40%以上患有100度以上散光。

一起看下面的說(shuō)明性圖像。即使你有完美的視覺(jué)，你也很可能在黑色背景上看到白色文字周?chē)墓鈺灐?

淺色模式與深色模式

如果增加文字并降低文字的大小，這種效果可能會(huì)更強(qiáng)：

右邊的圖像你應(yīng)該會(huì)看到更多的光暈，如果你有散光癥狀，深色模式可能會(huì)讓你看屏幕更費(fèi)勁。在深色模式下，虹膜打開(kāi)以接收更多的光，并且瞳孔的變形在眼睛上產(chǎn)生了更加模糊的焦點(diǎn)，因此，當(dāng)你在深色屏幕上看到淺色文本時(shí)，其邊緣似乎滲入黑色背景，也就是所謂的“光暈效果”。雖然深色模式可能更適合夜晚等弱光環(huán)境下使用，但不一定能幫助更好地閱讀，對(duì)于散光患者來(lái)說(shuō)，可能還會(huì)加劇視疲勞。

當(dāng)然，從實(shí)用性上講，深色模式也有它的好處，深色模式利用OLED屏幕在純黑的背景下不發(fā)光的特性，確實(shí)能有效的省電，讓你的電子設(shè)備續(xù)航上提升很大，這也是很多人一直在追求深色模式的一個(gè)重要原因，只要手機(jī)續(xù)航強(qiáng)比啥都重要！這也可能是蘋(píng)果公司決定在幾乎所有產(chǎn)品上線深色模式的一個(gè)原因。

另外深色模式更有利于給用戶營(yíng)造一種沉浸體驗(yàn)，對(duì)于視覺(jué)娛樂(lè)應(yīng)用尤為如此。當(dāng)你想突出顯示特定類(lèi)型的內(nèi)容時(shí)，深色模式會(huì)特別有用。豆瓣、數(shù)字尾巴、網(wǎng)易云音樂(lè)是我常用的幾個(gè)軟件，它們都已經(jīng)適配了深色模式。在這種模式下你的目光會(huì)更加注意到電影的海報(bào)、數(shù)碼產(chǎn)品和充滿活力的音樂(lè)專(zhuān)輯上。

豆瓣、數(shù)字尾巴、網(wǎng)易云音樂(lè)的深色模式

為什么深色模式看起來(lái)不自然

一是由于我們?nèi)四X的組織結(jié)構(gòu)造成的，從多年來(lái)的多項(xiàng)科學(xué)研究和調(diào)查得出的結(jié)論是，從物種進(jìn)化來(lái)看，人類(lèi)99%的時(shí)間都是在白天中活動(dòng)，人腦更傾向于在淺的背景上顯示深色的圖像。所以無(wú)論白天還是黑夜，淺色的背景都可以讓你更快地專(zhuān)注于顯示的元素，而深色的背景則使其難以辨別文字和視覺(jué)界面元素，從而影響你的閱讀效果并最終使你的眼睛疲勞。其實(shí)從世界各地多個(gè)洞穴中發(fā)現(xiàn)的史前壁畫(huà)也能說(shuō)明為什么我們傾向于喜歡淺色模式。

追逐獵物的獅子，法國(guó)Chauvet Cave，約公元前30,000-28,000

德國(guó)帕紹大學(xué)曾經(jīng)做過(guò)一次測(cè)試。在該研究要求參與者閱讀屏幕上的正極性（白色背景上的黑色文本）或負(fù)極性（黑色背景上的白色文本）的文本。隨后，參與測(cè)試的人員會(huì)執(zhí)行基本的校對(duì)任務(wù)，例如查找拼寫(xiě)或語(yǔ)法錯(cuò)誤。研究人員還測(cè)量了每種模式下參與者的閱讀速度。結(jié)果是所有參與者在正極性條件下的表現(xiàn)都會(huì)更好，他們檢查出更多的錯(cuò)誤以及閱讀的速度更快。

可讀性差異

另一個(gè)學(xué)習(xí)發(fā)現(xiàn)正極性對(duì)于在顯示器上讀取小文本特別有利。人腦具有更快的可讀性，更喜歡在光線背景下顯示的深色文本和物體。

二是由于含有大量藍(lán)光的光源會(huì)使我們眼睛不舒服，當(dāng)我們談?wù)撈聊粚?duì)眼睛的潛在破壞性影響時(shí)，我們通常是在談?wù)摗八{(lán)光”，這是由短、高能量波長(zhǎng)構(gòu)成的光譜的一部分。研究發(fā)現(xiàn)藍(lán)光可能是導(dǎo)致眼睛疲勞的一個(gè)因素，但指出長(zhǎng)時(shí)間不眨眼的干眼也是導(dǎo)致眼睛疲勞的一個(gè)更嚴(yán)重的原因，當(dāng)然也有是因?yàn)樽煮w太小，以及散光這樣的原因。

當(dāng)我們身處暗室或是在黃昏或夜晚時(shí)，眼睛會(huì)切換成不同的視覺(jué)模式；在弱光環(huán)境下，人眼會(huì)從對(duì)綠色敏感變成對(duì)高能量藍(lán)光敏感，這代表我們?cè)诖罅康慕邮账{(lán)光，因此對(duì)刺眼強(qiáng)光的敏感度會(huì)增強(qiáng)。這類(lèi)情形對(duì)駕駛?cè)硕圆⒉荒吧?，?dāng)他們被來(lái)車(chē)車(chē)頭燈的強(qiáng)光照射時(shí)，特別是使用現(xiàn)代化氙氣燈或LED頭燈的車(chē)輛，可能會(huì)暫時(shí)喪失視力。

平板電腦、智能手機(jī)和其他電子顯示屏，不僅改變了我們所接觸的光譜，也使我們的視覺(jué)行為發(fā)生轉(zhuǎn)變。我們必須意識(shí)到，我們現(xiàn)在用于“近距離”視物的時(shí)間比以往多得多，這通常是因?yàn)楸尘傲炼忍邓隆?

在德國(guó)光學(xué)公司蔡司官方網(wǎng)站上，對(duì)于藍(lán)光也作一分為二的評(píng)價(jià)：“好處是當(dāng)外界環(huán)境變亮也就是藍(lán)光較多時(shí)，身體便釋放出血清素—它是其中一種快樂(lè)荷爾蒙以及皮質(zhì)醇—這是一種壓力荷爾蒙。這兩種荷爾蒙能讓我們保持清醒，富有活力，同時(shí)也應(yīng)用于冬季抑郁和失眠的治療中。但過(guò)多的紫外光和藍(lán)紫光可能會(huì)對(duì)肉眼造成損傷，除了可能導(dǎo)致令人難受的結(jié)膜和角膜發(fā)炎，也可能會(huì)破壞眼睛的晶狀體（例如白內(nèi)障），尤其是傷害我們的視網(wǎng)膜（黃斑病變）?！?

從設(shè)計(jì)角度看深色模式

在WWDC 2019大會(huì)上，蘋(píng)果宣布了iOS13的深色模式功能，在令人興奮之余，作為設(shè)計(jì)師和開(kāi)發(fā)人員，我們應(yīng)該考慮的該如何去實(shí)現(xiàn)它。蘋(píng)果和安卓已經(jīng)發(fā)布了為應(yīng)用程序設(shè)計(jì)深色模式的設(shè)計(jì)指南。當(dāng)然，沒(méi)有硬性規(guī)定要求遵循他們提供的設(shè)計(jì)指南，這些只是指導(dǎo)原則。

由于Material Design設(shè)計(jì)語(yǔ)言的原因，投影的占比是非常大的。在淺色模式下還好，但這不太適用于深色模式，因?yàn)樯钌尘吧系暮谏幱霸谝曈X(jué)上不容易察覺(jué)，為此安卓還提供了在深色模式下不同層級(jí)的卡片與投影上的參考。

根據(jù)設(shè)計(jì)文檔來(lái)看，iOS背景為純黑色，色值為＃000000，Google 則更喜歡深灰色，色值為＃121212。

通過(guò)提供的設(shè)計(jì)指南，我們可以輕易上手來(lái)設(shè)計(jì)和開(kāi)發(fā)我們的軟件，但要注意的是深色模式并不是簡(jiǎn)單的與淺色模式顏色對(duì)調(diào)，必須為所有的元素進(jìn)行單獨(dú)配色。

淺色模式下的白色不會(huì)在深色模式下轉(zhuǎn)換成純黑色

這樣也就能理解為什么很多軟件并沒(méi)有全部去適配新的深色模式，一方面使用場(chǎng)景決定的，另一方面就是深色模式并不是簡(jiǎn)單地?fù)Q個(gè)換個(gè)顏色就行，很多元素需要重新設(shè)計(jì)和開(kāi)發(fā)。

結(jié)論：該選擇哪種模式

在去年的 WWDC 大會(huì)上，蘋(píng)果人機(jī)交互團(tuán)隊(duì)的設(shè)計(jì)師曾對(duì) macOS 的深色模式使用場(chǎng)景做了進(jìn)一步的解釋。

他指出，只有閱讀瀏覽或是內(nèi)容創(chuàng)作型 App 才需要長(zhǎng)期啟用深色模式，比如文字或代碼編輯。它們會(huì)借助黑底白字的高對(duì)比度特性來(lái)讓用戶視線保持集中，其它大部分軟件對(duì)于深色模式的需求反而并不強(qiáng)烈。

或則你可以通過(guò)使用場(chǎng)景去選擇，在明亮的環(huán)境中使用淺色模式，在昏暗的環(huán)境中使用深色模式。

但是在大多數(shù)情況下，真正幫助你避免眼睛疲勞的是不要整天盯著屏幕，而不是糾結(jié)到底用深色還是淺色模式。

轉(zhuǎn)自：站酷-

評(píng)論(0) 瀏覽(3430)

272020-4

移動(dòng)端列表查詢最佳實(shí)踐

seo達(dá)人

無(wú)論是 pc 端還是移動(dòng)端，無(wú)可避免都會(huì)涉及到列表查詢有關(guān)的操作，但對(duì)于這兩種不同的設(shè)備，其列表查詢的最佳處理方式也是完全不同。

對(duì)于 pc 端列表查詢來(lái)說(shuō)，前端通常是給與服務(wù)端當(dāng)前需要獲取的數(shù)據(jù)量(如 pageCount，limit 等參數(shù))以及所需要獲取數(shù)據(jù)的位置(如 pageSize，offset 等參數(shù))作為查詢條件。然后服務(wù)端然后返回?cái)?shù)據(jù)總數(shù)，以及當(dāng)前數(shù)據(jù)，前端再結(jié)合這些數(shù)據(jù)顯示頁(yè)面總數(shù)等信息。這里我稱為相對(duì)位置取數(shù)。

對(duì)于移動(dòng)端而言，沒(méi)有pc 端那么大的空間展示以及操作，所以基本上都會(huì)采用下拉取數(shù)這種方案。

那么我們?cè)谔幚硪苿?dòng)端列表查詢時(shí)候使用這種相對(duì)位置取數(shù)會(huì)有什么問(wèn)題呢？

相對(duì)位置取數(shù)存在的問(wèn)題

性能劣勢(shì)

通過(guò)相對(duì)位置取數(shù)會(huì)具有性能問(wèn)題，因?yàn)橐坏┦褂?offset 信息來(lái)獲取數(shù)據(jù)，隨著頁(yè)數(shù)的增加，響應(yīng)速度也會(huì)變的越來(lái)越慢。因?yàn)樵跀?shù)據(jù)庫(kù)層面，我們每次所獲取的數(shù)據(jù)都是“從頭開(kāi)始第幾條”，每次我們都需要從第一條開(kāi)始計(jì)算，計(jì)算后舍棄前面的數(shù)據(jù)，只取最后多條數(shù)據(jù)返回前端。

當(dāng)然了，對(duì)于相對(duì)位置取數(shù)來(lái)說(shuō)，數(shù)據(jù)庫(kù)優(yōu)化是必然的，這里我就不多做贅述了。對(duì)于前端開(kāi)發(fā)來(lái)說(shuō)，優(yōu)秀的的查詢條件設(shè)計(jì)可以在一定方面解決此問(wèn)題。

數(shù)據(jù)顯示重復(fù)

事實(shí)上，對(duì)于一個(gè)實(shí)際運(yùn)行的項(xiàng)目而言，數(shù)據(jù)更新才是常態(tài)，如果數(shù)據(jù)更新的頻率很高或者你在當(dāng)前頁(yè)停留的時(shí)間過(guò)久的話，會(huì)導(dǎo)致當(dāng)前獲取的數(shù)據(jù)出現(xiàn)一定的偏差。

例如：當(dāng)你在獲取最開(kāi)始的 20 條數(shù)據(jù)后，正準(zhǔn)備獲取緊接著的后 20 條數(shù)據(jù)時(shí)，在這段時(shí)間內(nèi) ，發(fā)生了數(shù)據(jù)增加，此時(shí)移動(dòng)端列表就可能會(huì)出現(xiàn)重復(fù)數(shù)據(jù)。雖然這個(gè)問(wèn)題在 pc 端也存在，但是 pc 端只會(huì)展示當(dāng)前頁(yè)的信息，這樣就避免了該問(wèn)題所帶來(lái)的負(fù)面影響。

結(jié)合列表 key 維持渲染正確

我們?cè)谏厦娴膯?wèn)題中說(shuō)明了，移動(dòng)端下拉加載中使用相對(duì)位置查詢?nèi)?shù)是有問(wèn)題的。

那么，如果當(dāng)前不能迅速結(jié)合前后端進(jìn)行修改 api 的情況下，當(dāng)服務(wù)端傳遞過(guò)來(lái)的數(shù)據(jù)與用戶想要得的數(shù)據(jù)不一致，我們必須在前端進(jìn)行處理，至少處理數(shù)據(jù)重復(fù)問(wèn)題所帶來(lái)的負(fù)面影響。

因?yàn)楫?dāng)前分頁(yè)請(qǐng)求時(shí)無(wú)狀態(tài)的。在分頁(yè)取到數(shù)據(jù)之后前端可以對(duì)取得的數(shù)據(jù)進(jìn)行過(guò)濾，過(guò)濾掉當(dāng)前頁(yè)面已經(jīng)存在的 key(例如 id 等能夠確定的唯一鍵)。

通過(guò)這種處理方式，我們至少可以保證當(dāng)前用戶看到的數(shù)據(jù)不會(huì)出現(xiàn)重復(fù)。同時(shí)當(dāng)列表數(shù)據(jù)可以編輯修改的時(shí)候，也不會(huì)出現(xiàn)因?yàn)?key 值相同而導(dǎo)致數(shù)據(jù)錯(cuò)亂。

通過(guò)絕對(duì)位置獲取數(shù)據(jù)

如果不使用相對(duì)位置獲取數(shù)據(jù)，前端可以利用當(dāng)前列表中的最后一條數(shù)據(jù)作為請(qǐng)求源參數(shù)。前端事先記錄最后一條數(shù)據(jù)的信息。例如當(dāng)前的排序條件為創(chuàng)建時(shí)間，那么記錄最后一條數(shù)據(jù)的創(chuàng)建時(shí)間為主查詢條件(如果列表對(duì)應(yīng)的數(shù)據(jù)不屬于個(gè)人，可能創(chuàng)建時(shí)間不能唯一決定當(dāng)前數(shù)據(jù)位置，同時(shí)還需要添加 ID 等信息作為次要查詢條件)。

當(dāng)我們使用絕對(duì)位置獲取數(shù)據(jù)時(shí)候，雖然我們無(wú)法提供類(lèi)似于從第 1 頁(yè)直接跳轉(zhuǎn) 100 頁(yè)的查詢請(qǐng)求，但對(duì)于下拉加載這種類(lèi)型的請(qǐng)求，我們不必?fù)?dān)心性能以及數(shù)據(jù)重復(fù)顯示的問(wèn)題。

對(duì)于相對(duì)位置取數(shù)來(lái)說(shuō)，前端可以根據(jù)返回?cái)?shù)據(jù)的總數(shù)來(lái)判斷。但當(dāng)使用絕對(duì)位置取數(shù)時(shí)，即使獲取數(shù)據(jù)總數(shù)，也無(wú)法判斷當(dāng)前查詢是否存在后續(xù)數(shù)據(jù)。

從服務(wù)器端實(shí)現(xiàn)的角度來(lái)說(shuō)，當(dāng)用戶想要得到 20 條數(shù)據(jù)時(shí)候，服務(wù)端如果僅僅只向數(shù)據(jù)庫(kù)請(qǐng)求 20 條數(shù)據(jù)，是無(wú)法得知是否有后續(xù)數(shù)據(jù)的。服務(wù)端可以嘗試獲取當(dāng)前請(qǐng)求的數(shù)據(jù)條數(shù) + 1, 如向數(shù)據(jù)庫(kù)請(qǐng)求 21 條數(shù)據(jù)，如果成功獲得 21 條數(shù)據(jù)，則說(shuō)明至少存在著 1 條后續(xù)數(shù)據(jù)，這時(shí)候，我們就可以返回 20 條數(shù)據(jù)以及具有后續(xù)數(shù)據(jù)的信息。但如果我們請(qǐng)求 21 條數(shù)據(jù)卻僅僅只能獲取 20 條數(shù)據(jù)(及以下)，則說(shuō)明沒(méi)有后續(xù)數(shù)據(jù)。

如可以通過(guò) “hasMore” 字段來(lái)表示是否能夠繼續(xù)下拉加載的信息。

{ data: [], hasMore: true }

結(jié)合 HATEOAS 設(shè)計(jì)優(yōu)化

事實(shí)上，前面我們已經(jīng)解決了移動(dòng)端處理列表查詢的問(wèn)題。但是我們做的還不夠好，前端還需要結(jié)合排序條件來(lái)處理并提供請(qǐng)求參數(shù)，這個(gè)操作對(duì)于前端來(lái)說(shuō)也是一種負(fù)擔(dān)。那么我們就聊一下 HATEOAS 。

HATEOAS (Hypermedia As The Engine Of Application State, 超媒體即應(yīng)用狀態(tài)引起) 這個(gè)概念最早出現(xiàn)在 Roy Fielding 的論文中。REST 設(shè)計(jì)級(jí)別如下所示:

REST LEVEL 0: 使用 HTTP 作為傳輸方式
REST LEVEL 1: 引入資源的概念(每一個(gè)資源都有對(duì)應(yīng)的標(biāo)識(shí)符和表達(dá))
REST LEVEL 2: 引入 HTTP 動(dòng)詞(GET 獲取資源/POST 創(chuàng)建資源/PUT 更新或者創(chuàng)建字樣/DELETE 刪除資源等)
REST LEVEL 3: 引入 HATEOAS (在資源的表達(dá)中包含了鏈接信息?？蛻舳丝梢愿鶕?jù)鏈接來(lái)發(fā)現(xiàn)可以執(zhí)行的動(dòng)作)

HATEOAS 會(huì)在 API 返回的數(shù)據(jù)中添加下一步要執(zhí)行的行為，要獲取的數(shù)據(jù)等 URI 的鏈接信息?？蛻舳酥灰@取這些信息以及行為鏈接，就可以根據(jù)這些信息進(jìn)行接下來(lái)的操作。

對(duì)于當(dāng)前的請(qǐng)求來(lái)說(shuō)，服務(wù)端可以直接返回下一頁(yè)的信息，如

{ data: [], hasMore: true, nextPageParams: {}    
}

服務(wù)端如此傳遞數(shù)據(jù)，前端就不需要對(duì)其進(jìn)行多余的請(qǐng)求處理，如果當(dāng)前沒(méi)有修改之前的查詢以及排序條件，則只需要直接返回 “nextPageParams” 作為下一頁(yè)的查詢條件即可。

這樣做的好處不但符合 REST LEVEL 3,同時(shí)也減輕了前端的心智模型。前端無(wú)需配置下一頁(yè)請(qǐng)求參數(shù)。只需要在最開(kāi)始查詢的時(shí)候提供查詢條件即可。

當(dāng)然，如果前端已經(jīng)實(shí)現(xiàn)了所有排序添加以及查詢條件由服務(wù)端提供，前端僅僅提供組件，那么該方案更能體現(xiàn)優(yōu)勢(shì)。前端是不需要知道當(dāng)前業(yè)務(wù)究竟需要什么查詢條件，自然也不需要根據(jù)查詢條件來(lái)組織下一頁(yè)的條件。同時(shí)，該方案的輸入和輸出都由后端提供，當(dāng)涉及到業(yè)務(wù)替換( 查詢條件，排序條件修改)時(shí)候，前端無(wú)需任何修改便可以直接替換和使用。

其他注意事項(xiàng)

一旦涉及到移動(dòng)端請(qǐng)求，不可避免的會(huì)有網(wǎng)絡(luò)問(wèn)題，當(dāng)用戶在火車(chē)或者偏遠(yuǎn)地區(qū)時(shí)候，一旦下拉就會(huì)涉及取數(shù)，但是當(dāng)前數(shù)據(jù)沒(méi)有返回之前，用戶多次下拉可能會(huì)有多次取數(shù)請(qǐng)求，雖然前端可以結(jié)合 key 使得渲染不出錯(cuò)，但是還是會(huì)在緩慢的網(wǎng)絡(luò)下請(qǐng)求多次，無(wú)疑雪上加霜。這時(shí)候我們需要增加條件變量 loading。

偽代碼如下所示：

// 查詢 function search(cond) {
  loading = true api.then(res => {
      loading = false }).catch(err => {
      loading = false })
} // 獲取下一頁(yè)數(shù)據(jù) function queryNextPage() { if (!nextPageParams) return if (!loading) return search(nextPageParams)
}

評(píng)論(0) 瀏覽(3147)

272020-4

焦點(diǎn)配色法

資深UI設(shè)計(jì)者

今天跟大家聊聊設(shè)計(jì)中焦點(diǎn)配色這個(gè)話題。焦點(diǎn)這個(gè)詞對(duì)于設(shè)計(jì)師來(lái)說(shuō)應(yīng)該不會(huì)感到陌生，但是這節(jié)課我們主要是從色彩的角度，來(lái)看看焦點(diǎn)在設(shè)計(jì)中的作用以及色彩焦點(diǎn)的重要性。首先我們要知道設(shè)計(jì)的目的就是通過(guò)視覺(jué)來(lái)傳達(dá)信息，而視覺(jué)的表現(xiàn)形式是有一定規(guī)律性的，在這些眾多的規(guī)律性當(dāng)中，其中有一條就是通過(guò)色彩來(lái)實(shí)現(xiàn)，而焦點(diǎn)配色就是色彩設(shè)計(jì)中最有效的一個(gè)手段。

其實(shí)無(wú)論是繪畫(huà)、攝影還是我們的設(shè)計(jì)，都存在大量的焦點(diǎn)配色，只是我們平時(shí)沒(méi)有特別去注意而已。比如莫奈的這幅《日出·印象》，我們來(lái)嘗試分析一下焦點(diǎn)的設(shè)置和移動(dòng)。

我想絕大多數(shù)人都應(yīng)該是這種移動(dòng)路線，也就是在大面積灰色調(diào)和冷色調(diào)中先被強(qiáng)暖色的太陽(yáng)所吸引，然后是近景全黑色的船，接著順延到另一條船上，當(dāng)然每個(gè)人都會(huì)有所不同。

比如也可能是這種從遠(yuǎn)景到近景的順序。

也可能有的人是從近到遠(yuǎn)的觀看順序，但是無(wú)論你是哪一種，都不重要，為什么？

因?yàn)闊o(wú)論你的視線是怎么移動(dòng)的，都不會(huì)影響到我們最終焦點(diǎn)的歸屬。大家可以感受一下，當(dāng)你看這幅畫(huà)的時(shí)候，無(wú)論你先看哪后看哪，最終你的眼睛都會(huì)被這個(gè)橙紅色的太陽(yáng)所吸引，這就是色彩焦點(diǎn)的魅力。

我們?cè)賮?lái)看一個(gè)攝影作品，這個(gè)跟剛才那幅畫(huà)來(lái)比，焦點(diǎn)就更加清晰了，而且這里也不需要焦點(diǎn)的移動(dòng)，很明顯焦點(diǎn)就是這個(gè)人物。

但是這個(gè)焦點(diǎn)是怎么通過(guò)色彩得到強(qiáng)化的呢？可能有的人會(huì)說(shuō)這么明顯的人物肯定是焦點(diǎn)啊，但是你可以嘗試把人物后面的暖色光去掉看看，雖然人物同樣是這個(gè)畫(huà)面的焦點(diǎn)，但是一定沒(méi)有現(xiàn)在這樣搶眼，因?yàn)榕捅尘暗睦渖纬闪藦?qiáng)烈的對(duì)比。

所以無(wú)論是繪畫(huà)、攝影還是我們接下來(lái)會(huì)看到的設(shè)計(jì)，其中都會(huì)包含一種故意的或者是有意識(shí)的色彩焦點(diǎn)的安排，而這種焦點(diǎn)的形成是怎么實(shí)現(xiàn)的呢？其實(shí)就是通過(guò)色彩對(duì)比，因?yàn)橛猩蕦?duì)比必定產(chǎn)生焦點(diǎn)，即使沒(méi)有焦點(diǎn)我們也會(huì)努力去尋找焦點(diǎn)。我們聯(lián)想下平時(shí)的生活就會(huì)發(fā)現(xiàn)，無(wú)論是我們看到一幅畫(huà)面，或者是置身于一個(gè)真實(shí)的環(huán)境中，我們都會(huì)不自覺(jué)地去尋找色彩最突出或者最醒目的東西，這就是作為人的一種本能，也就是自然而然地去尋找焦點(diǎn)。

下面我們來(lái)看一些設(shè)計(jì)作品，我們看這三個(gè)界面，不能說(shuō)沒(méi)有焦點(diǎn)，有，就是圖片，準(zhǔn)確地說(shuō)應(yīng)該是沒(méi)有色彩焦點(diǎn)，所以我們接收到的就是圖片加上信息排在一起，我們很難在短時(shí)間內(nèi)區(qū)分出哪些是重要信息哪些是次要信息。我們不知道視線應(yīng)該落在哪里，因?yàn)闆](méi)有突出的東西，這種不知所措會(huì)讓看的人感到不舒服，這就是沒(méi)有焦點(diǎn)會(huì)造成的一種情況。

同樣這三個(gè)界面，我們什么都不變，只是在想強(qiáng)調(diào)的部分填充一個(gè)顏色，這樣就會(huì)讓看的人可以通過(guò)色彩毫不猶豫地感受到焦點(diǎn)，這種交互才是人性化的交互，而這個(gè)簡(jiǎn)單的過(guò)程其實(shí)就是色彩設(shè)計(jì)。

我們?cè)賮?lái)看一個(gè)更加簡(jiǎn)單易懂的，比如現(xiàn)在這個(gè)，就是在一個(gè)藍(lán)色背景上編排純白的文字，可能通過(guò)字號(hào)和距離的安排我們也知道孰輕孰重，但是如果從色彩的角度來(lái)看還不夠，因?yàn)闆](méi)有形成讓人快速識(shí)別的焦點(diǎn)。

如果在想強(qiáng)調(diào)的地方，適當(dāng)?shù)奶畛湟粋€(gè)顏色，那么瞬間就有了焦點(diǎn)，而這個(gè)顏色和背景色的對(duì)比越強(qiáng)，焦點(diǎn)就越明顯。

我們看這個(gè)海報(bào)，當(dāng)我們看到這個(gè)畫(huà)面的時(shí)候首先注意到的是什么？

首先注意的肯定是上方的圖片，其次會(huì)根據(jù)信息的層級(jí)大小去看主標(biāo)題，然后是次要信息。這種沒(méi)有設(shè)置色彩焦點(diǎn)的形式，雖然不太會(huì)影響信息的閱讀，但我們不妨試試有色彩焦點(diǎn)的情況。

當(dāng)原本就是畫(huà)面中比較重要的標(biāo)題信息和突出的英文被填充紅色之后，焦點(diǎn)就產(chǎn)生了并且得到強(qiáng)化。

這時(shí)候當(dāng)我們?cè)倏催@個(gè)作品，就可以在短時(shí)間內(nèi)迅速獲得信息，如果想繼續(xù)了解也可以繼續(xù)閱讀，這就是有焦點(diǎn)和沒(méi)焦點(diǎn)或者焦點(diǎn)不突出的差別。

我們看這個(gè) banner，這里我們不說(shuō)它的版式怎么樣，我們就看色彩和焦點(diǎn)，這個(gè)畫(huà)面有什么問(wèn)題呢？就是焦點(diǎn)設(shè)置錯(cuò)誤，什么意思？

也就是大家看這個(gè)畫(huà)面的時(shí)候，雖然都會(huì)先看月餅的圖片，然后是標(biāo)題到進(jìn)入專(zhuān)場(chǎng)，但是大家發(fā)現(xiàn)沒(méi)有，你的視線總會(huì)被中間這個(gè)粉色的花瓣吸引。

就是那種你不想看它，但是又不得不看的感覺(jué)，因?yàn)檫@個(gè)花瓣的顏色完全沒(méi)必要出現(xiàn)在這里，因?yàn)樗皇切畔?，為什么要充?dāng)焦點(diǎn)呢？這就是焦點(diǎn)錯(cuò)誤。

我們把花瓣去掉試試，這樣焦點(diǎn)就很清晰明確了。

現(xiàn)在我們知道了有焦點(diǎn)和沒(méi)焦點(diǎn)的差別，那焦點(diǎn)的設(shè)置其實(shí)也是有多種情況的。我們就拿這個(gè)網(wǎng)頁(yè)來(lái)舉例，版式部分保持不變，你想突出哪里就在哪里設(shè)置焦點(diǎn)。我們來(lái)看看通過(guò)色彩把焦點(diǎn)安排在不同的地方，這個(gè)頁(yè)面產(chǎn)生什么樣的效果。

比如我們可以把焦點(diǎn)設(shè)置在上半部分，也就是頂部的品牌和導(dǎo)航區(qū)域。

也可以把焦點(diǎn)設(shè)置在主標(biāo)題的文字信息上。

還可以設(shè)置在底部區(qū)域，形成色塊。

當(dāng)然也可以是自由式的焦點(diǎn)設(shè)置，強(qiáng)調(diào)你想強(qiáng)調(diào)的部分，這種情況下就有了焦點(diǎn)的移動(dòng)。

通過(guò)之前的案例分析我們總結(jié)一下有焦點(diǎn)的好處：首先它滿足了人的生理需求，其次滿足了視覺(jué)傳達(dá)的需求，最后滿足了審美的需求。也就是說(shuō)我們所要做的視覺(jué)設(shè)計(jì)是需要傳達(dá)信息的，你得讓受眾看到你的信息才行，而要想有效的讓人看到信息，焦點(diǎn)的設(shè)置就要滿足前面三個(gè)需求，如果沒(méi)有滿足，一定程度上說(shuō)明你的作品是失敗的。實(shí)際人都是充滿惰性的，也都不喜歡延遲，當(dāng)人們看到所有的信息在它應(yīng)該在的位置，不需要眼睛和大腦再去閱讀，這時(shí)候就得到了一種觀看和閱讀的滿足感。

說(shuō)了這么多焦點(diǎn)的好處，下面我們就來(lái)看看如何通過(guò)配色形成或者強(qiáng)化焦點(diǎn)。首先我們要知道的就是焦點(diǎn)是通過(guò)對(duì)比實(shí)現(xiàn)的，而這里包括了色相對(duì)比形成焦點(diǎn)、冷暖對(duì)比形成焦點(diǎn)、深淺對(duì)比形成焦點(diǎn)、有彩色與無(wú)彩色對(duì)比形成焦點(diǎn)、花色與純色對(duì)比形成焦點(diǎn)、色彩面積對(duì)比形成焦點(diǎn)。

首先我們來(lái)看色相對(duì)比形成焦點(diǎn)，這里的色相對(duì)比通常是指互補(bǔ)色或?qū)Ρ壬g的對(duì)比，因?yàn)樯嗖町愒酱笤饺菀桩a(chǎn)生焦點(diǎn)。比如這個(gè)海報(bào)就是藍(lán)色和黃色的互補(bǔ)色對(duì)比，當(dāng)然需要注意的是，我們所列舉出的這些對(duì)比并不是單獨(dú)存在的，它們往往都是相互結(jié)合的，比如這個(gè)海報(bào)最明顯的就是色相上的互補(bǔ)色對(duì)比，當(dāng)然你也可以說(shuō)是冷暖對(duì)比，同時(shí)也包括面積對(duì)比。

這個(gè)網(wǎng)頁(yè)作品，藍(lán)色與綠色形成了色相上的對(duì)比，同時(shí)它們二者又與背景形成了有彩色與無(wú)彩色的對(duì)比。

這個(gè)圣誕主題的 banner，整體是大面積的暗紅色，這就讓人物頭頂?shù)木G色圣誕樹(shù)成為了焦點(diǎn)，也就是色相對(duì)比中通過(guò)對(duì)比色形成焦點(diǎn)。

然后是冷暖色對(duì)比產(chǎn)生焦點(diǎn)，這個(gè)版面很簡(jiǎn)單，就是文字編排加上背景，但是很明顯，通過(guò)在強(qiáng)調(diào)的地方使用藍(lán)色與背景的粉紅色形成一種冷暖對(duì)比，讓焦點(diǎn)一目了然。

這個(gè)同樣也是紅色與藍(lán)色的冷暖對(duì)比強(qiáng)調(diào)焦點(diǎn)，讓人一眼就能抓住重點(diǎn)。

這個(gè)同樣也是通過(guò)冷暖對(duì)比形成焦點(diǎn)，只不過(guò)這個(gè)畫(huà)面并不是單一焦點(diǎn)的形式，是多個(gè)焦點(diǎn)從大到小或從近到遠(yuǎn)的移動(dòng)。

如果色相對(duì)比不夠明顯，那么通過(guò)單一色彩或近似色彩的深淺對(duì)比也可以很好的形成焦點(diǎn)，同樣純度和明度差異越大越容易產(chǎn)生焦點(diǎn)。比如這個(gè)畫(huà)面中的焦點(diǎn)面包與背景形成的就是深淺對(duì)比。

這個(gè)畫(huà)面整體是褐色的基調(diào)，但是杯子中的茶湯是比背景更亮一些的顏色，所以它自然而然地就成為了畫(huà)面的焦點(diǎn)，而且這個(gè)焦點(diǎn)也是符合這個(gè)版面的設(shè)計(jì)邏輯的。

這個(gè)頁(yè)面的背景是偏深一些的粉紅色，當(dāng)然圖片肯定是這個(gè)畫(huà)面的第一焦點(diǎn)，但除此之外，這個(gè)畫(huà)面中還有另外兩個(gè)焦點(diǎn)，就是比背景偏暗一些的嘴唇，這就是利用深淺色對(duì)比形成焦點(diǎn)。

焦點(diǎn)的作用以及如何強(qiáng)調(diào)焦點(diǎn)都很好理解和操作，但是設(shè)置焦點(diǎn)背后的原理是什么呢？就是我們之前講過(guò)的色彩營(yíng)銷(xiāo)，因?yàn)樵O(shè)計(jì)的目的是通過(guò)視覺(jué)傳達(dá)信息，而傳遞信息的目的是為了營(yíng)銷(xiāo)，所以答案也就很明了了。也就是如何設(shè)置焦點(diǎn)以及讓誰(shuí)成為焦點(diǎn)，這背后的邏輯要依據(jù)營(yíng)銷(xiāo)的目的，換句話說(shuō)焦點(diǎn)的設(shè)置一定要滿足以上的需求，假如設(shè)置了錯(cuò)誤的焦點(diǎn)，就會(huì)適得其反，倒不如不設(shè)置焦點(diǎn)了，這個(gè)道理大家一定要明白。

我們接著往下看，下一個(gè)就是有彩色與無(wú)彩色對(duì)比產(chǎn)生焦點(diǎn)。比如我們看上面這個(gè)海報(bào)，圖片整體是黑白的，只有雨傘的部分是紅色，非常醒目的被凸顯出來(lái)，當(dāng)然就是第一焦點(diǎn)，其次就是紅色的標(biāo)題性文字。因?yàn)楹谏c紅色很好的對(duì)比效果，所以類(lèi)似這種形式的攝影作品大家也一定見(jiàn)過(guò)很多，就是整體是黑白，個(gè)別地方用紅色的形式。

雖然這個(gè)網(wǎng)頁(yè)頁(yè)面上的有彩色并不是單一色彩，但是與背景黑色的搭配，整體上依然是有彩色與無(wú)彩色搭配所產(chǎn)生的對(duì)比，從而產(chǎn)生焦點(diǎn)。

這個(gè)雖然也是有彩色與無(wú)彩色的對(duì)比，但是這個(gè)很巧妙，因?yàn)樵O(shè)計(jì)者并沒(méi)有直接在主標(biāo)題上填充有彩色，而是在標(biāo)題下方使用了一個(gè)有彩色的色塊，這也是一種變相突顯焦點(diǎn)的方式。

接下來(lái)是花色與純色對(duì)比產(chǎn)生焦點(diǎn)，這個(gè)算是很常見(jiàn)很通用的一種形式了，尤其是照片上編排文字的形式，如果圖片本身的色彩就比較豐富，那么文字色必然要使用單一的色彩才能保證很好的識(shí)別。

這個(gè)雜志封面的背景是由多種色彩所形成的插畫(huà)圖形，而人物一身黑色位于中間形成了第一焦點(diǎn)，其次是位于人物上的綠色文字，可以說(shuō)既是有彩色與無(wú)彩色的對(duì)比，又是有彩色與花色之間的對(duì)比。

這個(gè)海報(bào)上的圖片雖然色彩并沒(méi)有多純，但是由于色彩比較分散，所以可想而知，在它上方編排文字難免會(huì)造成識(shí)別度很低的情況，所以設(shè)計(jì)師也很巧妙地使用了添加色塊的方式，利用這種圖片花色與色塊純色的對(duì)比來(lái)突出焦點(diǎn)。

最后就是通過(guò)色彩面積大小產(chǎn)生焦點(diǎn)，這種面積的對(duì)比可以說(shuō)是非常常見(jiàn)的，可以說(shuō)大部分有色彩焦點(diǎn)的畫(huà)面都是之前的那幾種形式與面積對(duì)比的一個(gè)結(jié)合，但是并沒(méi)有誰(shuí)重要誰(shuí)不重要一說(shuō)，就比如這個(gè)海報(bào)上的紅色圓形，無(wú)論你是把它的面積放大，還是把它換成和藍(lán)色相近的顏色，焦點(diǎn)的效果都沒(méi)有現(xiàn)在的好。所以我們?cè)诰唧w設(shè)計(jì)配色的時(shí)候千萬(wàn)不要有強(qiáng)迫癥，因?yàn)檫@些方法往往都是結(jié)合使用的。

這個(gè)也是面積對(duì)比產(chǎn)生的焦點(diǎn)，同時(shí)又有藍(lán)色與紅色的冷暖對(duì)比。

這個(gè)頁(yè)面也是，通過(guò)在大面積綠色調(diào)中使用一個(gè)紅色塊，快速形成對(duì)比，從而確定焦點(diǎn)。

以上我們主要講解了通過(guò)配色形成焦點(diǎn)的一些方法，但其實(shí)細(xì)心的同學(xué)就會(huì)發(fā)現(xiàn)，這里面還是有一些潛規(guī)則的，有的是和色彩有關(guān)，有的可能和色彩無(wú)關(guān)。比如說(shuō)同樣的色彩或同樣大小的對(duì)象，具象的東西比抽象的東西容易形成焦點(diǎn)、人物比場(chǎng)景或風(fēng)景容易形成焦點(diǎn)、圖像比文字容易形成焦點(diǎn)、標(biāo)題文字比內(nèi)文容易形成焦點(diǎn)、暖色比冷色容易形成焦點(diǎn)、強(qiáng)對(duì)比比弱對(duì)比容易形成焦點(diǎn)，最后我們就分別來(lái)看一下。

具象的事物比抽象的事物容易形成焦點(diǎn)，這個(gè)似乎沒(méi)什么可說(shuō)的，大家應(yīng)該都能明顯的感覺(jué)到，就比如這個(gè)海報(bào)，即使人臉的周?chē)兄苊苈槁榈某橄髨D像，我們的注意力依然在人臉的部分。

人物要比場(chǎng)景更容易產(chǎn)生焦點(diǎn)，比如這個(gè)海報(bào)，同時(shí)存在兩張圖片，雖然上方的圖片是一匹馬不是人，但是道理是一樣的，我們的視線總是想關(guān)注這個(gè)馬的眼睛，而下方的海水我們可能只是一掃而過(guò)。

圖片比文字更容易形成焦點(diǎn)，這個(gè)也是無(wú)需多說(shuō)的一點(diǎn)，因?yàn)榧词苟际呛诎椎膱D片和文字，我們也會(huì)首先注意到圖片，這是圖片所具有的天然魅力。比如這個(gè)海報(bào)，假如我們把圖片遮掉，那么紅色的「魂」字毋庸置疑就是第一焦點(diǎn)，因?yàn)樵谝欢押谏淖种兴鼘?shí)在太顯眼了，但是加上人物圖片的話，就沒(méi)有多少人會(huì)去關(guān)注「魂」字了。

標(biāo)題比內(nèi)文更容易產(chǎn)生焦點(diǎn)，這是因?yàn)闃?biāo)題所具有的天然優(yōu)勢(shì)，也就是面積優(yōu)勢(shì)，比如我們看這個(gè)海報(bào)，其實(shí)它這里的標(biāo)題使用與圖片一樣的藍(lán)色并不是很突出，雖然日期和副標(biāo)題使用了色相對(duì)比，也確實(shí)成為了焦點(diǎn)，但是對(duì)于主標(biāo)題的影響并不是很大，我們依然不會(huì)忽略掉主標(biāo)題，這就是面積原因所造成的，因?yàn)樗銐虼蟆?

暖色比冷色更容易形成焦點(diǎn)，這個(gè)海報(bào)就是一個(gè)很好的說(shuō)明，因?yàn)楹?bào)中兩個(gè)圖片大小相當(dāng)，唯一的區(qū)別就是一個(gè)是暖色一個(gè)是冷色，那么哪個(gè)更吸引你呢？一定是暖色，如果你說(shuō)你就是被冷色所吸引那也沒(méi)關(guān)系，但是你自己保留意見(jiàn)，我不接受反駁。

最后就是強(qiáng)對(duì)比大于弱對(duì)比，比如我們看這個(gè)海報(bào)，其實(shí)本身背景色上有色相的對(duì)比，但是因?yàn)閷?duì)比不夠強(qiáng)，所以就讓上方的紅色成為了焦點(diǎn)，因?yàn)榧t色與整體背景形成了強(qiáng)烈的深淺對(duì)比。

簡(jiǎn)單總結(jié)一下，首先我們通過(guò)一些案例說(shuō)明了色彩焦點(diǎn)的重要性，也就是滿足了人的三種需求：生理需求、視覺(jué)傳達(dá)的需求以及審美的需求。其次我們講解了如何形成或強(qiáng)調(diào)焦點(diǎn)，也就是通過(guò)一些色彩對(duì)比來(lái)實(shí)現(xiàn)。最后補(bǔ)充了一些焦點(diǎn)配色中存在的潛規(guī)則，也就是哪些內(nèi)容或形式具有形成焦點(diǎn)的天然優(yōu)勢(shì)。當(dāng)然這一切的落腳點(diǎn)還要?dú)w到視覺(jué)傳達(dá)以及色彩營(yíng)銷(xiāo)上。

文章來(lái)源：優(yōu)設(shè) 作者：研習(xí)設(shè)

評(píng)論(0) 瀏覽(3050)

272020-4

從免費(fèi)圖庫(kù)、影片到字體，這個(gè)網(wǎng)站全包了！

資深UI設(shè)計(jì)者

距離上一次介紹 The Stocks 已經(jīng)超過(guò)五年，前段時(shí)間無(wú)意間瀏覽到這個(gè)網(wǎng)站，才想起我以前好像也寫(xiě)過(guò)文章，不過(guò)網(wǎng)站現(xiàn)在變得不太一樣而且內(nèi)容又更完整了，非常推薦加入收藏，因?yàn)檎娴暮芊奖?。如果你還不知道 The Stocks，它整合各種設(shè)計(jì)相關(guān)免費(fèi)資源，最早只有將一些免費(fèi)圖庫(kù)整合在一起，讓找圖的使用者透過(guò)側(cè)邊欄選單快速切換各個(gè)不同圖庫(kù)網(wǎng)站，加速搜尋圖庫(kù)的效率。

在全新的 The Stocks 2 除了免費(fèi)圖庫(kù)，加入配色工具、免費(fèi)圖標(biāo)、免費(fèi)影片、免費(fèi)字體和 Mockups 素材網(wǎng)站共六種項(xiàng)目，相較于早期來(lái)說(shuō)在資源數(shù)量上增加不少，現(xiàn)在一樣可以從網(wǎng)站側(cè)邊選單選取你要瀏覽的素材類(lèi)型，The Stocks 就會(huì)出現(xiàn)一整排的網(wǎng)站列表讓使用者直接選擇，再?gòu)倪@些網(wǎng)站去尋找你要的免費(fèi)資源。

對(duì)于平常會(huì)需要搜尋設(shè)計(jì)相關(guān)資源的使用者來(lái)說(shuō)，The Stocks 是很好用的工具。

不過(guò) The Stocks 現(xiàn)在會(huì)加入一些贊助商「推薦」內(nèi)容，如果使用者進(jìn)入這些服務(wù)，也有付費(fèi)購(gòu)買(mǎi)的話 The Stocks 開(kāi)發(fā)者就能獲得回饋（其實(shí)就是 Affiliate），網(wǎng)站主要還是以收錄免費(fèi)服務(wù)為主。

The Stocks 2

網(wǎng)站鏈接：http://thestocks.im/

使用教學(xué)

開(kāi)啟 The Stocks 網(wǎng)站后會(huì)隨機(jī)顯示一個(gè)免費(fèi)圖庫(kù)，The Stocks 主要功能列在左側(cè)，點(diǎn)選選單上的網(wǎng)站名稱會(huì)將網(wǎng)頁(yè)顯示于右側(cè)，方便在各個(gè)外部網(wǎng)站跳轉(zhuǎn)和搜尋，不過(guò)有些網(wǎng)站不允許被嵌入其他頁(yè)面，這時(shí)候就會(huì)以開(kāi)新分頁(yè)方式替代。

左上角是 The Stocks 收錄的免費(fèi)資源類(lèi)型，包括免費(fèi)圖庫(kù)、配色工具、免費(fèi)圖標(biāo)、免費(fèi)影片、免費(fèi)字體和 Mockups 素材網(wǎng)站，點(diǎn)選后下方的網(wǎng)站列表就會(huì)實(shí)時(shí)更新。

有些標(biāo)示為 Featured 就是本文前面提到的贊助商推薦內(nèi)容，大多都是付費(fèi)服務(wù)，例如銷(xiāo)售相片圖片的 Shutterstock、iStock 圖庫(kù)，如果有在找圖的朋友應(yīng)該不陌生，其實(shí)很多免費(fèi)圖庫(kù)也是透過(guò)刊登付費(fèi)圖庫(kù)廣告來(lái)獲取收益。

當(dāng)然 The Stocks 收錄的網(wǎng)站仍以免費(fèi)資源居多，點(diǎn)選后就能快速瀏覽網(wǎng)站，如果操作上發(fā)現(xiàn)有些問(wèn)題或無(wú)法正確顯示，亦可搜尋該網(wǎng)站名稱直接在瀏覽器開(kāi)啟。

最近因?yàn)橐咔殛P(guān)系，很多公司改為在家上班，如果要開(kāi)會(huì)就會(huì)透過(guò)一些視頻會(huì)議軟件例如 Zoom ，The Stocks 也有提供 Zoom 適用的免費(fèi)虛擬背景（特別是家里背景很雜亂的朋友可以稍微隱藏一下），這些素材可以在網(wǎng)站右上角 Zoom Virtual Backgrounds 找到。

值得一試的三個(gè)理由：

整合免費(fèi)圖庫(kù)、配色工具、免費(fèi)圖標(biāo)、免費(fèi)影片、免費(fèi)字體等相關(guān)網(wǎng)站
點(diǎn)選網(wǎng)站鏈接即可在同一頁(yè)面快速切換瀏覽

對(duì)于要搜尋素材來(lái)說(shuō)很方便很有用

文章來(lái)源：優(yōu)設(shè) 作者：Pseric

評(píng)論(0) 瀏覽(2781)

242020-4

前端架構(gòu)演進(jìn)及主流UI

前端達(dá)人

總結(jié)

前端三要素

JavaScript 框架

NodeJs

常用UI框架

前后端分離的演進(jìn)

為了降低開(kāi)發(fā)的復(fù)雜度，以后端為出發(fā)點(diǎn)，比如:Struts、SpringMVC 等框架的使用，就是后端的 MVC 時(shí)代;

以 SpringMVC 流程為例:

優(yōu)點(diǎn):

前后端職責(zé)很清晰: 前端工作在瀏覽器端，后端工作在服務(wù)端。清晰的分工，可以讓開(kāi)發(fā)并行，測(cè) 試數(shù)據(jù)的模擬不難，前端可以本地開(kāi)發(fā)。后端則可以專(zhuān)注于業(yè)務(wù)邏輯的處理，輸出 RESTful等接口。
前端開(kāi)發(fā)的復(fù)雜度可控: 前端代碼很重，但合理的分層，讓前端代碼能各司其職。這一塊蠻有意思的，簡(jiǎn)單如模板特性的選擇，就有很多很多講究。并非越強(qiáng)大越好，限制什么，留下哪些自由，代碼應(yīng)該如何組織，所有這一切設(shè)計(jì)，得花一本書(shū)的厚度去說(shuō)明。
-部署相對(duì)獨(dú)立: 可以快速改進(jìn)產(chǎn)品體驗(yàn)
缺點(diǎn):

代碼不能復(fù)用。比如后端依舊需要對(duì)數(shù)據(jù)做各種校驗(yàn)，校驗(yàn)邏輯無(wú)法復(fù)用瀏覽器端的代碼。如果可以復(fù)用，那么后端的數(shù)據(jù)校驗(yàn)可以相對(duì)簡(jiǎn)單化。
全異步，對(duì) SEO 不利。往往還需要服務(wù)端做同步渲染的降級(jí)方案。性能并非最佳，特別是移動(dòng)互聯(lián)網(wǎng)環(huán)境下。
SPA 不能滿足所有需求，依舊存在大量多頁(yè)面應(yīng)用。URL Design 需要后端配合，前端無(wú)法完全掌控。
NodeJS 帶來(lái)的全棧時(shí)代

前端為主的 MV* 模式解決了很多很多問(wèn)題，但如上所述，依舊存在不少不足之處。隨著 NodeJS 的興起，JavaScript 開(kāi)始有能力運(yùn)行在服務(wù)端。這意味著可以有一種新的研發(fā)模式:
————————————————
版權(quán)聲明：本文為CSDN博主「叁有三分之一」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/iME_cho/article/details/105654633

評(píng)論(0) 瀏覽(2664)

242020-4

【CSS基礎(chǔ)學(xué)習(xí)】行內(nèi)元素，塊級(jí)元素，行內(nèi)塊級(jí)元素

前端達(dá)人

文章目錄

元素的顯示方式和轉(zhuǎn)換

塊級(jí)元素
行級(jí)元素
行內(nèi)塊級(jí)元素

顯示方式之間的轉(zhuǎn)化

元素的顯示方式和轉(zhuǎn)換

塊級(jí)元素

塊級(jí)元素（inline）：
塊級(jí)元素可以包含行內(nèi)元素和其它塊級(jí)元素，且占據(jù)父元素的整個(gè)空間，可以設(shè)置 width 和 height 屬性，瀏覽器通常會(huì)在塊級(jí)元素前后另起一個(gè)新行。
常見(jiàn)塊級(jí)元素：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <style>
        div{
            width: 150px;
            height: 150px;
            background-color: cadetblue;
        }
    </style>
</head>
<body>
    <div>塊級(jí)元素1</div>
    <div>塊級(jí)元素2</div>
</body>
</html>

分析：
塊級(jí)元素的高和寬可以被修改，而且塊級(jí)元素會(huì)在一個(gè)塊級(jí)元素之后另起一行。

行級(jí)元素
行級(jí)元素（block）：
一般情況下，行內(nèi)元素只能包含內(nèi)容或者其它行內(nèi)元素，寬度和長(zhǎng)度依據(jù)內(nèi)容而定，不可以設(shè)置，可以和其它元素和平共處于一行。
常見(jiàn)行級(jí)元素：
a,b,strong,span,img,label,button,input,select,textarea
特點(diǎn)：

和相鄰的行內(nèi)元素在一行上
高度和寬度無(wú)效，但是水平方向上的padding和margin可以設(shè)置，垂直方向上的無(wú)效
默認(rèn)的寬度就是它本身的寬度
行內(nèi)元素只能容納純文本或者是其他的行內(nèi)元素（a標(biāo)簽除外）
例如：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <style>
        span{
            width: 150px;
            height: 150px;
            font-size: 40px;
            background-color: cadetblue;
        }
    </style>
</head>
<body>
    <span>行級(jí)元素1</span>
    <span>行級(jí)元素2</span>
</body>
</html>

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <style>
        span{
            width: 150px;
            height: 150px;
            font-size: 20px;
            background-color: cadetblue;
            display: inline-block;
        }
    </style>
</head>
<body>
    <span>以前我是行級(jí)元素，</span>
    <span>現(xiàn)在我只想做行內(nèi)塊級(jí)元素。</span>
</body>
</html>

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <style>
        div{
            width: 150px;
            height: 150px;
            font-size: 30px;
            background-color: cadetblue;
            display: inline;
        }
    </style>
</head>
<body>
    <div>我以前是塊級(jí)元素，</div>
    <div>現(xiàn)在我是行級(jí)元素！</div>
</body>
</html>

分析：
在VSC中，修改寬高的代碼已經(jīng)出現(xiàn)了波浪線，證明他是錯(cuò)誤的，所以現(xiàn)在的div已經(jīng)變成了行級(jí)元素。

————————————————
版權(quán)聲明：本文為CSDN博主「董小宇」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/lolly1023/article/details/105715892

評(píng)論(0) 瀏覽(2572)

242020-4

帶你快速了解VSCode的10個(gè)特性，極大提高開(kāi)發(fā)效率

前端達(dá)人

其實(shí)VSCode編輯器本身自帶了一個(gè)功能（Interactive Editor Playground ：可以讓你快速了解VSCode的特性，并且是可以交互的），

但很可惜它的內(nèi)容是全英文的（將VSCode設(shè)置為中文也沒(méi)用哦~），

我將每一部分截圖下來(lái)，并為你說(shuō)明關(guān)鍵內(nèi)容，教你學(xué)會(huì)使用 Interactive Editor Playground

還有一些顯而易見(jiàn)的特性，我不會(huì)再用文字?jǐn)⑹鲆槐椋ㄋ鼈兌际菨撘颇模?br />
在下文中會(huì)涉及到大量快捷鍵的介紹，如果看不懂快捷鍵請(qǐng)自行百度

鼠標(biāo) = 文本光標(biāo) = 光標(biāo)

本文成于2020年4月22日，隨著VSCode的版本更迭，此部分內(nèi)容可能會(huì)略有差異（小更改不影響觀看，有較大影響的更新請(qǐng)?jiān)谠u(píng)論區(qū)告之，我會(huì)及時(shí)更新的）

打開(kāi)VSCode > Help > Interactive Playground

你將會(huì)打開(kāi) Interactive Editor Playground 頁(yè)面

互動(dòng)式編輯游樂(lè)場(chǎng)

VS代碼中的核心編輯器包含許多特性。此頁(yè)高亮顯示了10個(gè)特性，每個(gè)特性介紹中都提供了代碼行供你編輯

接下來(lái)的10行內(nèi)容（你可以理解為目錄，對(duì)應(yīng)10個(gè)特性）

多光標(biāo)編輯（Multi-Cursor Editing）- 選擇一塊區(qū)域，選擇所有匹配項(xiàng)，添加其余光標(biāo)等
智能感應(yīng)（intelliSense）- 獲取代碼和外部模塊的代碼幫助和參數(shù)建議
行操作（Line Actions ）- 快速移動(dòng)行以重新排序代碼
重命名重構(gòu)（Rename Refactoring）- 快速重命名代碼庫(kù)中的符號(hào)（比如變量名、函數(shù)名）
格式化（Formatting）- 使用內(nèi)置文檔和選擇格式使代碼看起來(lái)很棒
代碼折疊（Code Folding） - 通過(guò)折疊其他代碼區(qū)域，關(guān)注代碼中最相關(guān)的部分
錯(cuò)誤和警告（Errors and Warnings）- 寫(xiě)代碼時(shí)請(qǐng)參閱錯(cuò)誤和警告
片段（Snippets）- 花更少的時(shí)間輸入片段
Emmet - 只需要敲一行代碼就能生成你想要的完整HTML結(jié)構(gòu)等（極大方便前端開(kāi)發(fā)）
JavaScript Type Checking- 使用零配置的TypeScript對(duì)JavaScript文件執(zhí)行類(lèi)型檢查。
Multi-Cursor Editing

使用多光標(biāo)編輯可以同時(shí)編輯文檔的多個(gè)部分，極大地提高了工作效率

框式選擇
鍵盤(pán)同時(shí)按下 Shift + DownArrow（下鍵）、Shift + RightArrow（右鍵）、Shift + UpArrow（上鍵）、Shift + LeftArrow（左鍵）的任意組合可選擇文本塊
也可以用鼠標(biāo)選擇文本時(shí)按 Shift + Alt 鍵
或使用鼠標(biāo)中鍵拖動(dòng)選擇（可用性很高）
添加光標(biāo)
按 Ctrl + Alt + UpArrow 在行上方添加新光標(biāo)
或按 Ctrl + Alt + DownArrow 在行下方添加新光標(biāo)
您也可以使用鼠標(biāo)和 Alt + Click 在任何地方添加光標(biāo)（可用性很高）
在所有出現(xiàn)的字符串上創(chuàng)建光標(biāo)
選擇字符串的一個(gè)實(shí)例，例如我用鼠標(biāo)選中所有background，然后按 Ctrl + Shift + L，文本中所有的background都將被選中（可用性很高）
IntelliSense

Visual Studio Code 預(yù)裝了強(qiáng)大的JavaScript和TypeScript智能感知。

在代碼示例中，將文本光標(biāo)放在錯(cuò)誤下劃線的上面，會(huì)自動(dòng)調(diào)用IntelliSense

這只是智能提示的冰山一角，還有懸停在函數(shù)名上可以看到參數(shù)及其注釋?zhuān)ㄈ绻校┑鹊?，它?huì)潛移默化的帶給你極大幫助

其他語(yǔ)言在安裝對(duì)應(yīng)插件后，會(huì)附帶對(duì)應(yīng)語(yǔ)言的IntelliSense

Line Actions

分別使用 Shift + Alt + DownArrow 或 Shift + Alt + UpArrow 復(fù)制光標(biāo)所在行并將其插入當(dāng)前光標(biāo)位置的上方或下方
分別使用 Alt + UpArrow 和 Alt + DownArrow 向上或向下移動(dòng)選定行（可用性很高）
用 Ctrl + Shift + K 刪除整行（可用性很高）
通過(guò)按 Ctrl + / 來(lái)注釋掉光標(biāo)所在行、切換注釋?zhuān)捎眯院芨撸?br /> Rename Refactoring

重命名符號(hào)（如函數(shù)名或變量名）

將光標(biāo)選中符號(hào)，按F2鍵
或者選中該符號(hào)，鼠標(biāo)右鍵 > Rename Symbol

重命名操作將在項(xiàng)目中的所有文件中發(fā)生（可用性很高）

Formatting

代碼如果沒(méi)有良好的編寫(xiě)格式，閱讀起來(lái)是一個(gè)折磨

Formatting可以解決編寫(xiě)格式問(wèn)題：無(wú)論你的代碼的格式寫(xiě)的有多么糟糕，它可以將代碼格式化為閱讀性良好的格式

格式化整個(gè)文檔 Shift + Alt + F （可用性很高）
格式化當(dāng)前行 Ctrl + K Ctrl + F（即先按Ctrl，再按K，最后按F）
鼠標(biāo)右鍵 > Format Document （格式化整個(gè)文檔）
將格式化操作設(shè)置為自動(dòng)化（保存時(shí)自動(dòng)格式化整個(gè)文檔）：Ctrl + , 輸入 editor.formatOnSave

Code Folding

鼠標(biāo)操作，自己嘗試一下，秒懂

快捷鍵：

折疊 Ctrl + Shift + [
展開(kāi) Ctrl + Shift + ]

折疊代碼段是基于基于縮進(jìn)

Errors and Warning

錯(cuò)誤和警告將在你出現(xiàn)錯(cuò)誤時(shí)，高亮該代碼行

在代碼示例中可以看到許多語(yǔ)法錯(cuò)誤（如果沒(méi)有，請(qǐng)你隨便修改它，讓它出現(xiàn)錯(cuò)誤）

按F8鍵可以按順序在錯(cuò)誤之間導(dǎo)航，并查看詳細(xì)的錯(cuò)誤消息（可用性很高）

Snippets

通過(guò)使用代碼片段，可以大大加快編輯速度

在代碼編輯區(qū)，你可以嘗試輸入try并從建議列表中選擇try catch，

然后按Tab鍵或者Enter，創(chuàng)建try->catch塊

你的光標(biāo)將放在文本error上，以便編輯。如果存在多個(gè)參數(shù)，請(qǐng)按Tab鍵跳轉(zhuǎn)到該參數(shù)。

Emmet

Emmet將代碼片段的概念提升到了一個(gè)全新的層次（前端開(kāi)發(fā)的大寶貝）

你可以鍵入類(lèi)似Css的可動(dòng)態(tài)解析表達(dá)式，并根據(jù)在abrevision中鍵入的內(nèi)容生成輸出

比如說(shuō)：

然后Enter

JavaScript Type Checking

————————————————
版權(quán)聲明：本文為CSDN博主「索兒呀」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/Zhangguohao666/article/details/105676173

評(píng)論(0) 瀏覽(3017)

242020-4