移動端做適配有幾種方法,今天來聊聊amfe-flexible和postcss-plugin-px2rem。
amfe-flexible:動態改變根字體的大小(會在html上自動添加上font-size);
postcss-plugin-px2rem: 編譯時,根據字根的大小,將px轉換成rem。
1. 安裝amfe-flexible
npm install -S amfe-flexible
2. 在main.js中引入
import 'amfe-flexible/index.js'
3. 修改public/index.html
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, minimum-scale=1, user-scalable=no">
安裝好后,重新啟動,就可以看到html上設置了font-size樣式,切換不同型號的手機,可以看到font-size會隨之變化。
1. 安裝postcss-plugin-px2rem
npm install postcss-plugin-px2rem lib-flexible --save-dev
2. 在vue.config.js添加如下碼
module.exports = {
css: {
// 啟用 CSS modules
// 是否使用css分離插件
extract: true,
// 開啟 CSS source maps?
sourceMap: false,
// css預設器配置項
loaderOptions: {
css: {},
postcss: {
plugins: [
require('postcss-plugin-px2rem')({
rootValue: 100, //字體基數,設計稿為750的基數
exclude: /(node_module)/, // 默認false,可以(reg)利用正則表達式排除某些文件夾的方法,例如/(node_module)/ 。如果想把前端UI框架內的px也轉換成rem,請把此屬性設為默認值
mediaQuery: true, // (布爾值)允許在媒體查詢中轉換px。
minPixelValue: 3 // 設置要替換的最小像素值(3px會被轉rem)。 默認 0
})
]
}
}
}
};
配置好后,貌似我們成功嘍。來試一下是否可以。在app.vue頁面里給#app配置一下寬度,并給個黑色背景。
啟動服務看下效果:控制臺確實變成了7.5rem,html上的字根大小也確實是動態的。但似乎哪里不對啊!為什么任何型號的手機上都沒有全屏鋪滿黑色?
揭密:
是因為px2rem和amfe-flexible換算的基數不一樣!
以UI圖750px為例,在插件px2rem里配置的基數是100px,即將整屏分成了7.5份,其它型號的手機如果分成7.5份的話,那么基數則是手機寬度/7.5,這個基數是html里的字根的大小。我們來看看amfe-flexible的基數是多少嘞?在node_modules找到amfe-flexible的庫,發現這里設置的是將手機寬度分成了10,則每份的基數變少,所以鋪不滿。這里我們要做下修改,使amfe-flexible與px2rem匹配上:
打開amfe-flexible所在的目錄:
將
var rem = docEl.clientWidth / 10
替換成
var rem = docEl.clientWidth / 7.5
修改后我們再重新啟動一下看看效果吧~
在任何機型下都能鋪滿屏!完美!
接下來我們就可以使用px暢快淋漓地寫代碼啦!
提示:當脫離掉node_modules重新npm install項目依賴時還是需要重新修改一遍的,千萬別忘了!
于 CSSer 來說,多多少少都會遇到過 “樣式規則不生效?”、“樣式規則被覆蓋?” 等等問題,這些都與 CSS 權重有關系。
我自己是一名從事了多年開發的web前端老程序員,目前辭職在做自己的web前端私人定制課程,今年年初我花了一個月整理了一份最適合2019年學習的web前端學習干貨,各種框架都有整理,送給每一位前端小伙伴,想要獲取的可以關注我的頭條號并在后臺私信我:前端,即可免費獲取
選擇器匹配原理
在此之前,容我先簡單介紹瀏覽器是怎么通過各種選擇器,把樣式規則和 DOM 元素扯上關系的。
瀏覽器中存在著專門的渲染引擎來渲染 HTML 文檔。這里以 Webkit 內核為例,在啟動渲染流程時,引擎一方面會解析 HTML 文檔,構建 DOM 節點樹(DOM Tree),另一方面會解析樣式文件生成 樣式規則(Style Rules),然后結合分析 DOM 樹和樣式規則生成 渲染樹(Render Tree),最后 布局 和 繪制 出 UI 界面。
Webkit 渲染流程(摘自 https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/)
CSS 的選擇器匹配就發生在 渲染樹 的構建過程。瀏覽器會從 DOM 樹的根節點開始遍歷每個可見節點,對于每個可見節點都會在規則表中查找適配的樣式規則。那么,如此龐大的樣式數據和復雜的選擇器結構,渲染引擎是怎么尋找到適配當前元素的樣式規則呢?
請看下面這個復合選擇器。如果引擎是按照從左向右的順序匹配選擇器,將會導致大量 回溯 的發生:先是在當前節點到 DOM 樹跟節點的路徑上尋找 div 元素,然后沿著分支路徑繼續往下找第二個 div 元素,如果當前路徑找不到,就得回退到上一個 div 元素嘗試另一條分支路徑。如此往復,對性能損耗將會非常嚴重。
div div span .text {}
所以,引擎是采取 從右向左 的順序來匹配選擇器。也就是 從最具體的選擇器開始,如果與當前節點不匹配,則直接拋棄該條規則;如果匹配,只需要沿著路徑往上確認其他選擇器是否也匹配,這樣做可以大大減少無效的匹配數,提高性能。除此之外,引擎還會把不同類型的選擇器(id、class、tag 及其他類型)歸類到哈希表中,進一步減少查找基數。
了解選擇器的匹配原理,有利于我們理解其權重規則,對于編寫簡潔、高效的 CSS 代碼非常有幫助。
CSS 權重
通過不同的方式(內聯樣式、外部樣式表)、不同類型的選擇器組合針對某個元素聲明樣式規則時,如何決定最終哪個聲明會被應用到元素上?這就涉及到 CSS 權重(也指優先級,Specificity)。
圍繞 CSS 權重主要有以下三條規則:
<html> <head> <style> body div { color: red; } html div { color: blue; } </style> </head> <body> <div>測試</div> </body> <html>
<html> <head> <style> #parent { color: red; } span { color: blue; } </style> </head> <body> <div id="parent"> <span>測試</span> </div> </body> <html>
CSS 權重等級
如何比較不同選擇器的權重高低?這里劃分成 5 個權重等級,按照等級 由高到低 的順序:
<div style="color: #fff;">測試</div>
id 選擇器
#demo {}
類選擇器、屬性選擇器、偽類選擇器
.demo {} [type="text"] {} div:hover {} div:first-child {}
需要注意,否定偽類(:not())比較特殊,它不會對權重產生影響,但是 否定偽類內部的選擇器會影響權重。
<html> <head> <style> div#demo span { color: red; } div:not(#demo) span { color: blue; } </style> </head> <body> <div id="demo"> <span>普通 demo</span> <div id="pseudo"> <span>否定偽類 demo</span> </div> </div> </body> <html>
div {} div:before {} div:after {}
除了上述的選擇器之外,通配符選擇器(*) 和 結合符(+、>、~)對優先級沒有影響。
對于復雜的復合選擇器,我們需要逐個等級比較權重大小,不允許跨越等級比較。為了方便計算,我們可以把權重值具象化,每出現一個選擇器就在其對應的等級區間中權重值加 1,參考下面實例:
* {} /* 權重值 0-0-0-0-0 */ div {} /* 權重值 0-0-0-0-1 */ div h1+h2 {} /* 權重值 0-0-0-0-3 */ div, ... div {} /* 權重值 0-0-0-0-n */ #demo a:hover {} /* 權重值 0-0-1-1-1 */
國外大神 把 CSS 權重的計算模擬成海洋生物鏈,選擇器組合權重越大則在生物鏈位置越高,非常淺顯生動,建議收藏。
圖片轉自 https://specifishity.com/
建議
在充分了解 CSS 選擇器匹配原理和權重規則之后,在編寫 CSS 代碼時不妨多注意以下細節:
<html> <head> <style> div { color: red !important; } /* 通過 id選擇器 增加權重 */ #demo { color: blue !important; } </style> </head> <body> <div id="demo">測試</div> </body> <html>
減少不必要的選擇器嵌套,嵌套最好不要超過三級。大量的復合選擇器,會影響選擇器匹配的效率,同時也會增加 CSS 樣式文件的體積,不易維護。
當出現大量嵌套時,我們可以指定一個更具體的類選擇器來替換復合選擇器。
文分享自華為云社區《DTSE Tech Talk | 3招解決時序數據高基數難題,性能多維度提升!-云社區-華為云》,作者:華為云開源。
本期《openGemini全新列存引擎,為您解決時序數據高基數難題》的主題直播中,華為云開源DTSE技術布道師&數據庫創新Lab技術專家黃飛騰,與開發者朋友們分享了時序數據庫的特點和遙測數據應用場景下的優勢,通過解析openGemini的框架引出了數據庫行業長期存在的一大痛點—由于高基數導致的性能大幅下降,并向大家介紹了openGemini時序數據庫針對這一難題而開發的列存引擎是如何有效改善高基數帶來的不利影響。
市面上有很多不同類型的數據存儲系統,它們在不同場景具有不同的優勢和局限性。那海量遙測數據場景下,我們應該選擇什么類型的數據庫呢?先感受一下遙測數據的龐大,全國每天光智能電表就能生成500億條記錄,10萬輛車的企業每天采集約1PB數據。海量的數據產生后給存儲帶來了巨大的壓力,傳統數據庫已不能滿足如今的實際業務需求。因此,面向運維監控、物聯網等眾多領域,專注海量遙測數據存儲與分析的時序數據庫應運而生。
以openGemini時序數據庫為例,它具有高并發、低時延、低成本的特性,完美契合企業的需要。更重要的是,openGemini框架中自帶全新開發的“列存引擎”,重點解決時序高基數問題,為性能保駕護航。
首先了解一下基數是什么,基數:表示某一列數據中唯一值的個數。
那高基數就可以理解為一個列中不同值的數量很大。不同的標簽或者列有不同的基數,如 ip 地址基數可能達到億級,時間戳則與采樣頻率相關,采樣頻率越高則基數越高。
在高基數的場景下,tag組合數量、SID數量會急劇膨脹,倒排索引中的 SID lists 膨脹,導致倒排索引的維護與查詢開銷增大。
最終,對外表現的性能會急劇下降,那高基數給時序引擎帶來的具體問題為:
openGemini目前解決該問題應對措施為:列式存儲+排序+聚簇索引。
簡單來說,我們把時間線的約束去掉,采取部分的標簽和列做排序,排序完成后會按照排序鍵排序列示存儲,存儲之后再構造一個稀疏(聚簇)索引,這樣的優勢是:索引相對于數據而言,總是稀疏的,與時間線無關,構建開銷不會隨時間線的增加而增加。聚簇索引存儲每個 Block 的第一條記錄,數據有序時,該索引有良好得過濾效果。
列存引擎和時序引擎最主要的差別是數據排序的方式和索引方式的不同。時序引擎是按照時間線力度來做聚簇,然后再按時間做排序。而高基數列存引擎是按照特定的列做排序,跟時間線無關。時序引擎采用倒排索引,時間線膨脹會導致倒排索引的開銷變大,列存引擎的構建與時間線無關。繼而以上的列存引擎設計思路可以大大提升數據庫的讀寫性能。
時序引擎的倒排索引,本質上存儲了一個 kv 對,其中 key 對應到所有的 tag 列名 + tag 值,value 對應該 tag 值所對應的所有時間線,所以通過倒排索引可以快速查找到特定 tag 列的所有唯一值。如果沒有倒排索引,則需要完全掃描該列數據,并進行去重,查詢開銷與數據量成正比,在數據量較大的情形,開銷非常大。新引入的列式存儲方案,基于現有倒排索引對 key 的去重能力,直接存儲了該列的唯一值。
openGemini 從 v1.1.0 版本開始支持列存引擎以及 Arrow 協議。
文檔:https://docs.opengemini.org/zh/guide/features/high_series_cardinality.html
Arrow Flight 配置
創表
接下來請查看實操演示視頻,復制鏈接查看直播完整版:https://bbs.huaweicloud.com/live/DTT_live/202311151630.html
如下圖所示,與其他數據庫做測試對比,從時間線支持規模來看,openGemini達到無上限;單核寫入性格提升到60萬rows/s/cpu;
在特定4個場景下,億級時間線并發查詢時延都遠遠低于測試產品,最低時延為0.012s。在全量數據統計查詢場景下,openGemini與對比產品基本相當,整體時延都非常低。總體看,openGemini不論是寫入還是查詢,性能都十分優秀。
openGemini社區旨在打造開放、合作、包容的全球性技術社區,社區正在快速發展中,接下來會聚焦于開發更多功能,對性能進行調優。社區尚有理想未達,在此誠邀大家參與openGemini的建設(不限于代碼、文檔、生態貢獻),同社區一起成長,彼此攜手方能到達遠方。
關注#華為云開發者聯盟# 點擊下方,第一時間了解華為云新鮮技術~
華為云博客_大數據博客_AI博客_云計算博客_開發者中心-華為云
*請認真填寫需求信息,我們會在24小時內與您取得聯系。