整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
要：HI，朋友們好，有許多事情看起來都很簡單，但是當自己做的時候發現其實堅持下去并不容易，比如我的這個計劃，1000家網站計劃，看起來人人都會做，但想要每天堅持寫下來卻是不容易的。之前我也介紹過不少圖形設計工具了，不知道你們有沒有使用，國內比較好用的如：創客貼，也是我經常使用的，今天我在找雜志封面制作工具的時候，一搜發現了一大把，但是后來用了用還是FotoJet比較好用一點，和其他圖形設計工具都差不多，還支持中文站，挺值得收藏的，后面還有許多有意思的網站等你發現，自己看著需要哪個拿走吧。
超強的雜志封面制作工具：FotoJet
你不需要很好的Photoshop、AI技巧，就能制作出一整本很不錯的封面設計，信嗎？通過雜志封面制作工具，您只需點擊一下鼠標，即可將自己的照片放在人物，花花公子，時間，財富等知名雜志的封面模板上。FotoJet是一個提供在線免費的圖片拼貼模版，幫助用戶輕松的實現圖片拼接組合，無需注冊和下載即可使用，網站內置了320+套精致的模版和80+經典的布局樣式，支持添加文字和剪貼畫圖片、背景圖片。該網站有許多模板可供選擇，可以JPG或PNG格式保存你的雜志封面，或直接分享到社交媒體，支持中文站。
推薦度：★★★★★
支持私有云部署的文檔管理系統：KodExplorer
與其把自己的照片、文檔、視頻等重要資料交給某數字公司、某競價排名公司、某社交軟件公司，還不如把這些個人的重要數據緊緊地握在手里。（KodExplorer）可道云是一個基于企業私有云和在線文檔管理的資源管理器，該平臺是基于Web技術的私有云和在線文件管理系統，可用于服務器文件管理，支持圖片、音樂、視頻預覽，在線解壓縮，文件夾拖拽上傳，遠程離線下載。支持Office的在線預覽和編輯，可多人協同編輯作業，文檔歷史版本回溯，更有Photoshop、Ai、AutoCAD等專業文檔的在線預覽，支持圖形編輯，圖片粘貼、數據報表生成等。多人實時在線協同編輯，實時查看他人改動，實時保存和自動版本合并。可設定到期時間、提取密碼、下載權限，滿足更多場景需求，輕松將文件分享給客戶、同事查看。內置輕應用和插件市場，數百種插件和拓展支持，從辦公環境到個人娛樂，幾乎覆蓋日常使用所有需求。
推薦度：★★★★★
旅游出差比價的報銷助手：報銷吧
現在很多企業機構的費用報銷，會抱一堆發票，跑到財務那里報銷。有時候，發票比較多，財務一張一張核對，過于繁瑣；有時候，員工又會把發票弄丟，雖然可以找其他發票替代，卻加重了財務核對的工作量。報銷吧是一家在線的企業級差旅和費用報銷管理工具，也支持手機App。基于華為的費用管理思想，同時也是華為云解決方案合作伙伴。平時我們商務、銷售、市場、老板人員出差要訂票、打車、住酒店，而報銷吧整合國內的眾多旅游服務商，比如：飛鶴航空、攜程與同程網的機票酒店、滴滴出行企業版、京東企業購等，一款軟件內可以實現商務出差全過程，從出差到報銷，無需再下載多個軟件應用，只需一個報銷吧，就可以實現應用內一站式預訂機票、酒店、火車及打車和出差比價的功能，由于集中采購所以要比攜程優惠很多，出差與報銷的人員（上班族）必備。
推薦度：★★★★★
可視化協作圖表編輯工具：Lucidchart
這款圖表編輯工具功能強大，不論是在線還是離線都隨時隨地進行圖表繪制，同時可輕松與他人分享圖表。Lucidchart是一個基于HTML5的功能完善的在線流程圖繪制和協作應用，可以方便快速的實現流程圖表的繪制，同時還可以和他人進行實時的流程圖繪制和修改，所有的變動都會實時的同步，對于群組協作來說是很方便的工具。提供了很多免費繪圖模板，大大地加快了用戶的繪圖速度。從數百種形狀中進行選擇，支持 Autoprompt，快速添加和連接對象，從任何對象拖拽出新線條，拖放來添加您自己的圖片，導出為（矢量）PDF、PNG 和 JPG- 嵌入圖標至博客，包含熱點和狀態的交互式實體模型，從 microsoft Visio （vdx） 導入文檔，國內也有同類產品ProcessOn。
推薦度：★★★★★
可反向在線制作GIF動畫圖片的工具：Freegifmaker.me
想要制作gif動畫圖片嗎？相信不少人都會有這個想法吧。每天你都可以在社交網絡上看到許多有趣的動畫GIF。但是，你有沒有想過如何動畫看起來相反的順序？倒過來的GIF可能會更有趣。Freegifmaker.me是一個免費在線制作GIF動畫圖片的應用，使用非常簡單，無需注冊。制作非常簡單，打開網站，然后選擇一個GIF動畫模板，如大鼻子特效、扭曲、霧化、底片效果、油畫特效. . .等，然后跳轉到上傳制作頁面，點擊”瀏覽”上傳圖片，然后在”Select Size”選項處選擇制作GIF 圖片的大小，默認是300像素，最后點擊”Generate Animation”開始制作。制作完成后，就可以右鍵–另存為–保存圖片了，也可以通過網站給的分享地址和他人一起分享。支持反向制作GIF動畫圖片，曾用名叫Loogix，后來Freegifmaker.me，很好玩，可以試試。
推薦度：★★★★★
查找你注冊過的站點的網站：REG007
你用你的手機號和郵箱注冊過哪些網站？是不是有些已經忘卻了？沒關系，這樣的一個網站幫你找到他們測試了一下發現還是很有用的，除了可以找回你曾經注冊過的站點，還可以當做一個社會工程學工具。REG007是一個你注冊過哪些網站，輸入郵箱或手機號，一搜便知的網站工具。可以在線快速查詢你在那些網站進行注冊過，無需注冊任何信息就可以使用。這款在線應用可以幫助你重新記憶起你在那些網站注冊，這個對于健忘的人來說非常方便，同樣你也可以用來查詢誰誰在哪個網站注冊過。其實，用這個可以做很多事，也很有許多需要注意的，比如，你要換電話號了，那么就要第一時間把注冊過的網站的手機號都換掉，提前。
推薦度：★★★★★
在線字體轉換網站工具：Font2Web
假如你只有一種otf格式的字體，網站中引入的話，會有很大兼容問題，微軟ie和mac好像都有問題，解決這個問題的辦法可以實施字體轉換，把otf轉化為你想要的字體。因為在做東西的時候發現我只備了ttf字體，但是在考慮兼容的情況下，只有這一個字體是不夠的，所以百度發現了Font2Web這個工具，操作非常簡單。Font2Web是一款在線轉換字體服務的網站，可以快速將ttf字體在線轉換成.ttf, .otf, .eot, .woff , .svg等網頁設計CSS專用字體，上傳ttf文件點擊按鈕就可以實現在線轉換，成功后會自動下載一個壓縮包，里面就有eot,otf,svg,wotf各種字體，又一款非常不錯的字體轉換在線應用，前端程序員、網頁設計人員收藏必備吧。
推薦度：★★★★★
1000家網站：這是一個從0到1的歷程，是一個自媒體肩負起互聯網普及的歷程，是一段為了理想重新上路、累并快樂著的歷程。嗯，1000家網站，互聯網發展這么多年，很多人經常使用的還是那些常用的網站（資訊、影視、社交、搜索....），有許多（優秀的、好玩的、特色的、有趣的、實用的.....國內外網站）未被發掘過，也沒有人去真正了解過，為此，我們推出了這個系列計劃，先讓這1000家網站走近大眾化，我們的理念是：讓人人都能了解，人人都會利用互聯網學習、工作、提升效率，增長見識。如果你也喜歡，請關注我們的動態。
多數設備的刷新頻率是60Hz，也就說是瀏覽器對每一幀畫面的渲染工作要在16ms內完成,超出這個時間，頁面的渲染就會出現卡頓現象，影響用戶體驗。前端的用戶體驗給了前端直觀的印象，因此對B/S架構的開發人員來說，熟悉瀏覽器的內部執行原理顯得尤為重要。
瀏覽器大體上由以下幾個組件組成，各個瀏覽器可能有一點不同。
注意：chrome瀏覽器與其他瀏覽器不同，chrome使用多個渲染引擎實例，每個Tab頁一個，即每個Tab都是一個獨立進程。
Chrome瀏覽器使用多個進程來隔離不同的網頁，在Chrome中打開一個網頁相當于起了一個進程，每個tab網頁都有由其獨立的渲染引擎實例。因為如果非多進程的話，如果瀏覽器中的一個tab網頁崩潰，將會導致其他被打開的網頁應用。另外相對于線程，進程之間是不共享資源和地址空間的，所以不會存在太多的安全問題，而由于多個線程共享著相同的地址空間和資源，所以會存在線程之間有可能會惡意修改或者獲取非授權數據等復雜的安全問題。
在內核控制下各線程相互配合以保持同步，一個瀏覽器通常由以下常駐線程組成：
GUI渲染線程負責渲染瀏覽器界面HTML元素,當界面需要重繪(Repaint)或由于某種操作引發回流(reflow)時，該線程就會執行。在Javascript引擎運行腳本期間,GUI渲染線程都是處于掛起狀態的，也就是說被凍結了.
JS為處理頁面中用戶的交互，以及操作DOM樹、CSS樣式樹來給用戶呈現一份動態而豐富的交互體驗和服務器邏輯的交互處理。如果JS是多線程的方式來操作這些UI DOM，則可能出現UI操作的沖突；如果JS是多線程的話，在多線程的交互下，處于UI中的DOM節點就可能成為一個臨界資源，假設存在兩個線程同時操作一個DOM，一個負責修改一個負責刪除，那么這個時候就需要瀏覽器來裁決如何生效哪個線程的執行結果，當然我們可以通過鎖來解決上面的問題。但為了避免因為引入了鎖而帶來更大的復雜性，JS在最初就選擇了單線程執行。
GUI渲染線程與JS引擎線程互斥的，是由于JavaScript是可操縱DOM的，如果在修改這些元素屬性同時渲染界面（即JavaScript線程和UI線程同時運行），那么渲染線程前后獲得的元素數據就可能不一致。當JavaScript引擎執行時GUI線程會被掛起，GUI更新會被保存在一個隊列中等到引擎線程空閑時立即被執行。由于GUI渲染線程與JS執行線程是互斥的關系，當瀏覽器在執行JS程序的時候，GUI渲染線程會被保存在一個隊列中，直到JS程序執行完成，才會接著執行。因此如果JS執行的時間過長，這樣就會造成頁面的渲染不連貫，導致頁面渲染加載阻塞的感覺。
瀏覽器定時計數器并不是由JS引擎計數的, 因為JS引擎是單線程的, 如果處于阻塞線程狀態就會影響記計時的準確, 因此通過單獨線程來計時并觸發定時是更為合理的方案。
當一個事件被觸發時該線程會把事件添加到待處理隊列的隊尾，等待JS引擎的處理。這些事件可以是當前執行的代碼塊如定時任務、也可來自瀏覽器內核的其他線程如鼠標點擊、AJAX異步請求等，但由于JS的單線程關系所有這些事件都得排隊等待JS引擎處理。
在XMLHttpRequest在連接后是通過瀏覽器新開一個線程請求，將檢測到狀態變更時，如果設置有回調函數，異步線程就產生狀態變更事件放到JS引擎的處理隊列中等待處理。
用戶請求的HTML文本(text/html)通過瀏覽器的網絡層到達渲染引擎后，渲染工作開始。每次通常渲染不會超過8K的數據塊，其中基礎的渲染流程圖：
webkit引擎渲染的詳細流程，其他引擎渲染流程稍有不同：
渲染流程有四個主要步驟：
以上步驟是一個漸進的過程，為了提高用戶體驗，渲染引擎試圖盡可能快的把結果顯示給最終用戶。它不會等到所有HTML都被解析完才創建并布局渲染樹。它會在從網絡層獲取文檔內容的同時把已經接收到的局部內容先展示出來。
DOM樹的構建過程是一個深度遍歷過程：當前節點的所有子節點都構建好后才會去構建當前節點的下一個兄弟節點。DOM樹的根節點就是document對象。
DOM樹的生成過程中可能會被CSS和JS的加載執行阻塞，具體可以參見下一章。當HTML文檔解析過程完畢后，瀏覽器繼續進行標記為deferred模式的腳本加載，然后就是整個解析過程的實際結束觸發DOMContentLoaded事件，并在async文檔文檔執行完之后觸發load事件。
生成DOM樹的同時會生成樣式結構體CSSOM（CSS Object Model）Tree，再根據CSSOM和DOM樹構造渲染樹Render Tree，渲染樹包含帶有顏色，尺寸等顯示屬性的矩形，這些矩形的順序與顯示順序基本一致。從MVC的角度來說，可以將Render樹看成是V，DOM樹與CSSOM樹看成是M，C則是具體的調度者，比HTMLDocumentParser等。
可以這么說，沒有DOM樹就沒有Render樹，但是它們之間不是簡單的一對一的關系。Render樹是用于顯示，那不可見的元素當然不會在這棵樹中出現了，譬如 <head>。除此之外，display等于none的也不會被顯示在這棵樹里頭，但是visibility等于hidden的元素是會顯示在這棵樹里頭的。
DOM對象類型很豐富，什么head、title、div，而Render樹相對來說就比較單一了，畢竟它的職責就是為了以后的顯示渲染用嘛。Render樹的每一個節點我們叫它渲染器renderer。
一棵Render樹大概是醬紫，左邊是DOM樹，右邊是Render樹：
從上圖我們可以看出，renderer與DOM元素是相對應的，但并不是一一對應，有些DOM元素沒有對應的renderer，而有些DOM元素卻對應了好幾個renderer，對應多個renderer的情況是普遍存在的，就是為了解決一個renderer描述不清楚如何顯示出來的問題，譬如有下拉列表的select元素，我們就需要三個renderer：一個用于顯示區域，一個用于下拉列表框，還有一個用于按鈕。
另外，renderer與DOM元素的位置也可能是不一樣的。那些添加了 float或者 position:absolute的元素，因為它們脫離了正常的文檔流，構造Render樹的時候會針對它們實際的位置進行構造。
上面確定了renderer的樣式規則后，然后就是重要的顯示元素布局了。當renderer構造出來并添加到Render樹上之后，它并沒有位置跟大小信息，為它確定這些信息的過程，接下來是布局(layout)。
瀏覽器進行頁面布局基本過程是以瀏覽器可見區域為畫布，左上角為 (0,0)基礎坐標，從左到右，從上到下從DOM的根節點開始畫，首先確定顯示元素的大小跟位置，此過程是通過瀏覽器計算出來的，用戶CSS中定義的量未必就是瀏覽器實際采用的量。如果顯示元素有子元素得先去確定子元素的顯示信息。
布局階段輸出的結果稱為box盒模型（width,height,margin,padding,border,left,top,…），盒模型精確表示了每一個元素的位置和大小，并且所有相對度量單位此時都轉化為了絕對單位。
在繪制(painting)階段，渲染引擎會遍歷Render樹，并調用renderer的 paint() 方法，將renderer的內容顯示在屏幕上。繪制工作是使用UI后端組件完成的。
回流(reflow)：當瀏覽器發現某個部分發生了點變化影響了布局，需要倒回去重新渲染。reflow 會從 <html>這個 root frame 開始遞歸往下，依次計算所有的結點幾何尺寸和位置。reflow 幾乎是無法避免的。現在界面上流行的一些效果，比如樹狀目錄的折疊、展開（實質上是元素的顯示與隱藏）等，都將引起瀏覽器的 reflow。鼠標滑過、點擊……只要這些行為引起了頁面上某些元素的占位面積、定位方式、邊距等屬性的變化，都會引起它內部、周圍甚至整個頁面的重新渲染。通常我們都無法預估瀏覽器到底會 reflow 哪一部分的代碼，它們都彼此相互影響著。
重繪(repaint)：改變某個元素的背景色、文字顏色、邊框顏色等等不影響它周圍或內部布局的屬性時，屏幕的一部分要重畫，但是元素的幾何尺寸沒有變。
每次Reflow，Repaint后瀏覽器還需要合并渲染層并輸出到屏幕上。所有的這些都會是動畫卡頓的原因。Reflow 的成本比 Repaint 的成本高得多的多。一個結點的 Reflow 很有可能導致子結點，甚至父點以及同級結點的 Reflow 。在一些高性能的電腦上也許還沒什么，但是如果 Reflow 發生在手機上，那么這個過程是延慢加載和耗電的。可以在csstrigger上查找某個css屬性會觸發什么事件。
reflow與repaint的時機：
在瀏覽器拿到HTML、CSS、JS等外部資源到渲染出頁面的過程，有一個重要的概念關鍵渲染路徑（Critical Rendering Path）。例如為了保障首屏內容的最快速顯示，通常會提到一個漸進式頁面渲染，但是為了漸進式頁面渲染，就需要做資源的拆分，那么以什么粒度拆分、要不要拆分，不同頁面、不同場景策略不同。具體方案的確定既要考慮體驗問題，也要考慮工程問題。了解原理可以讓我們更好的優化關鍵渲染路徑，從而獲得更好的用戶體驗。
現代瀏覽器總是并行加載資源，例如，當 HTML 解析器（HTML Parser）被腳本阻塞時，解析器雖然會停止構建 DOM，但仍會識別該腳本后面的資源，并進行預加載。
同時，由于下面兩點：
存在阻塞的 CSS 資源時，瀏覽器會延遲 JavaScript 的執行和 DOM 構建。另外：
所以，script 標簽的位置很重要。實際使用時，可以遵循下面兩個原則：
下面來看看 CSS 與 JavaScript 是具體如何阻塞資源的。
<style>
p { color: red; }
</style>
<link rel="stylesheet" href="index.css">這樣的 link 標簽（無論是否 inline）會被視為阻塞渲染的資源，瀏覽器會優先處理這些 CSS 資源，直至 CSSOM 構建完畢。
渲染樹（Render-Tree）的關鍵渲染路徑中，要求同時具有 DOM 和 CSSOM，之后才會構建渲染樹。即，HTML 和 CSS 都是阻塞渲染的資源。HTML 顯然是必需的，因為包括我們希望顯示的文本在內的內容，都在 DOM 中存放，那么可以從 CSS 上想辦法。
最容易想到的當然是精簡 CSS 并盡快提供它。除此之外，還可以用媒體類型（media type）和媒體查詢（media query）來解除對渲染的阻塞。
<link href="index.css" rel="stylesheet">
<link href="print.css" rel="stylesheet" media="print">
<link href="other.css" rel="stylesheet" media="(min-width: 30em) and (orientation: landscape)">第一個資源會加載并阻塞。第二個資源設置了媒體類型，會加載但不會阻塞，print 聲明只在打印網頁時使用。第三個資源提供了媒體查詢，會在符合條件時阻塞渲染。
關于CSS加載的阻塞情況：
沒有js的理想情況下，html與css會并行解析，分別生成DOM與CSSOM，然后合并成Render Tree，進入Rendering Pipeline；但如果有js，css加載會阻塞后面js語句的執行，而（同步）js腳本執行會阻塞其后的DOM解析（所以通常會把css放在頭部，js放在body尾）
JavaScript 的情況比 CSS 要更復雜一些。如果沒有 defer 或 async，瀏覽器會立即加載并執行指定的腳本，“立即”指的是在渲染該 script 標簽之下的HTML元素之前，也就是說不等待后續載入的HTML元素，讀到就加載并執行。觀察下面的代碼：
<p>Do not go gentle into that good night,</p>
<script>console.log("inline1")</script>
<p>Old age should burn and rave at close of day;</p>
<script src="app.js"></script>
<p>Rage, rage against the dying of the light.</p>
<script src="app.js"></script>
<p>Old age should burn and rave at close of day;</p>
<script>console.log("inline2")</script>
<p>Rage, rage against the dying of the light.</p>這里的 script 標簽會阻塞 HTML 解析，無論是不是 inline-script。上面的 P 標簽會從上到下解析，這個過程會被兩段 JavaScript 分別打斷一次（加載、執行）。
解析過程中無論遇到的JavaScript是內聯還是外鏈，只要瀏覽器遇到 script 標記，喚醒 JavaScript解析器，就會進行暫停 (blocked )瀏覽器解析HTML，并等到 CSSOM 構建完畢，才去執行js腳本。因為腳本中可能會操作DOM元素，而如果在加載執行腳本的時候DOM元素并沒有被解析，腳本就會因為DOM元素沒有生成取不到響應元素，所以實際工程中，我們常常將資源放到文檔底部。
defer 與 async 可以改變之前的那些阻塞情形，這兩個屬性都會使 script 異步加載，然而執行的時機是不一樣的。注意 async 與 defer 屬性對于 inline-script 都是無效的，所以下面這個示例中三個 script 標簽的代碼會從上到下依次執行。
<script async>
console.log("1")
</script>
<script defer>
console.log("2")
</script>
<script>
console.log("3")
</script>上面腳本會按需輸出 1 2 3，故，下面兩節討論的內容都是針對設置了 src 屬性的 script 標簽。
先放個熟悉的圖~
藍色線代表網絡讀取，紅色線代表執行時間，這倆都是針對腳本的；綠色線代表 HTML 解析。
<script src="app1.js" defer></script>
<script src="app2.js" defer></script>
<script src="app3.js" defer></script>defer 屬性表示延遲執行引入 JavaScript，即 JavaScript 加載時 HTML 并未停止解析，這兩個過程是并行的。整個 document 解析完畢且 defer-script 也加載完成之后（這兩件事情的順序無關），會執行所有由 defer-script 加載的 JavaScript 代碼，再觸發 DOMContentLoaded(初始的 HTML 文檔被完全加載和解析完成之后觸發，無需等待樣式表圖像和子框架的完成加載) 事件 。
defer 不會改變 script 中代碼的執行順序，示例代碼會按照 1、2、3 的順序執行。所以，defer 與相比普通 script，有兩點區別：載入 JavaScript 文件時不阻塞 HTML 的解析，執行階段被放到 HTML 標簽解析完成之后。
async 屬性表示異步執行引入的 JavaScript，與 defer 的區別在于，如果已經加載好，就會開始執行，無論此刻是 HTML 解析階段還是 DOMContentLoaded 觸發(HTML解析完成事件)之后。需要注意的是，這種方式加載的 JavaScript 依然會阻塞 load 事件。換句話說，async-script 可能在 DOMContentLoaded 觸發之前或之后執行，但一定在 load 觸發之前執行。
從上一段也能推出，多個 async-script 的執行順序是不確定的，誰先加載完誰執行。值得注意的是，向 document 動態添加 script 標簽時，async 屬性默認是 true。
使用 document.createElement 創建的 script 默認是異步的，示例如下。
console.log(document.createElement("script").async); // true所以，通過動態添加 script 標簽引入 JavaScript 文件默認是不會阻塞頁面的。如果想同步執行，需要將 async 屬性人為設置為 false。
如果使用 document.createElement 創建 link 標簽會怎樣呢？
const style=document.createElement("link");
style.rel="stylesheet";
style.href="index.css";
document.head.appendChild(style); // 阻塞？其實這只能通過試驗確定，已知的是，Chrome 中已經不會阻塞渲染，Firefox、IE 在以前是阻塞的，現在會怎樣目前不太清楚。
結合渲染流程，可以針對性的優化渲染性能：
這里主要參考Google的瀏覽器渲染性能的基礎講座，想看更詳細內容可以去瞅瞅~
setTimeout(callback)和setInterval(callback)無法保證callback函數的執行時機，很可能在幀結束的時候執行，從而導致丟幀，如下圖：
requestAnimationFrame(callback)可以保證callback函數在每幀動畫開始的時候執行。注意：jQuery3.0.0以前版本的animate函數就是用setTimeout來實現動畫，可以通過jquery-requestAnimationFrame這個補丁來用requestAnimationFrame替代setTimeout
JS代碼運行在瀏覽器的主線程上，與此同時，瀏覽器的主線程還負責樣式計算、布局、繪制的工作，如果JavaScript代碼運行時間過長，就會阻塞其他渲染工作，很可能會導致丟幀。前面提到每幀的渲染應該在16ms內完成，但在動畫過程中，由于已經被占用了不少時間，所以JavaScript代碼運行耗時應該控制在3-4毫秒。如果真的有特別耗時且不操作DOM元素的純計算工作，可以考慮放到Web Workers中執行。
var dataSortWorker=new Worker("sort-worker.js");
dataSortWorker.postMesssage(dataToSort);
// 主線程不受Web Workers線程干擾
dataSortWorker.addEventListener('message', function(evt) {
var sortedData=e.data;
// Web Workers線程執行結束 // ...});由于Web Workers不能操作DOM元素的限制，所以只能做一些純計算的工作，對于很多需要操作DOM元素的邏輯，可以考慮分步處理，把任務分為若干個小任務，每個任務都放到 requestAnimationFrame中回調執行
var taskList=breakBigTaskIntoMicroTasks(monsterTaskList);
requestAnimationFrame(processTaskList);
function processTaskList(taskStartTime) {
var nextTask=taskList.pop();
// 執行小任務
processTask(nextTask);
if (taskList.length > 0) {
requestAnimationFrame(processTaskList);
}
}打開 ChromeDevTools>Timeline>JSProfile，錄制一次動作，然后分析得到的細節信息，從而發現問題并修復問題。
添加或移除一個DOM元素、修改元素屬性和樣式類、應用動畫效果等操作，都會引起DOM結構的改變，從而導致瀏覽器要repaint或者reflow。那么這里可以采取一些措施。
盡量保持class的簡短，或者使用Web Components框架。
.box:nth-last-child(-n+1) .title {}
// 改善后
.final-box-title {}由于瀏覽器的優化，現代瀏覽器的樣式計算直接對目標元素執行，而不是對整個頁面執行，所以我們應該盡可能減少需要執行樣式計算的元素的個數。
布局就是計算DOM元素的大小和位置的過程，如果你的頁面中包含很多元素，那么計算這些元素的位置將耗費很長時間。布局的主要消耗在于：1. 需要布局的DOM元素的數量；2. 布局過程的復雜程度
當你修改了元素的屬性之后，瀏覽器將會檢查為了使這個修改生效是否需要重新計算布局以及更新渲染樹，對于DOM元素的幾何屬性修改，比如width/height/left/top等，都需要重新計算布局。對于不能避免的布局，可以使用Chrome DevTools工具的Timeline查看布局的耗時，以及受影響的DOM元素數量。
老的布局模型以相對/絕對/浮動的方式將元素定位到屏幕上，而Floxbox布局模型用流式布局的方式將元素定位到屏幕上。通過一個小實驗可以看出兩種布局模型的性能差距，同樣對1300個元素布局，浮動布局耗時14.3ms，Flexbox布局耗時3.5ms。IE10+支持。
根據渲染流程，JS腳本是在layout之前執行，但是我們可以強制瀏覽器在執行JS腳本之前先執行布局過程，這就是所謂的強制同步布局。
requestAnimationFrame(logBoxHeight);
// 先寫后讀，觸發強制布局
function logBoxHeight() {
// 更新box樣式
box.classList.add('super-big');
// 為了返回box的offersetHeight值
// 瀏覽器必須先應用屬性修改，接著執行布局過程
console.log(box.offsetHeight);
}
// 先讀后寫，避免強制布局
function logBoxHeight() {
// 獲取box.offsetHeight
console.log(box.offsetHeight);
// 更新box樣式
box.classList.add('super-big');
}在JS腳本運行的時候，它能獲取到的元素樣式屬性值都是上一幀畫面的，都是舊的值。因此，如果你在當前幀獲取屬性之前又對元素節點有改動，那就會導致瀏覽器必須先應用屬性修改，結果執行布局過程，最后再執行JS邏輯。
如果連續快速的多次觸發強制同步布局，那么結果更糟糕。比如下面的例子，獲取box的屬性，設置到paragraphs上，由于每次設置paragraphs都會觸發樣式計算和布局過程，而下一次獲取box的屬性必須等到上一步設置結束之后才能觸發。
function resizeWidth() { // 會讓瀏覽器陷入'讀寫讀寫'循環 for (var i=0; i < paragraphs.length; i++) { paragraphs[i].style.width=box.offsetWidth + 'px'; }}
// 改善后方案var width=box.offsetWidth;function resizeWidth() { for (var i=0; i < paragraphs.length; i++) { paragraphs[i].style.width=width + 'px'; }}注意：可以使用FastDOM來確保讀寫操作的安全，從而幫你自動完成讀寫操作的批處理，還能避免意外地觸發強制同步布局或快速連續布局，消除大量操作DOM的時候的布局抖動。
Paint就是填充像素的過程，通常這個過程是整個渲染流程中耗時最長的一環，因此也是最需要避免發生的一環。如果Layout被觸發，那么接下來元素的Paint一定會被觸發。當然純粹改變元素的非幾何屬性，也可能會觸發Paint，比如背景、文字顏色、陰影效果等。
繪制并非總是在內存中的單層畫面里完成的，實際上，瀏覽器在必要時會將一幀畫面繪制成多層畫面，然后將這若干層畫面合并成一張圖片顯示到屏幕上。這種繪制方式的好處是，使用transform來實現移動效果的元素將會被正常繪制，同時不會觸發其他元素的繪制。
瀏覽器會把相鄰區域的渲染任務合并在一起進行，所以需要對動畫效果進行精密設計，以保證各自的繪制區域不會有太多重疊。另外可以實現同樣效果的不同方式，應該采用性能更好的那種。
打開DevTools，在彈出的面板中，選中 MoreTools>Rendering選項卡下的Paint flashing，這樣每當頁面發生繪制的時候，屏幕就會閃現綠色的方框。通過該工具可以檢查Paint發生的區域和時機是不是可以被優化。通過Chrome DevTools中的 Timeline>Paint選項可以查看更細節的Paint信息
使用transform/opacity實現動畫效果，會跳過渲染流程的布局和繪制環節，只做渲染層的合并。
TypeFuncPositiontransform: translate(-px,-px)Scaletransform: scale(-)Rotationtransform: rotate(-deg)Skewtransform: skew(X/Y)(-deg)Matrixtransform: matrix(3d)(..)Opacityopacity: 0-1
使用transform/opacity的元素必須獨占一個渲染層，所以必須提升該元素到單獨的渲染層。
應用動畫效果的元素應該被提升到其自有的渲染層，但不要濫用。在頁面中創建一個新的渲染層最好的方式就是使用CSS屬性will-change，對于目前還不支持will-change屬性、但支持創建渲染層的瀏覽器，可以通過3D transform屬性來強制瀏覽器創建一個新的渲染層。需要注意的是，不要創建過多的渲染層，這意味著新的內存分配和更復雜的層管理。注意，IE11，Edge17都不支持這一屬性。
.moving-element { will-change: transform; transform: translateZ(0);}盡管提升渲染層看起來很誘人，但不能濫用，因為更多的渲染層意味著更多的額外的內存和管理資源，所以當且僅當需要的時候才為元素創建渲染層。
* { will-change: transform; transform: translateZ(0);}開啟 Timeline>Paint選項，然后錄制一段時間的操作，選擇單獨的幀，看到每個幀的渲染細節，在ESC彈出框有個Layers選項，可以看到渲染層的細節，有多少渲染層，為何被創建？
用戶輸入事件處理函數會在運行時阻塞幀的渲染，并且會導致額外的布局發生。
理想情況下，當用戶和頁面交互，頁面的渲染層合并線程將接收到這個事件并移動元素。這個響應過程是不需要主線程參與，不會導致JavaScript、布局和繪制過程發生。但是如果被觸摸的元素綁定了輸入事件處理函數，比如touchstart/touchmove/touchend，那么渲染層合并線程必須等待這些被綁定的處理函數執行完畢才能執行，也就是用戶的滾動頁面操作被阻塞了，表現出的行為就是滾動出現延遲或者卡頓。
簡而言之就是你必須確保用戶輸入事件綁定的任何處理函數都能夠快速的執行完畢，以便騰出時間來讓渲染層合并線程完成他的工作。
輸入事件處理函數，比如scroll/touch事件的處理，都會在requestAnimationFrame之前被調用執行。因此，如果你在上述輸入事件的處理函數中做了修改樣式屬性的操作，那么這些操作就會被瀏覽器暫存起來，然后在調用requestAnimationFrame的時候，如果你在一開始就做了讀取樣式屬性的操作，那么將會觸發瀏覽器的強制同步布局操作。
通過requestAnimationFrame可以對樣式修改操作去抖動，同時也可以使你的事件處理函數變得更輕
為一個產品經理，學習并掌握基礎的技術知識是非常重要的。而本篇文章就重點討論前端部分，講一講HTML和CSS、JavaScript的知識要點。
為什么學習技術？我想上面這段話給予了非常好的解釋。
在當今時代，職能劃分越來越精細，但你仍然可以看到不同行業、領域、職業都密不可分，他們互相融合和滲透。設計和技術亦是如此，產品經理和程序員亦是如此。
不難發現，成功的產品經理有一個共性，那就是在精通設計與用戶體驗的基礎上，精通技術或者如何運用技術。前者如張小龍，后者如喬布斯。
這并非偶然，而是因為技術和設計原本就是一體的：設計使用當下的技術來解決問題，因此設計中就包含了對技術的考量與使用。
你可能會說，作為一個執行層的產品，并不需要了解這些宏觀的問題。你可能還會說，在技術如此成熟的當下，產品可以盡情發揮想象或者直接套用現有設計模式。
可是事實表明，在微觀層面設計和技術達成共識可以顯著提升合作質量和效率，這也正是各個平臺（不管是安卓、iOS，還是小程序、網站）推出設計/開發規范的原因；另一方面，只有深諳設計模式及其背后的技術基礎，才能打破模式、迸發創意。
在學習技術的同時，我剛好在看交互設計精髓這本書。書中提到了設計可以分為對內容、形態、行為的設計。我驚喜地發現這些設計領域剛好可以對應一些技術語言或實現方案，例如HTML、CSS、JS，又例如MVC（一種開發模式，下篇文章會提及）。
所以對產品經理而言，學習技術可以幫助你更好地理解產品設計，更好地執行產品工作，更加順暢地與開發人員合作。
最初我學習技術的動機來自于想寫一份好的PRD（我的一篇專欄文章講述了這個主題，詳見文章底部的參考資料），為此，我需要知道前端、后端分別想從需求文檔中獲取哪些信息以及他們會如何利用這些信息進行開發。
由此出發，我看了三本書，分別介紹了HTML和CSS、JavaScript、Python這些編程語言在前端開發、后端開發中的應用。
在這里，簡單總結一下這些書中提及的技術原理，并結合自己的思考和實踐指出這些技術原理在產品工作中的應用，希望可以對自己以及他人有所幫助。
由于內容較多，這篇文章將重點討論前端部分，涉及HTML和CSS、JavaScript的內容；關于后端的內容，將在下一篇文章中分享。
下面將分別介紹一下HTML、CSS、JavaScript在web前端開發中的應用。
HTML翻譯作“超文本標記語言”，和現在廣為使用的markdown一樣，作為一種標記語言，HTML通過一套既定的語法來標記文本或者富文本內容，從而為這些內容劃定結構。
這些HTML格式的文件通常存儲在服務器上，瀏覽器通過互聯網向服務器請求這些頁面資源，然后解析并呈現出用戶直接看到的頁面。
在瀏覽器中打開任意web頁面，并檢查其HTML元素，都可以看到其大體的結構：
<head>元素存放網頁的基本信息，<body>元素里的內容就是用戶將在瀏覽器看到的東西，此外還有許許多多的元素（如：<h>、<p>、<a>、<img>、<div>、<li>、<div>）嵌套起來，共同構建了網頁的結構。
這些元素一般由開始標記、結束標記、內容、屬性等部分構成，其中“屬性”可以幫助對這些元素進行更加具體的描述。
舉例說明：標題元素的寫法如下，<h1></h1>為開始和結束標記，中間包圍的即為標題元素的內容。
<h1>這里是標題</h1>
表單元素的常見寫法如下，其中<form>為開始標記，有action 和method兩個屬性，</form>為結束標記，省略號的位置放置表單元素包圍的所有內容和輸入控件。
<form action="http://123.com/test.py" method="POST"> ... </form>
在同一網站內部，可以通過在<a>元素中使用相對資源路徑鏈接到一個新的頁面。
在網站之外，則可以使用URL（統一資源定位符，用文件地址來標識web上的任何資源），通過絕對路徑直接向服務器請求頁面資源。
URL的結構通常如下：通信協議（http、https、file等）、服務器名（常見的www）、域名（服務器IP地址的簡便記法）、資源的絕對路徑、隨URL傳遞的參數。
我們設計出一個頁面，頁面上每一個元素（包括控件、信息、圖片）都由HTML元素（例如<input>、<p>、<img>）來定義或者說實現。
這些頁面控件、信息、圖片的屬性同樣可以由HTML元素屬性來實現，例如通過設置placeholder屬性值，可以為輸入框加入提示文案，通過設置draggable屬性，讓元素可以拖動。
在頁面結構層面了解設計與技術的關聯，可以幫助從技術的角度撰寫產品方案。
（1）一方面，知道了技術會把頁面結構拆解為元素及其屬性，我們在寫文檔時，也應當以這種思路拆解并描述頁面，寫清楚頁面有哪些信息，哪些輸入控件，哪些顯示控件，這些控件的屬性是否需要自定義，還是直接使用瀏覽器或操作系統的默認樣式。
（2）另一方面，從技術角度了解元素及其基本屬性，就可以減少產品方案中對細節描述的遺漏。
CSS翻譯作“層疊樣式表”，和HTML一樣，CSS也是我們用來創建網頁的語言，HTML定義頁面的內容和結構，而CSS定義了web頁面的樣式和表現。
具體來說，通過在HTML的<link>或<style>中鏈接到CSS樣式表，CSS就可以通過其眾多的樣式屬性，控制HTML中元素的外觀表現。
CSS的樣式屬性，例如color、border、font-style等，可以控制HTML元素的字體顏色、邊框、字體樣式等等。此外，CSS將每個HTML元素看作一個盒子（這也就是“盒模型”），以控制其內外邊距、邊框等。
還可以使用CSS靈活的對頁面進行布局：
（1）流體布局，擴展瀏覽器窗口時，頁面中的內容會根據一定規則自動擴展以適應頁面
（2）凍結布局，通過設定頁面寬度，所有頁面元素都將固定在頁面上，不隨瀏覽器窗口大小而改變布局
（3）凝膠布局，鎖定頁面內容區域的寬度，但外邊距會根據窗口大小進行擴展收縮，從而使得頁面在瀏覽器中居中
（4）絕對定位，使得元素相對于頁面固定
（5）固定定位，使元素相對于瀏覽器窗口固定不動
（6）相對定位
（7）表格顯示
（8）浮動布局
CSS可以靈活適配，可以為一個HTML頁面設置多個樣式表（或者在CSS中設置@media規則），用于不同的場景展示、匹配不同的設備或者適應不同的窗口寬度。
（1）在詳細的產品設計實現方案中，不僅要定義頁面具有哪些元素，也要定義這些元素的樣式、外觀、動效等。
在技術實現上，這是兩個不同的層面，由不同的語言來實現；因而在文檔寫作中，也應該將元素與其樣式區分開來進行描述，而不是將所有說明混雜在一起（雖然這個工作往往需要和設計進行配合）。
例如在描述按鈕時，不僅要指明按鈕元素的基本屬性（例如按鈕文本、按鈕類別），也應該指出按鈕在不同狀態的不同樣式。
（2）在宏觀層面，隨著設備形態的多樣化，樣式適配也變成了一個很大的主題，也應是產品設計中應該考慮的重要方面。
以網站設計而言，同樣的內容元素，在手機和PC上往往需要定義不同的樣式，對此有很多技術實現方案，產品經理應對樣式適配有基本認知，才能與技術共同商定適配方案。
前面提到，使用HTML標記和CSS可以幫助搭建web頁面，而JavaScript的使用，可以為這些頁面增加行為和功能（比如對用戶行為作出響應、處理事件、更新頁面、與服務端通信），從而成為真正意義上的web應用。
HTML5是HTML的最新版本，但實際上當我們談論HTML5時，不僅僅指代標記，而是HTML標記、CSS樣式、JavaScript腳本這些技術的結合，這些技術共同幫助構件web應用。
通過在代碼中引用JavaScript文件或者直接將腳本放在<script>元素中，就可以在web頁面中增加JavaScript。
瀏覽器在加載頁面時，對于HTML中每一個元素，會創建一個表示該元素的對象，把它與所有其他元素一起放在一個類似樹的結構中，這個樹即為DOM（文檔對象模型 Document Object Model），DOM是瀏覽器對于頁面結構的內部表示。
JavaScript可以通過DOM對頁面元素進行訪問、修改、增刪。例如，可以使用document.getElementById在DOM中查找元素，使用元素的innderHTML屬性修改其內容，然后瀏覽器會近乎實時的對DOM以及頁面進行更新。
瀏覽器在顯示頁面時，會有許多事件發生，例如按鈕點擊事件、數據到達事件、時間到期事件等，使用JavaScript編寫事件處理程序，可以對這些事件進行處理。
以表單的按鈕點擊事件為例進行說明：用戶在輸入框輸入信息，點擊按鈕提交信息后，可以在當前頁查看已經提交的信息。
實現思路如下：首先通過DOM獲取按鈕元素，并為按鈕的onclick屬性設置一個處理程序。
該處理程序需要通過DOM訪問輸入元素，并通過輸入元素的value屬性獲取用戶輸入值，最后再通過DOM增加到頁面中。這樣在用戶點擊按鈕時，就會執行該處理程序，獲取用戶輸入并增加到頁面中，以此實現用戶與系統的交互。
通過使用JavaScript API（API即應用編程接口，提供一組對象、方法和屬性，可以用來訪問這些技術的所有功能；對象可以理解為是屬性的集合）可以為頁面增加更多新的功能，如視頻播放、本地存儲、地理定位等。
以地理定位為例，通過調用地理定位API，使用其getCurrentPosition方法可以獲取當前位置信息（瀏覽器可以通過IP定位、GPS定位等方式獲取位置信息）并進行處理和顯示；使用watchPosition方法可以對位置更新進行實時監控和報告；使用clearWatch以停止監視位置。
（1）Ajax（XMLHttpRequest）
前端（比如瀏覽器）向服務器請求頁面或者數據資源，服務端接受請求并執行服務端程序，捕獲程序的輸出作為響應發回前端，前端監測到數據到達后，再執行處理程序對這些數據進行處理，最終更新DOM和頁面。
這種獲取數據的模式稱為Ajax，在應用中可以使用這種方式更新內容，而無需重新加載頁面。
那么如何使用JavaScript發送請求？
首先創建一個請求對象，指明請求方法和資源地址，同時提供一個處理程序，然后發出請求，等待數據到達。數據到達時，就會調用這個處理程序，在請求對象的responseText屬性中獲取傳回的數據并進行處理。
瀏覽器主要使用兩種方法發送請求：GET和POST
使用POST和GET方法都可以向服務端發送請求，不過采用了不同的方式。POST會打包要傳遞到服務端的數據，并在后臺把他們發送到服務器；GET也會打包數據，但會把這些數據追加到URL的最后，然后向服務器發送請求。
如果要傳遞的數據應當是私有的，或者數據很多，就應當使用POST；如果返回的頁面要支持添加書簽，就需要使用GET方法。
（2）JSONP
除了提供HTML和JavaScript的服務器外，瀏覽器不允許從其他不同的服務器獲取數據，這是瀏覽器的安全策略。如果頁面和要請求的數據同在一個服務器上，可以使用Ajax請求數據，如果頁面和要請求的數據不在同一服務器上，則可以使用JSONP請求數據。
JSONP是一種使用<script>標記獲取數據的方法，通過在請求URL后指定回調函數，將返回的數據包裝在一個函數調用中進行處理。
例如，我們的網站從微博獲取用戶最近動態，就是一個跨域（服務器）請求數據的應用。
（3）Web Socket
Ajax和JSONP都使用了一個基于HTTP的請求/響應模型。也就是說，每次需要從服務端獲取資源時，都要使用瀏覽器作出請求得到相關頁面和數據。
對于一些數據更新比較頻繁的應用，瀏覽器需要不斷的發送請求詢問服務端是否有新數據，在這種應用場景下，Web Socket或許是一個更佳的通信方案。
Web Socket是一個新增的API，允許與一個服務器的連接保持打開，這樣在有新數據時，服務器就會主動把數據發給前端，就像瀏覽器與服務器之間的一個接通的電話線。
Web Socket提供了實時交互通信的能力，允許服務器主動發送信息給客戶端，是一種區別于HTTP的全新雙向數據流協議。
上面提及頁面從服務器獲取數據，除此之外，還可以使用本地存儲獲取數據，從而減少與服務端的通信，打造更好的用戶體驗與更廣泛的應用場景。
（1）瀏覽器cookie
服務器隨響應發送一個cookie給瀏覽器，cookie中以鍵值對形式存儲一些信息。瀏覽器在本地存儲cookie，下次發出請求時會將cookie發回服務器。cookie是按域存儲的，而且只能發送給這個域，因而不同域之間的cookie無法互相訪問。使用cookie可以實現個性化的體驗、維護游戲狀態、存儲用戶數據等等。
（2）web存儲/local storage（本地存儲）、session storage（會話存儲）
使用JS的 web storage API，可以在瀏覽器中更好的存儲數據。
每個瀏覽器都有一些本地存儲空間（每個域都有超過5M的空間，存儲在一個域的數據對另一個域是不可見的），使用setItem方法可以在localstorage中存儲一個鍵值對，使用getItem方法可以從本地存儲中獲取某個鍵對應的值，使用remove方法可以刪除本地存儲中某一鍵對應的數據項。
session storage與local storage非常相似，唯一的區別在于：在用戶與瀏覽器會話期間，session storage可以在本地存儲信息，一旦會話結束（即關閉瀏覽器窗口），這些信息將刪除；而local storage將永久存儲信息，除非用戶手動刪除緩存。
JavaScript是單線程的，如果要執行復雜的運算，可以會花費太多時間以至于無法及時作出頁面響應。這時可以使用web工作線程，他在一個單獨的線程處理耗時的任務，所以主代碼可以繼續運行以提高頁面的響應性。每個工作線程在他自己的線程中運行，如果你的計算機有一個多核處理器，工作線程會并行運行，這回提高運算速度。
下面簡單介紹一下web工作線程的工作方式。
在主代碼中使用構造函數創建一個或者多個工作線程對象，并指定工作線程要執行的JavaScript文件。
主代碼和工作線程代碼通過消息通信，使用postmessage發送信息，使用onmessage接收信息。
主代碼通過發送一個消息讓工作線程開始工作，即執行其JavaScript文件；工作線程完成工作后，會發回消息，并傳入其運算結果。主代碼得到這些結果，執行相應的處理程序，將結果展現在頁面中。
軟件產品的設計可以分為內容、形態、行為三個領域。前兩者是HTML和CSS的主要工作，而軟件行為的設計就是JS（JavaScript）的主要工作。
在內容層面，通過JS進行前后端通信，可以從服務端獲取最新的數據并動態的為頁面增加內容。
因而在產品設計中，我們應該考慮頁面信息的來源，是寫死在前端，還是請求服務端數據接口，是否需要搭建相應的管理后臺。通過JS進行前后端通信，還可以將用戶輸入等信息上報服務端并進行存儲，這亦是產品方案中應該考慮的地方。
在功能或行為層面，使用JS進行前后端通信，一些功能入口也可以通過服務端進行靈活的配置，例如為不同的用戶角色提供不同的功能入口或功能限制。
頁面對用戶的響應也都是通過JS來實現，例如對表單輸入進行校驗并反饋，這些邏輯判斷和運算都是通過JS完成。對此，產品經理往往需要通過流程圖、狀態圖等，進行邏輯與運算規則的說明。
上面分別提及在內容、形態、行為三個設計領域，技術在產品工作中的具體應用。在更加抽象的層面，技術的學習讓我更加了解互聯網產品的本質–信息。在團隊配合、項目流程上，技術與設計的結合同樣具有價值：
（1）幫助從技術的角度初步評估產品方案，用于評估方案的成本和性價比，排列優先級和進行版本規劃
（2）與技術團隊更高效的配合，隨著技術發展和不斷成熟，有越來越多的工具可以幫助快速開發，懂得技術的開發原理和開發手段，才可以采用更加靈活的方式與技術配合。
本文主要探討了：
下一次的分享中將會對后端，以及前后端交互的技術知識和應用進行總結，感興趣的小伙伴可以關注我或者我的專欄。
寫作本文著實花了不少時間，一方面在于其中涉及很多技術語言；但更主要的原因在于寫作過程中涉及到技術思維、設計思維的來回切換和融合，自認為本文在這一方面仍然有待提高。
學習技術給我帶來很多層面的收獲，讓我得以層層深入，庖丁解牛似的看清產品的內部構造；也讓我可以從不同角度看待技術、設計、產品在軟件產業不同階段中扮演的角色，對團隊組織構成有了新的理解。
最后以一句我的名言結尾：對于設計的追問會帶你走向技術，對于技術的追問會帶你走向設計。
《Head First HTML與CSS》
《Head First HTML5 Programming》
寫了30+產品需求文檔后，我對PRD有了新的認知
WebSocket簡介及應用實例
本文由 @lemon 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
