用戶體驗是用戶在使用產(chǎn)品或者服務中的所有的主觀感受。因此我們設計的過程中要以用戶為中心進行設計，不能單單為了設計一個產(chǎn)品而設計，只關注產(chǎn)品設計本身的功能性。

在生活中好的用戶體驗設計的產(chǎn)品讓人使用舒適，而用戶體驗不好的設計往往讓人很糟糕。

用戶體驗比較好的：比如我們坐地鐵的過程中很準時，這就是好的用戶體驗；在吃海底撈時，看到好吃的西瓜，他們會給你打包，這就是好的用戶體驗。

用戶體驗比較不好的設計：比如在生活中有些插座設計，一個兩孔一個三孔，只能一次插一個，很氣人有沒有，難道上下錯位和間距拉大有這么難嗎？再比如蚊香的設計，很容易斷，每到夏天不斷幾個，都不好意思！

提升用戶體驗的方向

在產(chǎn)品設計中是否滿足用戶需求我們可以分為 3 個點來進行分析，主要是有用性；易用性；滿意度。

1. 有用性

有用性就是產(chǎn)品有用的設計功能，也是產(chǎn)品基礎的設計原則。

對于有用性而言，我們在這個過程可以主要在三個方向進行把控，就是：基本需求；期望需求；興奮需求。

基本型需求

基本型需求是用戶必需需求，用戶在產(chǎn)品中認為這是必需的功能，（這些基本需求是用戶認為必備的，有了用戶覺得是應該的，如果沒有這些需求，那么用戶在使用產(chǎn)品過程中間大部分會直接放棄，選擇其他家產(chǎn)品）。

比如淘寶產(chǎn)品中的訂單和商品功能就是基本型需求；微信中的聊天和通訊錄就是基本型需求；QQ 音樂中的播放頁、播放菜單就是基本需求。

期望型需求

基本型需求是用戶意愿型需求，用戶自己也不知道，但是期望獲得的功能。（這類需求就沒有基本需求那樣必備，是產(chǎn)品中期望需求體驗越多越好，用戶越滿意，反之用戶滿意度也會下降）。

這類需求是期望型需求，也是我們產(chǎn)品競爭力所在，因此往往人們在談論哪個產(chǎn)品好不好，通常是期望需求和興奮型需求。比如淘寶產(chǎn)品中能買到便宜產(chǎn)品，而且符合詳情頁中描述；比如微信產(chǎn)品中聊天語音/微信/視頻，聊天更加方便；比如 qq 音樂中的曲目和歌單數(shù)量增加，用戶就會很滿意，這也是期望需求。

興奮型需求

興奮型需求是用戶非常期望的需求。（這類需求滿意度高，有這些興奮型需求時即使不太完善，用戶也會滿意，做得非常好就會讓用戶興奮；沒有這些需求用戶也不會表現(xiàn)得不滿意）。

比如淘寶產(chǎn)品能夠更多滿足用戶多樣化的生活，各種生活服務提供給用戶；商品評價頁用戶互動，方便用戶可以熟悉產(chǎn)品好壞；比如微信產(chǎn)品中暗黑模式，滿意希望黑暗模式體驗的用戶需求；比如 qq 音樂中單曲熱評，讓我們對歌曲背后的故事，歌友的心路有了了解互動。

此外興奮性需求在產(chǎn)品中還有一些重要的點，比如微動效、情感化設計等等這些都可以讓產(chǎn)品提升很大的用戶體驗，和宣傳力度，因為用戶在談論產(chǎn)品好壞時候比較多的是說產(chǎn)品的興奮型需求。

需求分析模型

需求分析工具 KANO 模型，主要是幫助我們直觀的了解產(chǎn)品不用類型需求實現(xiàn)程度和用戶滿意度的對比，我們了解這些需求的時候，可以讓我們更好的看到這些功能點有哪些影響力。

2. 易用性

易用性就是產(chǎn)品好不好用，容易使用嗎。同時我覺得在有用性上產(chǎn)品經(jīng)理需要考慮得比較多一點，而易用性上就是我們 UI、UE 需要重點負責和掌握的東西。

對于易用性而言，我們可以主要在三個方向進行把控，就是：上手快 ；操作快；負擔少。

上手快

上手快就是用戶使用產(chǎn)品容易上手，沒有啥學習成本。簡單的意思就是讓用戶不怎么動腦去想就知道下一步我要做什么，用戶操作滿足自己的心智模型。

心智模式是指深植我們心中關于我們自己、別人、組織及周圍世界每個層面的假設、形象和故事。并深受習慣思維、定勢思維、已有知識的局限。簡單理解就是在使用產(chǎn)品中滿足我們對產(chǎn)品的認知思維。當然文中介紹的只是心智模型的很一小部分，主要是想讓大家多去了解心智模型，更好地在以后的產(chǎn)品設計中運用它們。

比如淘寶的下單彈窗、微信的紅包、QQ 音樂的音樂播放，都是用戶容易上手，即使小白用戶在使用時，根據(jù)它們簡單的提示就可以操作，沒有太多復雜選項，一目了然。

操作便捷

操作便捷就是用戶在使用產(chǎn)品中操作效率高，沒有太多干擾項目。（這類設計一般就是操作方便，盡可能地減少干擾項目，增加快捷入口等）。

比如淘寶產(chǎn)品中的物流信息，沒有太多干擾直接出現(xiàn)在訂單的頭部位置，提高用戶查看商品物流信息的操作效率，提升了用戶體驗。比如微信聊天中的發(fā)送圖片功能，直接顯示最近圖片，快捷發(fā)送，提高用戶發(fā)送圖片的操作效率。比如 QQ 音樂的播放直接在首頁出現(xiàn)，方便用戶選歌切換，操作效率高。

負擔少

負擔少通常是減少記憶負擔，不讓用戶累著，為用戶分憂。

比如淘寶紅包展示就是在我的頁面里面直接顯示；比如微信錢包余額直接在錢包按鈕下方顯示，不用進入三級頁面；比如 qq 音樂自建歌單顯示歌單數(shù)量，減少用戶記憶負擔。

3. 滿意度

滿意度簡單理解就是用戶需求被滿足后的愉悅感。它是相對的概念，就是用戶需求和產(chǎn)品完成度之間的衡量。

對于滿意度而言，在產(chǎn)品設計上有很多方面，今天我們簡單講一下兩個方向的把控：視覺感官的刺激；獎勵。

視覺感官刺激

視覺感官刺激主要是超乎用戶想象的好看的視覺。而在 UI 設計中主要體現(xiàn)在動效設計、插畫等等。

比如淘寶產(chǎn)品中的圖標動效，趣味設計，提升用戶對產(chǎn)品的情感交流。比如微信聊天中的表情包功能，簡單的動作表達用戶的心理，好看又好玩。比如 QQ 音樂的加載像音符一樣有韻律地跳動著，給用戶帶來不一樣的審美體驗。

獎勵

獎勵是指用戶在完成一些操作時給予獎勵的設計。超出用戶預期，帶來愉悅。

比如淘寶用戶每次下單/參加活動獲得淘氣值，滿 1000 可以購買 88 會員，原件 888。比如 QQ 音樂的活動中心，用戶每日簽到累計可以獲得會員體驗獎勵，更優(yōu)質內(nèi)容的聲音享受激勵。

總結

用戶體驗設計最根本的就是以用戶為中心進行設計，本文主要從有用性、易用性、滿意度三個維度來把控用戶體驗設計，但是在日常工作中，因為產(chǎn)品業(yè)務的復雜程度，我們要因地制宜地進行設計，深入挖掘我們產(chǎn)品自己的體驗設計特色，增加自己的設計市場競爭力。

文章來源：優(yōu)設    作者：阿韓設計

在這篇文章中，我們將討論原型以及如何在 JS 中使用它們進行繼承。我們還將會看到原型方法與基于類的繼承有何不同。

繼承

繼承是編程語言的一個顯著特征，隨著面向對象編程語言的引入而出現(xiàn)。這些語言大多是基于類的語言。在這里，類就像一個藍圖，對象是它的展現(xiàn)形式。就是說，要創(chuàng)建一個對象，首先我們必須創(chuàng)建一個類，然后我們可以從一個類創(chuàng)建任意數(shù)量的對象。

想象一下，我們有一個表示智能手機的類。這個類具有像其他智能手機一樣的可以拍照、有GPS定位等功能。下面是使用 c++ 來描述這樣的一個類：

class SmartPhone {

 public:

 void captureImages() {}

}

SmartPhone x;

x.captureImages()

我們創(chuàng)建了一個名為SmartPhone的類，它有一個名為capturePictures的方法用來拍照。

如果我們需要一個iPhone類，它可以捕捉圖像和一些特殊的功能，比如面部ID掃描。下面是兩種可能的解決方案：

1.將捕獲圖像功能與其他常見的智能手機功能，以及iPhone的特定功能一起重寫到一個新類中。但是這種方法需要更多的時間和精力，并且會引入更多的bug。

重用SmartPhone類中的功能，這就是繼承的作用，繼承也是重用其他類/對象中功能的一種方式。

這里是我們?nèi)绾螐腟martPhone類中繼承capturePictures方法，使用 c++ 實現(xiàn)如下：

class Iphone: public SmartPhone {

 public:

 void faceIDScan() {}

}

Iphone x

x.faceIDScan()

x.captureImages()

上面是一個簡單的繼承示例。 但是，它表明繼承可以使我們以某種方式重用代碼，從而使所生成的程序更不易出錯，并且花費更少的時間進行開發(fā)。

以下是關于類的一些重要信息：

繼承該功能的類稱為子類

被繼承的類稱為父類

一個類可以同時從多個類中繼承

我們可以具有多個繼承級別。 例如，類C繼承自類B，而類B繼承自類A

值得注意的是，類本身并沒有做任何事情。在從類創(chuàng)建對象之前，實際上沒有完成任何工作。我們將看到它為什么不同于JavaScript。

大家都說簡歷沒項目寫，我就幫大家找了一個項目，還附贈【搭建教程】。

原型是什么？

在 JS 中，所有對象都有一個特殊的內(nèi)部屬性，該屬性基本上是對另一個對象的引用。 此引用取決于對象的創(chuàng)建方式。 在 ECMAScript/JavaScript規(guī)范中，它表示為[[Prototype]]。

由于[[Prototype]]鏈接到一個對象，所以該對象有自己的[[Prototype]]引用。這就是建立原型鏈的方式。

這個[[Prototype]]鏈是 JS 中繼承的構建塊。

__proto__ 對象

為了訪問對象的[[Prototype]]，大多數(shù)瀏覽器都提供__proto__屬性。訪問方式如下：

obj.__proto__

需要注意的是，這個屬性不是 ECMAScript 標準的一部分，它實際上是由瀏覽器實現(xiàn)的。

獲取和設置原型方法

除了__proto__屬性外，還有一種訪問[[Prototype]]的標準方法：

Object.getPrototypeOf(obj);

對應的有個類似的方法來設置對象的[[Prototype]]：

Object.setPrototypeOf(obj, prototype);

[[Prototype]]和.prototype屬性

[[Prototype]] 只不過是一種用來表示物體原型的標準符號。 許多開發(fā)人員將其與.prototype屬性混淆，這是完全不同的事情，接著我們來研究一下.prototype屬性。

在 JS 中，有許多創(chuàng)建對象的方法。一種方法是使用構造函數(shù)，像這樣使用new關鍵字來調(diào)用它:

function SmartPhone(os) {

 this.os = os

}

let phone = new SmartPhone('Android')

在控制臺打印 phone 對象：

{

 os: "IPhone"

 __proto__{

   constructor: ? SmartPhone(os)

  __proto__: Object

 }

}

現(xiàn)在，如果我們希望在phone對象上有一些方法，我們可以在函數(shù)上使用.prototype屬性，如下所示:

SmartPhone.prototype.isAndroid = function () {

 return this.os === 'Android' || 'android'

}

再次創(chuàng)建phone對象時，打印 phone 對象如下：

{

 os: "Android"

 __proto__{

   isAndroid: ?()

   constructor: ? SmartPhone(os)

  __proto__: Object

 }

}

我們可以在對象的[[Prototype]]中看到isAndroid()方法。

簡而言之，.prototype屬性基本上就像由給定的構造函數(shù)創(chuàng)建的[[Prototype]]對象的藍圖。 在.prototype屬性/對象中聲明的所有內(nèi)容都會在對象的[[Prototype]]中彈出。

實上，如果將 SmartPhone.prototype 與phone 的[[Prototype]]進行比較，就會發(fā)現(xiàn)它們是相同的：

console.log(Object.getPrototypeOf(phone) === SmartPhone.prototype);

// true

值得注意的是，我們還可以在構造函數(shù)中創(chuàng)建方法：

function ObjectA() {

 this.methodA = function () {}

}

let firstObj = new ObjectA()

console.log(firstObj)

這種方法的問題是當我們初始化一個新對象時。所有實例都有自己methodA的副本。相反，當我們在函數(shù)的原型上創(chuàng)建它時，對象的所有實例只共享方法的一個副本，顯然使用原型的方式效率會過高。

大家都說簡歷沒項目寫，我就幫大家找了一個項目，還附贈【搭建教程】。

當我們訪問屬性時這里發(fā)生了什么？

當我們訪問一個屬性以獲取它時，會發(fā)生以下情況：

JS 引擎查找對象上的屬性，如果找到了該屬性，然后返回它。否則，JS 引擎將通過查看[[Prototype]]來檢查對象的繼承屬性，如果找到該屬性，則返回它，否則，它會查找 [[Prototype]]的[[Prototype]]。 找到屬性或沒有[[Prototype]]時，該鏈結束，這意味著我們已經(jīng)到達原型鏈的末端。

當我們設置/創(chuàng)建屬性時，JS 總是在對象本身上進行設置。 即使[[Prototype]]鏈上存在相同的屬性，下面是一個例子：

function MyObject() {}

MyObject.prototype.propA = 10; // 在原型上創(chuàng)建屬性

let myObject = new MyObject();

console.log(myObject.propA); // [[Prototype]]上的屬性

// 10

myObject.propA = 20; // 對象的屬性

console.log(myObject.propA);

// 20

在上面的示例中，我們創(chuàng)建了一個構造函數(shù)，該函數(shù)的[[Prototype]]上具有屬性propA。 當我們嘗試對其進行讀取操作時，會在控制臺中看到該值。 但是，當我們嘗試在對象本身上設置相同的屬性時；JS 使用給定值在對象上創(chuàng)建一個新屬性。 現(xiàn)在，如果我們不能直接訪問[[Prototype]]上的屬性。

值得注意的是，普通對象的[[Prototype]]鏈的末尾是內(nèi)置的Object.prototype。 這就是為什么大多數(shù)對象共享許多方法（例如toString()）的原因。 因為它們實際上是在Object.prototype上定義的。

使用原型繼承的各種方法

在 JS 中，無論我們?nèi)绾蝿?chuàng)建對象，只有原型繼承，但這些方式還有一些區(qū)別，來看看：

對象字面量

在JavaScript中創(chuàng)建對象的最簡單方法是使用對象字面量：

let obj = {}

如果在瀏覽器的控制臺中打印obj，我們將看到以下內(nèi)容:

clipboard.png

基本上，所有用文字面量創(chuàng)建的對象都繼承了Object.prototype的屬性。

需要注意的是__proto__對象引用了創(chuàng)建它的構造函數(shù)。 在這種情況下，constructor屬性指向Object構造函數(shù)。

使用對象構造函數(shù)

另一種不太常見的創(chuàng)建對象的方法是使用對象構造函數(shù)。JS 提供了一個名為Object的內(nèi)置構造函數(shù)方法來創(chuàng)建對象。

let obj = new Object();

這種方法的結果與對象字面量的方式相同。它從Object.prototype繼承屬性。因為我們使用Object作為構造函數(shù)。

Object.create 方法

使用此輔助方法，我們可以創(chuàng)建一個帶有[[Prototype]]的對象，如下所示：

let SmartPhone = {

 captureImages: function() {}

}

let Iphone = Object.create(SmartPhone)

Iphone.captureImages()

這是在 JS 中使用繼承的最簡單方法之一。猜猜我們?nèi)绾卧跊]有任何[[Prototype]]引用的情況下創(chuàng)建對象？

構造方法

與 JS 運行時提供的對象構造函數(shù)相似。 我們還可以創(chuàng)建自己的構造函數(shù)，以創(chuàng)建適合我們需求的對象，如下所示：

function SmartPhone(os) {

 this.os = os;

}

SmartPhone.prototype.isAndroid = function() {

 return this.os === 'Android';

};

SmartPhone.prototype.isIOS = function() {

 return this.os === 'iOS';

};

現(xiàn)在，我們想創(chuàng)建一個iPhone類，它應該有'iOS'作為它 os 屬性的值。它還應該有faceIDScan方法。

首先，我們必須創(chuàng)建一個Iphone構造函數(shù)，在其中，我們應該調(diào)用SmartPhone構造函數(shù)，如下所示：

function Iphone() {

  SmartPhone.call(this, 'iOS');

}

這會將Iphone構造函數(shù)中的this.os屬性設置為’iOS‘。

之所以調(diào)用SmartPhone.call方法，是因為我們需要更改 this 值以引用Iphone。 這類似于在面向對象的世界中調(diào)用父級的構造函數(shù)。

接下來的事情是，我們必須從SmartPhone構造函數(shù)繼承方法。 我們可以在此處使用Object.create朋友，如下所示：

Iphone.prototype = Object.create(SmartPhone.prototype);

現(xiàn)在，我們可以使用.prototype為Iphone添加方法，如下所示：

Iphone.prototype.faceIDScan = function() {};

最后，我們可以使用Iphone創(chuàng)建一個對象，如下所示：

let x = new Iphone();

// calling inherited method

console.log(x.isIOS()):

// true

ES6 class

使用ES6，整個過程非常簡單。 我們可以創(chuàng)建類（它們與C ++或其他任何基于類的語言中的類不同，只是在原型繼承之上的語法糖），然后從其他類派生新的類。

下面是我們?nèi)绾卧贓S6中創(chuàng)建類:

class SmartPhone {

 constructor(os) {

   this.os = os;

 }

 isAndroid() {

   return this.os === 'Android';

 }

 isIos() {

   return this.os === 'iOS';

 }

};

現(xiàn)在，我們可以創(chuàng)建一個派生自SmartPhone的新類，如下所示：

class Iphone extends SmartPhone {

  constructor() {

    super.call('iOS');

  }

  faceIDScan() {}

}

我們不是調(diào)用SmartPhone.call，而是調(diào)用super.call。 在內(nèi)部，JavaScript引擎會自動為我們執(zhí)行此操作。

最后，我們可以使用Iphone創(chuàng)建一個對象，如下所示

let x = new Iphone();

x.faceIDScan();

// calling inherited method

console.log(x.isIos()):

// true

該ES6示例與先前的構造方法示例相同。 但是閱讀和理解起來要干凈得多。

原文：https://javascript.info/proto...

代碼部署后可能存在的BUG沒法實時知道，事后為了解決這些BUG，花了大量的時間進行l(wèi)og 調(diào)試，這邊順便給大家推薦一個好用的BUG監(jiān)控工具 Fundebug。

自己寫了段jquery的ajax請求，并輸出到頁面的表格中

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>jQuery實現(xiàn)JSONP</title>
</head>
<body>
<div id="mydiv">
    <button id="btn">點擊</button>

    <div id="container">
        <!--每個條目-->
        <div class="item">
            <div class="item-title">作業(yè)名字</div>
            <div>
                <span class="item-content">創(chuàng)建時間</span>
                <span class="item-content">發(fā)布老師</span>
            </div>
        </div>
    </div>
</div>
</body>
<script type="text/javascript" src="https://code.jquery.com/jquery-3.1.0.min.js"></script>
<script type="text/javascript">
    $(function(){
        $("#btn").click(function(){

            $.ajax({
                async : true,
                url : "xxxxxxxxxxx",
                type : "GET",
                dataType : "json", // 返回的數(shù)據(jù)類型，設置為JSONP方式
                jsonp : 'callback', //指定一個查詢參數(shù)名稱來覆蓋默認的 jsonp 回調(diào)參數(shù)名 callback
                jsonpCallback: 'handleResponse', //設置回調(diào)函數(shù)名
                data : {
                    q : "javascript",
                    count : 1,
                    city:'北京'
                },
                success: function(response, status, xhr){
                    // console.log('狀態(tài)為：' + status + ',狀態(tài)是：' + xhr.statusText);
                    // console.log(response);

                    var group = response.hourly_forecast;

                    console.log(group,111111111)
                    console.log(group.length,222222222222)

                    //拼接字符串
                    var str = '';
                    //對數(shù)據(jù)做遍歷，拼接到頁面顯示
                    for(var i=0;i<group.length;i++){
                        str += '<div class="item">'+
                                '<div class="item-title">'+ group[i].date +'</div>'+
                                '<div>'+
                                '<span class="item-content">'+ group[i].hum +'</span>'+
                                '<span class="item-content">'+ group[i].pop +'</span>'+
                                '</div>'+
                                '</div>';
                    }
                    //放入頁面的容器顯示
                    $('#container').html(str);

                }
            });
        });
    });

    function handleResponse(response){
        // 對response數(shù)據(jù)進行操作代碼
        alert("jsonp success!");
    }
</script>
</html>

jquery中ajax處理跨域的三大方式

一、處理跨域的方式：

1.代理

2.XHR2

HTML5中提供的XMLHTTPREQUEST Level2（及XHR2）已經(jīng)實現(xiàn)了跨域訪問。但ie10以下不支持

只需要在服務端填上響應頭：

header("Access-Control-Allow-Origin:*");

/*星號表示所有的域都可以接受，*/

header("Access-Control-Allow-Methods:GET,POST");

        

            3.jsonP
        

        

            原理：
        

        

             ajax本身是不可以跨域的，
通過產(chǎn)生一個script標簽來實現(xiàn)跨域。因為script標簽的src屬性是沒有跨域的限制的。
        

        

            其實設置了dataType: 'jsonp'后，$.ajax方法就和ajax XmlHttpRequest沒什么關系了，取而代之的則是JSONP協(xié)議。JSONP是一個非官方的協(xié)議，它允許在服務器端集成Script tags返回至客戶端，通過javascript callback的形式實現(xiàn)跨域訪問。
        

        

             ajax的跨域寫法：
        

        

            （其余寫法和不跨域的一樣）：
        

        

            比如 
        

在很多設計作品中，我們不難發(fā)現(xiàn)對于材質的運用是十分廣泛的，合理地運用材質可以很大程度地提升作品的質感、細節(jié)感！但是相反，如果使用不得當它也可以毀掉一個原本不錯的作品，很多人對于材質的理解存在著一定局限性，那么本期內(nèi)容：設計中材質有哪些運用形式？應該如何合理地運用材質？

材質運用的誤區(qū)

很多人對于材質并不陌生，但是每次使用后最終結果總是差強人意，這里首先要說的就是材質運用的幾個常見誤區(qū)：

• 誤區(qū)一：材質種類用的越多越好，這是很多人容易走進的一個誤區(qū)，材質的運用要結合畫面整體，運用材質的目的是提升設計作品的出彩度，而非刻意使用，過多不同形式的材質會使得畫面雜亂。
• 誤區(qū)二：不了解材質所傳遞的信息，其實不同形態(tài)的材質所傳遞的信息是不同的，有些材質也會存在一定的使用局限性。
• 誤區(qū)三：一味地追求材質表現(xiàn)，而忽略了主體，材質在很多時候只是輔助畫面，提升整體細節(jié)感的一種手法，不能因為過度強調(diào)材質而搶了主體。

那么應該如何合理地運用材質呢？

背景添加材質

在日常工作中，背景添加材質、肌理的手法是很常用的，但是表現(xiàn)手法上也是有所不同的，表現(xiàn)形式一：將材質、肌理作為背景形象的一部分，也就是將材質做得足夠明顯，這么做的目的是豐富畫面視覺層次變化，增強畫面整體對比，比如我們常見的：

通過對比不難發(fā)現(xiàn)有無材質對于整體的影響，同樣的構圖，沒有材質變化的畫面給人一種很單薄、視覺形象不夠鮮明的感覺，但是通過添加材質、肌理，畫面整體的豐富度大大提升，背景畫面的變化增強，通過材質的變化，也使得主體的視覺形象也更加鮮明；將材質作為背景的組成部分，一定要切記時刻圍繞主體展開，主體的位置是不可撼動的。

表現(xiàn)形式二：將材質、肌理作為畫面視覺中相對較弱的表現(xiàn)形式，也就是做得不明顯，縮小看幾乎沒有，正常看的情況下又有一定的變化，這種表現(xiàn)形式目的在于增加畫面細節(jié)感，使得畫面不會因為缺少變化而略顯單調(diào)，比如：

這種表現(xiàn)手法放小了看對于畫面的影響并不大，但是如果 1:1 正常比例看，有材質的畫面會給人一種細節(jié)感豐富、畫面充滿不同層次的變化感受，這樣帶給作品更多的可塑性，使得畫面給人的視覺感受更深刻，同時也起到了一定的豐富畫面的作用。

文字添加材質

對于在文字中疊加材質在一些作品中是很常見的，同樣的文字，給予不同的材質也會呈現(xiàn)出不同的視覺感受，更多的目的是提升文字與整體形象的契合度，增強整體視覺沖擊力，比如：

材質在很大程度上可以提升文字的立體形象，使得文字在整體的視覺形象更加鮮明，但是對于材質的運用也要做到有所選擇，每種材質所傳遞的視覺信息都有所不同，要讓材質與文案、主題相契合才能將材質的效果發(fā)揮得淋淋盡致，這一點很重要，比如：

這里只考慮材質對文字的影響，首先我們解讀文字「第一戰(zhàn)場」，讓我們首先聯(lián)想到的就是破損、狼藉、金屬等等，那么在給這一文字添加材質時我們就要結合主題；上面兩種的材質分別是木紋和大理石，給人的感覺是太過干凈、簡約，與戰(zhàn)場主題不相符，所以說材質使用不得當，而后面兩個的材質分別是破損的石灰墻以及金屬，就能在很大程度上加強「戰(zhàn)場」這一主題的視覺形象，在視覺上屬于強調(diào)的作用。

材質使用技巧

材質的選擇和使用也是有一定技巧可言的，這里首先要說下：當我們想要使用材質時，應該如何選擇呢？

結合整體風格選擇，比如畫面整體偏簡約、干凈的感覺，我們就可以嘗試：大理石、木紋、石灰墻、花紋、木紋等等；再比如想要炫酷效果，那么我們就可以嘗試：金屬、破損墻壁、石頭等等，也就是說盡可能讓材質本身的風格偏向畫面整體風格，這樣可以讓材質更加融合畫面，不會給人一種很突兀、刻意的感覺。

結合產(chǎn)品選擇，一切的手法、技巧都是要服務于產(chǎn)品、主體的，結合產(chǎn)品選擇材質也是很常用的；比如一些化妝品海報，我們可能用到的材質會有：水、植物、大理石、木紋或者產(chǎn)品本身所固有的材質等等，目的是凸顯產(chǎn)品的美觀、功效，讓用戶能夠在背景及產(chǎn)品之間產(chǎn)生共鳴、聯(lián)想，這樣也能起到對產(chǎn)品的強調(diào)輔助作用。

關于使用：通常找到合適的材質后，會銳化一下，目的是增強材質的質感，然后會用不同的圖層模式去試，（一般情況下會用「正片疊底、濾色、疊加、柔光的模式」）以便找到最佳的使用形式；當然如果只用材質的紋理感覺，不用材質本身顏色的話，也可以去色后再去選擇圖層模式。

案例演示

結合本期內(nèi)容，做了一個簡單的化妝品的海報，充分利用材質的不同表現(xiàn)形式，用分析的角度去觀察，第一步，通過運用 C4D 軟件，做一個簡易場景：

簡易場景搭建完成，因為只是黑白稿的場景，那么接下來就要通過分析產(chǎn)品確定材質的選擇：

產(chǎn)品的感覺是干凈、簡約的，那么就圍繞這個整體感覺，展開材質的貼合及制作，這里我選擇紋理相對不復雜的大理石為主要材質，結合用到木紋、金屬作為豐富畫面的材質：

這樣一個畫面給人的感覺是輕飄飄的，因為沒有影子，沒有將畫面做出光感的效果，而且整體缺少色感，這里我選擇把原本無色的材質換成有色材質，目的是增加畫面整體色感，其次將投影、倒影做好，光源定在左側，最終呈現(xiàn)的效果：

最終的呈現(xiàn)幾乎是用不同材質做出來的一個場景，雖然這里用到了很多不同顏色的材質，但是最終用到的材質屬性只有三種：大理石、木紋 、金屬，而且依舊貫徹干凈、簡約的視覺感受，將同種材質的不同形態(tài)運用在一起會給人視覺聯(lián)系的作用，不會給人一種雜亂的感覺！

總結

材質對畫面是輔助、豐富、增加細節(jié)感的作用，合理地運用材質可以提升設計作品的視覺層次、增強畫面質感！但是不管是哪種形式的材質，都要做到切合主題，要讓設計的每個元素做到有理有據(jù)，切記不要因為材質的過于凸顯而搶了主體。

文章來源：優(yōu)設    作者：

美工美邦

大家平常都習慣去哪些免費圖庫網(wǎng)站找圖呢？雖然有一些老牌、圖片數(shù)量充足的圖庫，像是 Unsplash、Pixabay、Pexels，但后來經(jīng)過人工智能和大數(shù)據(jù)學習的搜尋工具更深得我心，也能通過算法將質量較低、不適合使用的圖庫圖片先排除掉，大幅節(jié)省搜尋時間。如果在尋找圖片素材時想盡量避免使用和其他人重復的內(nèi)容，試試看由攝影師親自拍攝的小型圖庫或許是個不錯的方法。

往期回顧：

本文要介紹的「DesignersPics」是一個持續(xù)更新、每個月都會加入新相片的圖庫，由攝影師 Jeshu John 親自拍攝修圖，收錄各種類型的相片，包括建筑、商業(yè)活動、概念、美食和飲料、大自然、人物、科技等等，照片數(shù)量不多，但有一定的獨特性。

DesignersPics 的相片都具有非常高的分辨率和畫質，可自由下載用于個人或商業(yè)用途，例如網(wǎng)站、投影片、包裝、標簽、HTML/PSD 模版、T-Shirts、廣告橫幅、商店或辦公室裝飾等等，無需標示出處來源。

DesignersPics

網(wǎng)站鏈接：http://www.designerspics.com/

使用教學

開啟 DesignersPics 從右上角的「Categories」選擇要瀏覽的相片分類，或是直接從首頁以日期方式瀏覽，網(wǎng)站亦提供搜尋功能，不過圖庫本身相片量不多，瀏覽上不會耗費太多時間。

每張相片會有預覽圖、標題和免費下載的按鈕。

進入圖片頁面，還能看到圖片尺寸、大小等等信息，點選「Download」就能下載取得 .jpg 格式的圖片文件。雖然 DesignersPics 沒有硬性規(guī)定必須標示作者來源，但如果你喜歡可以協(xié)助推廣。

值得一試的三個理由：

• 由 Jeshu John 親自拍攝，每個月都會更新加入新的相片素材
• 相片都具有大尺寸及高畫質，免費下載取得 .Jpg 格式

• 可自由使用于個人或是商業(yè)用途

文章來源：優(yōu)設    作者：Pseric

一覺醒來，2020 年潘通年度色就這么發(fā)布了。

2020年年度潘通色：「經(jīng)典藍」

這款被命名為為「經(jīng)典藍」（Classic Blue）的色彩沉穩(wěn)耐看，雋永優(yōu)雅，按照潘通官方的說法，「經(jīng)典藍」仿佛暮色四合時的天空，寧神靜心，讓人駐足。「經(jīng)典藍」是一種穩(wěn)固可靠的色彩，給人確信感，撫慰著每一個期待穩(wěn)定者的心靈。

為什么會選擇這樣一種藍色，潘通色彩研究所的執(zhí)行董事 Leatrice Eiseman 在潘通官網(wǎng)上，予以詳細的解釋。

解讀「經(jīng)典藍」

「我們生活在一個亟需信念和信任的時代。潘通 19-4052 經(jīng)典藍 ，這種色彩正是自信和恒久的外化體現(xiàn)，這種堅實可靠的藍色調(diào)，更能與人產(chǎn)生深層的共鳴，令人心安。一望無際的藍色能夠喚起人類對于廣袤無垠夜空的無限遐想，經(jīng)典藍鼓勵著我們透過顯而易見的事實，拓展思維，放飛想象。

經(jīng)典藍敦促著我們更加深入地思考，開闊視野，進行更加深入的交流。」

——Leatrice Eiseman 潘通色彩研究所執(zhí)行董事

從色彩心理學的角度上來看，藍色色相本身有著信任、信念的含義，也是的色相。在此之前，潘通曾經(jīng)多次選擇藍色作為年度色， 2000 年的時候選擇天藍色（Cerulean），在 2005 年的時候則選擇了藍綠色（Blue Turquoise），2008 年的年度色叫鳶尾藍（Blue Iris），2016 年的年度色則是靜謐藍（Serenity）。

相比于這4種藍色，「經(jīng)典藍」更為沉靜穩(wěn)重，沒有一點攻擊性，也不顯得沉重，輕松而易于互動。

「經(jīng)典藍」無疑是一個略顯保守，但是非常貼合當下語境的色彩。它充滿了確信感，讓人覺得安全，屏蔽了焦慮。同 2019 年充滿前進感的「活力珊瑚橙」相比，「經(jīng)典藍」更加內(nèi)斂和篤定，悄無聲息地增加每一個的信心。

除了發(fā)布這一年度色彩之外，潘通色彩研究所還專門制定了5套配色方案，這些配色方案應該會在接下來的 2020 年，得到更加廣泛的應用。

「經(jīng)典藍」的5套官方配色方案

沉思

這是一套舒緩的配色方案，涼爽的藍色調(diào)和同樣柔和的暖色組合到一起，給人以沉靜的感覺。

呼吸

這套名為呼吸的配色方案當中，加入了更為經(jīng)典的黑白色，選擇了對比更加強烈、更加富有活力的搭配方式。這樣的色彩搭配更容易喚起觀者的幸福感，讓你的設計更加具有田園牧歌的氣息。

沙漠暮色

「經(jīng)典藍」的靈感來源之一就是夜幕降臨時的天空。而這套名為沙漠暮色的配色方案，就與此相關。充滿金屬質感的潘通色更能夠凸顯「沙漠」的閃亮質感，而恰為對比色的「經(jīng)典藍」讓這套配色方案優(yōu)雅無比。

異域風情

這套配色方案比起之前的配色更加豐富，更顯混搭，仿佛加入了天然的調(diào)味料。這種健康而自我的色彩搭配方式，讓人仿佛身在異域，不同于此地的文化，迥異與此時的感覺，獨特卻令人著迷。

非傳統(tǒng)

打破常規(guī)的桎梏，選擇異乎尋常的色彩搭配，而足夠傳統(tǒng)的「經(jīng)典藍」恰恰構成了這種搭配方式當中，作為基礎的底色。這套配色方案指向時尚，突破規(guī)則，如同小品，有趣而俏皮。

「經(jīng)典藍」的9套精選配色方案

為了更加方便線上的設計師來使用這些配色方案，優(yōu)設的小編從官方提供的這些配色方案當中，精心挑選了 9 套適合進行數(shù)字設計的配色方案，并且標注上了相應的 HEX 值便于精準取色，請盡情取用：

轉自：站酷——hicatherine86 

語法

emcc [options] file ...

這個輸入文件file，既可以是clang可以編譯的C/C++語言，也可以是二進制形式的llvm bitcode或者人類可讀形式的llvm assembly文件。

參數(shù)

大部分clang或者gcc的選項（option）都是可以工作的，比如：

# 顯示信息 emcc --help # 顯示編譯器版本信息 emcc --version

如果想看當前Emscripten中clang版本支持的全部選項列表，可以直接使用命令：
clang --help.

emcc修改的或者emcc中新的選項列在下面：

首先是一些編譯優(yōu)化flag，它們-O0，-O1，-O2，-Os，-Oz，-O3。

-O0：
不進行編譯優(yōu)化（這是默認情況）。當你剛開始移植項目是推薦使用它，因為它會包含許多斷言。

-O1：
簡單優(yōu)化。推薦你在既想縮短編譯時間又想編譯優(yōu)化時使用。它畢竟比-O2級別的優(yōu)化編譯起來快多了。它會進行asm.js和llvm的-O1進行優(yōu)化，它會relooping，會刪除運行時斷言和C++異常捕獲，它也會使得-s ALIASING_FUNCTION_POINTERS=1。

想要C++異常捕獲重新可用，請設置：-s DISABLE_EXCEPTION_CATCHING=0。

-O2：
和-O1類似，不過多了JavaScript級別的優(yōu)化以及一些llvm -O3的優(yōu)化項。當你想發(fā)布項目的時候，推薦使用本級別優(yōu)化。

-O3：
和-O2類似，不過比-O2又多了一些JavaScript優(yōu)化，而且編譯時間明顯比-O2長。這個也推薦在發(fā)布版本的時候使用。

-Os:
和-O3類似，不過增加了額外的優(yōu)化以減小生成的代碼體積，代價是比-O3性能差一點。-Os優(yōu)化會同時影響llvm bitcode 和JavaScript文件的生成。

-Oz:
和-Os類似，不過進一步減小了代碼體積。

-s OPTION=VALUE
傳給編譯器的所有涉及到JavaScript代碼生成的選項。選項列表，請見settings.js。

對于某個選項的值，不僅可以直接在emcc命令行里面設定，也可以把他們寫成json文件。比如下面，就是將DEAD_FUNCTIONS選項的值放到了path/to/file文件里，emcc里面?zhèn)鬟@個文件的路徑。

-s DEAD_FUNCTIONS=@/path/to/file

note: 1、文件內(nèi)容可以是：["_func1","_func2"]； 2、文件路徑必須是絕對的，不能是相對的。

-g：
這是保留調(diào)試信息flag。

• 如果只是編譯到bitcode，那就和clang和gcc中的-g一樣。
• 如果是要編譯到JavaScript，-g就等于-g3。

-g<level>
控制打印的調(diào)試信息數(shù)量，每一個level都是在前一個level的基礎上編譯的：

• -g0:不保留調(diào)試信息。
• -g1:保留空格,不壓縮。
• -g2:保留函數(shù)名。
• -g3:保留變量名，與-g同。變量名一般不是必須編譯后保留的，但是如果保留了，可以推斷變量的目的，對吧。
• -g4:保留llvm 調(diào)試信息，這是能調(diào)試的最高級別。

note：
優(yōu)化級別越高，編譯時間越長

--profiling:

--profiling-funcs:

--tracing:
啟用Emscripten的tracing API。

--emit-symbol-map：

--js-opts<level>:
允許JavaScript優(yōu)化，有兩個值：
0：不允許JavaScript優(yōu)化器允許；
1：使用JavaScript優(yōu)化器。
通常用不到我們設置這一項， 因為設置-O后面的level的時候，這個項就能順便取到一個合適的值。

note：
有些選項會重寫這個flag的值，比如EMTERPRETIFY, DEAD_FUNCTIONS, OUTLINING_LIMIT, SAFE_HEAP 和 SPLIT_MEMORY會將js-opts=1，因為他們依賴js優(yōu)化器。

--llvm-opts<level>:
啟用llvm優(yōu)化。它的取值有有：

• 0：不使用llvm優(yōu)化
• 1：llvm -O1優(yōu)化
• 2：llvm -O2優(yōu)化
• 3：llvm -O3優(yōu)化

和--js-opts<level>一樣，通常用不到我們設置這一項， 因為設置-O后面的level的時候，這個項就能順便取到一個合適的值。

--llvm-lto<level>:
啟用llvm 連接時 優(yōu)化。可以取值0，1，2，3。

--closure <on>：
運行壓縮編譯器（Closure Compiler），可能的取值有，0,1,2：

• 0：是不啟用壓縮編譯器。
• 1：啟用。
• 2：啟用。

--pre-js <file>
生成代碼前，指定一個要把內(nèi)容添加進來的文件。

--post-js <file>
生成代碼后，指定一個要把內(nèi)容添加進來的文件。

--embed-file <file>
指定一個帶路徑的文件嵌入到編譯生成的js代碼里。路徑是相對于編譯時的當前路徑。如果傳的是一個目錄，則目錄下所有文件的內(nèi)容都會被嵌入到將來生成的js代碼中。

--preload-file <name>
異步運行編譯代碼前，指定一個預加載的文件。路徑是相對于編譯時的當前路徑。如果傳的是一個目錄，則目錄下所有文件的內(nèi)容都會被預加載到一個.data文件中。

--exclude-file <name>
從 –embed-file and –preload-file后面的目錄中排除一些文件，支持使用通配符*。

--use-preload-plugins
告訴文件打包器當文件加載時，運行預加載插件。它用來執(zhí)行諸如使用瀏覽器解碼器解碼圖片和音頻等。

--shell-file <path>
指定要生成HTML的模板文件。

--source-map-base <base-url>

--minify 0
等于-g1。

--js-transform <cmd>
優(yōu)化之前，生成代碼之后，設定這一條命令。這條命令可以讓你修改JavaScript代碼。之后，編譯器會將修改的和未修改的一起進行編譯優(yōu)化。

--bind
啟用bingdings編譯源代碼。bingings是Emscripten中連接C++和JavaScript代碼的一類API。

--ignore-dynamic-linking
告訴編譯器忽視動態(tài)鏈接，之后用戶就得手動鏈接到共享庫。

--js-library <lib>
定義除了核心庫(src/library_*)以外的js庫。

-v
打開詳細輸出。
這個設置為把-v傳給clang，并且啟用EMCC_DEBUG生成編譯階段的中間文件。它也會運行Emscripten關于工具鏈的內(nèi)部的完整性檢查。

tip: emcc -v是診斷錯誤的有用工具，不管你是否附加其他參數(shù)。

--cache

--clear-cache

--clear-ports

--show-ports

--save-bc PATH

--memory-init-file <on>
規(guī)定是否單獨生成一個內(nèi)存初始化文件。取值包括0和1.

• 0：不單獨生成.mem文件。
• 1：單獨生成.mem文件。

-Wwarn-absolute-paths
啟用在-I和-L命令行指令中使用絕對路徑的警告。這是用來警告無意中使用了絕對路徑的。在引用非可移植的本地系統(tǒng)頭文件時，使用絕對路徑有時是很危險的。

--proxy-to-worker

--emrun
使生成的代碼能夠感知emrun命令行工具。當運行emran生成的應用程序時，這樣設置就允許stdout、stderr和exit(returncode)被捕獲。

--cpuprofiler
在生成的頁面上嵌入一個簡單的CPU分析器。使用這個來執(zhí)行粗略的交互式性能分析。

--memoryprofiler
在生成的頁面上嵌入內(nèi)存分配跟蹤器，使用它來分析應用程序Emscripten堆的使用情況。

--threadprofiler
在生成的頁面上嵌入一個線程活動分析器。當進行多線程編譯時，使用它來分析多線程應用程序。
--em-config

--default-obj-ext .ext

--valid-abspath path
設置一個絕對路徑的白名單，以防止關于絕對路徑的警告。

-o <target>
編譯輸出的文件格式。target可以取值為：

• name.js:JavaScript文件；
• name.html：HTML+js文件。把js單獨生成是為了減小頁面加載時間。
• name.bc：llvm bitcode。這是默認值。
• name.o：和上面一樣。

note:
如果你用了--memory-init-file，則還會從js文件中再單獨分出一部分代碼為.mem文件。

-c
生成llvm bitcode代碼，而不是JavaScript。

--separate-asm
把asm.js文件單獨生成到一個文件中。這樣可以減少啟動時的內(nèi)存加載。

--output_eol windows|linux
規(guī)定生成的文本文件的行尾，如果是–output_eol windows，就是windows rn行尾，如果是–output_eol linux，則生成Linux行尾的文本文件。

--cflags

環(huán)境變量

emcc會受到幾個環(huán)境變量的影響，如下：

• EMMAKEN_JUST_CONFIGURE
• EMMAKEN_JUST_CONFIGURE_RECURSE
• EMCONFIGURE_JS
• EMCONFIGURE_CC
• EMMAKEN_CXX
• EMMAKEN_COMPILER
• EMMAKEN_CFLAGS
• EMCC_DEBUG

這幾個里面比較有意思的是EMCC_DEBUG。比如，如果你在編譯之前設置set EMCC_DEBUG=1，那么編譯的時候會把編譯過程的調(diào)試信息和編譯各個階段的中間文件輸出到一個臨時目錄，這算是給開發(fā)者提供一些編譯期間的幫助或者說調(diào)試信息吧。

Emscripten主題系列文章是emscripten中文站點的一部分內(nèi)容。
第一個主題介紹代碼可移植性與限制
第二個主題介紹Emscripten的運行時環(huán)境
第三個主題第一篇文章介紹連接C++和JavaScript
第三個主題第二篇文章介紹embind
第四個主題介紹文件和文件系統(tǒng)
第六個主題介紹Emscripten如何調(diào)試代碼

這幾天在工作中處理了一個歷史遺留問題：彈窗適配，幾經(jīng)折騰終于落定發(fā)包。于是我也趁著這個機會把彈窗體系梳理研究了一遍。

我們常見的彈窗有對話框，提示框，有時候在需求溝通中經(jīng)常會聽到產(chǎn)品同學說，給這里加個彈窗，那里加個提示框吧。實際上，這個彈窗到底該不該加？這個彈窗承載的是提示說明文字內(nèi)容，還是需要引導用戶下一步操作？接下來我們從彈窗的屬性來聊聊我們的彈窗到底在什么時候加比較合適？用什么形態(tài)展示體驗會更好？

彈窗體系：模態(tài)與非模態(tài)

模態(tài)彈窗：是指在用戶任務中，終止了用戶的上一步行為。也就是說，這個模態(tài)彈窗必須要用戶操作才可以進行下一步動作。所以在產(chǎn)品設計中，我們通常會用模態(tài)彈窗引導用戶去做我們要他做的操作。

常見的模態(tài)彈窗有這幾種：對話框、動作欄、浮層。

對話框：對話框主要是給用戶提供選項、相關的操作。另外，在一些對話框中，也可以展現(xiàn)圖片、頭像、步驟圖、其它輸入項等。

動作欄：常見的動作欄一般會出現(xiàn)屏幕下方，比如選擇某個內(nèi)容時候，出現(xiàn)的選擇。

浮層：彈出窗口，浮動于頂層窗口，氣泡。

非模態(tài)彈窗：是指不強制用戶操作，他的作用相當于內(nèi)容信息提示，他的出現(xiàn)不打擾用戶的當前操作，并且有時間限制，在一定時間里能自動消失。比如「xxx 功能已更新哦」，這種提示是不需要用戶點擊操作，讓用戶看到就可以了。

常見的非模態(tài)彈窗有這幾種：toast/hud、snackbar、notice（通知）

toast/hud：iOS 用戶更習慣于在中間感知反饋信息，通常在信息提示完 3 秒左右后會消失，安卓通常會出現(xiàn)在屏幕頂部或者下部，不會遮擋主體內(nèi)容。需要注意的是 toast 只有文字，hud 是可以帶有圖標的。

snackbar；可以理解為加強版的 Toast

notice：系統(tǒng)消息、通知推送，也是不干擾用戶行為，有消失時間，是非模態(tài)的彈窗。

什么場景下使用什么彈框

了解完彈窗體系后，我們就可以針對具體場景來看產(chǎn)品同學說加個彈窗到底合適不合適？我們可以從下面的幾個使用場景來看用什么樣的彈窗合適。

1. 重要打斷用戶操作

在一些重要操作，避免用戶操作失誤。不過目前很多人都覺得這類彈框有利有弊，有的地方出現(xiàn)得不合時宜，打斷了用戶的使用狀態(tài)。所以在設計這類彈框時要非常謹慎，得通過多研究確認是否有必要出現(xiàn)。

對話框相對來說比動作欄更重要，因為在視覺中心，更能強烈引起用戶的重視，對于十分重要的內(nèi)容需要打斷用戶上一步任務的，采用對話框的彈窗，對于不是特別重要信息露出又需要終止用戶上一步動作的情況下，一般采用動作欄彈框。

2. 定制化廣告彈窗

如功能更新、升級、優(yōu)惠券彈窗。這一類一般是強制用戶看到的，要展示出與眾不同的特色，在視覺上比較突出，會使用模態(tài)的彈窗浮層形式。

3. 給予一定提示

比如提示用戶狀態(tài)、信息、反饋，確保用戶知曉自己所處的狀態(tài)，并可以做出相應的措施。一般使用非模態(tài)的彈窗。

4. 用戶操作反饋

出現(xiàn)在用戶操作完之后的反饋，比如提醒用戶頁面正在加載中、保存成功、已刪除、已刷新等等。

可以不用彈窗的反饋例子：完成頁

比如已支付成功、下載完畢、簽到成功，這一類是告訴你上個動作結束了，下一步不需要進行引導了，這種反饋大多數(shù)都不采用彈窗形式展現(xiàn)了。

需要注意事項

1. 層級關系

彈框是內(nèi)容和導航的補充，用于通知、操作菜單、成功或加載狀態(tài)的 toast，他是寫在蒙層上面的一層內(nèi)容。

2. 適配方式

下面我們需要了解的是這幾種彈窗在開發(fā)那的實現(xiàn)形式。我們可以理解為 2 種形式：

一種是開發(fā)直接用系統(tǒng)的接口，缺點是具有不可定制，形式美觀度不夠好。

另一種是開發(fā)用代碼會單獨寫出一個模態(tài)彈框系統(tǒng)，這套系統(tǒng)與整體設計語言具有一致性，可以復用在各個任務中，可以定制化設計。

需要注意的是，代碼寫出來的模態(tài)樣式要考慮在不同機型的適配情況，考慮不同機型的邊界。這個適配也有兩種實現(xiàn)形式，一種是固定寬高尺寸，展示在不同機型尺寸中，另一種是常用的等比例縮放。這個就需要開發(fā)與設計進行密切的溝通，能盡量合理地在不同機型展現(xiàn)更加合適，避免出現(xiàn)極限的情況。

我們是這樣操作的，為了避免尺寸比例混亂的情況，會設計一個彈窗的寬高尺寸范圍，開發(fā)同學代碼寫出的這套彈窗的適配在各個機型中，是在一定縮放比例下，適用各個不同情況下的視覺展示。這套彈窗可以調(diào)用在首頁引導、升級等各個頁面的彈窗設計中。

文章來源：優(yōu)設    作者：詠舍