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