transform比top更適合進行居中
今天看到一個回答說transform比top更適合居中操作的原理,主要有三個部分,一是transform可以生成新的合成層,合成層上有GPU加速,二是它的使用不會引起迴流,三是top的動畫處理是是以px爲單位,但是transform的處理更加平滑,因爲它的基本單位更小。
首先對於第二點,因爲transform會生成新的渲染層,並使用一種合成渲染的方式,講渲染好的圖層平移過去,跳過了repaiting和reflow,因此它的性能確實更好。
但是對於第一點,transform在二維上的使用是不會創建新的合成層的,只有滿足一定條件的渲染層纔會被提升到新的合成層,我們可以通過devtool查看。
而使用了:
will-change: transform
可以看到這兒多了兩個合成層,這是爲什麼呢?
因爲我在代碼中的原渲染層上添加了一個新的渲染層,使用z-index,同時這個層層級 是高的,因此出現了隱式合成合成層的情況,生成了兩個合成層。
二維碼原理
用戶進入一個網頁後,服務器生成一個uid來標識用戶,而顯現出的二維碼則標識了對應uid的鏈接。當使用正確的客戶端打開這個鏈接時,服務器會收到用戶的相關信息,並在客戶端點擊確認登陸後生成一個token給對應網頁。之後的交互都依賴這個token。
寫個事件委託
function delegate(element, type, selector, fn){
element.addEventListener(type, e=>{
let target = e.target
while(!target.matches(selector)){
if(target==element){
target = null
break
}
target=target.parentNode
}
target&&fn(target)
})
}
數組去重
arr.reduce((t,v)=>t.includes(v)?t:[...t, v],[])
arr.filter((v,i)=>arr.indexOf(v)==i)
[...new Set(arr)]
Webpack生命週期
- 初始化參數,從配置文件或shell中
- 初始化Compile,加載插件,執行run方法開始編譯
- 根據entry找到入口文件
- 從入口文件出發,執行所有的loader對模塊編譯,找到該模塊依賴的模塊,再遞歸的執行,知道所有編譯結束。
- 拿到模塊翻譯後的最終內容和依賴關係
- 根據入口和模塊的依賴關係,打包成一個個chunk,把每個chunk轉換成輸出文件加入輸出列表
- 根據輸出配置輸出路徑和文件名
Webpack的XHR
- 在watch模式下,webpack監聽到文件的變化,重新打包並保存到內存中
- 通過sockjs在瀏覽器和服務端建立一個websocket長連接,將 webpack 編譯打包的各個階段的狀態信息告知瀏覽器端,最主要的是新模塊的hash值。
- 客戶端某模塊接收到新模塊的hasn值,發送AJAX請求,服務端返回一個json,上面有所有需要更新的模塊hash,根據這個更新列表發送JSONP。
- 檢查新舊模塊更新與否,更新模塊依賴等。
domain和samesite
domain設置.baidu.com,指的是cookie還是可以發送到百度及其下的子域名,而無需管請求的來源,因此domain是指子域名下能拿到該cookie。
samesite則關注請求來源。
記一次體驗很差的面試
上次遇到一次nice的面試官,這次同樣的企業,遇到了位很不尊重人的面試官,或許面試策略如此吧。
相對於CSS和JS,對HTML還是有些輕視的,在表單和meta這一塊,昨天被問到逮個正着。不過從一開始,對方總是說自己不帶偏見的去說這說那,言語中真讓人感覺不到所謂的不帶偏見。偶爾竟然還能說髒話,整個面試就已經不想進行下去了。還說移動端現在佔據業務的百分之90,這一點我是不知道,可能和您自家有關吧。還有就是說自己準備了很多移動端問題,你不瞭解touch事件我都沒法問。不過也沒辦法,人是菜了點,一臉笑臉面到最後,卻是這麼多家,只在這兒感覺得不到基本的尊重,實在是想不到的。
說一下漏掉的兩個問題,input表單的問題,問的是readonly和disable,這個確是不記得了,現在看來是一個能提交請求,一個不能。
meta,viewport和移動端相關知識的問題,移動端的知識確實是之前漏掉了,很多面經也沒有提到這塊,所有這裏來梳理一下。
首先是device pixels,我們可以理解爲一個點,有紅藍綠三個彩燈通過不同的亮度顯示最後的色彩。
接着是設備獨立像素,區別於上面的知識,設備獨立像素可能包含多個設備像素。而1個CSS像素 等於 1個設備獨立像素,設原來分辨率爲100100,元素爲5050,當我們分辨率改成200*200,元素自然顯得更小了。
2K和4K就不說了,說說PPI,5.8英寸、分辨率爲1125x2436的iphonex,ppi = Math.sqrt(11251125 + 24362436) / 5.8=463ppi。DPR則是物理像素除以設備獨立像素。
掌握了上面的基本知識,再看viewport就很好理解了,假如你使用!+Tab,html文件會自動生成:
<meta name="viewport" content="width=device-width, initial-scale=1.0">
這意味着當我們使用手機端測試時,寬度會默認爲設備的寬度,如iphone設爲375等。這樣字體就不至於縮放的很小,否則,大部分瀏覽器會以980的寬度進行渲染。
initial-scale定義了初始縮放比例,maximum-scale定義了用戶最多能放大多少倍,minimum-scale定義了最大能縮小多少倍。