K60至尊版狂暴引擎2.0加持：超177萬跑分?jǐn)孬@性能第一
Redmi的后性能時(shí)代戰(zhàn)略發(fā)布會(huì)今天下午如期舉辦，在本次發(fā)布會(huì)上，Redmi公布了多項(xiàng)關(guān)于和聯(lián)發(fā)科的深度合作，以及新機(jī)K60 Ultra在軟件和硬件方面的特性，例如：“K60 至尊版，雙芯旗艦
大家好，這里是大家的林語冰。
JS 的 with() 語句已被腰斬，且強(qiáng)烈建議直接禁用。雖然但是，這合理嗎喵？
with 語句實(shí)際已被棄用，且在嚴(yán)格模式下無法奏效，但即使綜合考慮其“18 禁”的原因，它仍然令人雞凍。讓我們花一些時(shí)間回首往昔，with() 的超能力是什么、其飽受爭議又是為何，以及本人對(duì)這些差評(píng)的反對(duì)意見。
當(dāng)我們讀寫 JS 對(duì)象的屬性時(shí)，我們幾乎總是需要訴諸標(biāo)識(shí)符來限定這些屬性，這樣引擎才知道哪里可以找到對(duì)應(yīng)的值。唯一的例外是全局變量。如果該名稱對(duì)應(yīng)的變量在作用域鏈中不存在，那么會(huì)將其作為 window 或 globalThis 的屬性進(jìn)行檢查。如下所示：
const name = '林語冰'const cat = { name: '薛定諤', isSingle: true}// 搜索 cat 對(duì)象：console.log(cat.name) // '薛定諤'// 搜索作用域鏈，然后繼續(xù)上溯搜索 window/globalThis：console.log(name) // '林語冰'在沒有限定標(biāo)識(shí)符的情況下，with 語句也能讀寫對(duì)象的屬性。我們只需將它們作為獨(dú)立的變量引用即可。
const cat = { name: '薛定諤', isSingle: true}with (cat) { console.log(name) // '薛定諤' console.log(isSingle) // `true`}這能奏效，因?yàn)?nbsp;with() 把 cat 插入作用域鏈的開頭，這意味著，在繼續(xù)上溯搜索之前，這首先會(huì)搜索目標(biāo)對(duì)象的值。順便一提，您仍然可以從更寬泛的作用域讀寫變量 —— 您只需要依賴該顯式標(biāo)識(shí)符：
window.name = '林語冰'with (cat) { console.log(window.name) // "林語冰"}在某些方面，它提供了類似于解構(gòu)賦值的人體工程學(xué)福利。這不需要重復(fù)標(biāo)識(shí)符，語法脂肪會(huì)稍減。但另一個(gè)福利是，with() 內(nèi)執(zhí)行的代碼包含在不同的區(qū)塊作用域中。
如果我們偷瞄 TC39 文檔，我們會(huì)發(fā)現(xiàn)，with() 語句被標(biāo)記為“歷史包袱”，且不鼓勵(lì)使用，但它并沒有深入說明原因。雖然但是，如果我們偷瞄其他資料，就會(huì)發(fā)現(xiàn)若干主要原因。（順便一提，我很可能遺漏了其他某些關(guān)于 with 的關(guān)鍵差評(píng)。如果您了解這些差評(píng)，請(qǐng)不吝賜教。）
如果沒有顯式標(biāo)識(shí)符，那么可能會(huì)寫下某些難以閱讀的“代媽屎山”。請(qǐng)瞄一下這個(gè)函數(shù)：
function doSomething(name, obj) { with (obj) { console.log(name) } console.log(name)}doSomething('林語冰', { name: '薛定諤' })// '薛定諤'// '林語冰'乍一看，并不清楚 name 是什么鬼物 —— 是 obj 上的屬性，還是傳遞給函數(shù)的參數(shù)。并且相同的變量名在整個(gè)函數(shù)體中引用了截然不同的值。這很令人懵逼，并且可能會(huì)讓您搬起石頭砸到自己的貓。畢竟，根據(jù)該變量的使用位置，解析其作用域的執(zhí)行方式一龍一豬。
這是一個(gè)有意義的差評(píng)，但在我看來，這并非致命的批評(píng)。寫下這樣的代碼是開發(fā)者（糟糕的）選擇，并且很大程度上似乎可以通過教育來解決。
除此之外，由于其設(shè)計(jì)，我們可能會(huì)因?yàn)樽x寫不打算處理的不同作用域內(nèi)的屬性，而無意中遭遇 bug。假設(shè)我們有一個(gè)處理包含了戀愛史的 cat 對(duì)象的函數(shù)。
const cat = { history: ['girl1', 'lady2']}function processHistory(cat) { with (cat) { // 使用 history 屬性搞事情 }}processHistory(cat)直到您傳遞一個(gè)沒有 history 屬性的 cat 變量之前，這都能奏效。否則，history 將回退到 window.history（或作用域鏈上存在的其他某些 history 變量），導(dǎo)致意外 bug。
在這個(gè)簡單的示例中，如果 history 是必需屬性，那就問題不大（如果對(duì)象是通過對(duì)象字面量創(chuàng)建的，那么 TS 可以提供輔助），但我們可以看到在更復(fù)雜的場景中出現(xiàn)其他意外。我們正在修改作用域鏈。在某些時(shí)候，奇奇怪怪的事情肯定會(huì)發(fā)生。
當(dāng)與性能相關(guān)時(shí)，事情會(huì)變得更有趣。在我看來，這是我見過的最義憤填膺的差評(píng)。
當(dāng)在 with 語句中讀寫屬性時(shí)，不僅會(huì)在給定對(duì)象的頂層屬性中搜索它的值，還會(huì)在其整個(gè)原型鏈中搜索。如果在原型鏈中搜索不到，它就會(huì)從一個(gè)作用域上溯另一個(gè)作用域繼續(xù)搜索。每次屬性讀寫都必然會(huì)遵循這種搜索順序。根據(jù)具體需求的不同，這可能會(huì)導(dǎo)致某些緩慢的搜索和高性能雷區(qū)。
此處簡述一下下，我們使用 with 讀寫 me 的屬性，該屬性位于原型鏈的底部：
const creature = { name: '碳基生物', planet: '地球' }const mammal = Object.create(creature, { name: { value: '哺乳動(dòng)物' } })const human = Object.create(mammal, { name: { value: '人族' } })const me = Object.create(human, { name: { value: '林語冰' } })function outerFunction() { const outer = 'outer' function innerFunction() { const inner = 'inner' with (me) { console.log(name, planet, inner, outer) // '林語冰' '地球' 'inner' 'outer' } } innerFunction()}outerFunction()由于 name 直接存儲(chǔ)在 me 對(duì)象上，因此搜索它沒有太多開銷。粉絲請(qǐng)記住 —— 目標(biāo)對(duì)象的頂層屬性優(yōu)先被搜索。但 planet 不并非如此，它不在 me 對(duì)象上，因此原型鏈中的每個(gè)對(duì)象都會(huì)搜索一個(gè)值，直到找到為止。
為了獲得相同的“干凈”變量規(guī)避此風(fēng)險(xiǎn)，通常建議使用解構(gòu)賦值。我們重構(gòu)之前的繼承示例：
const creature = { name: '碳基生物', planet: '地球' }const mammal = Object.create(creature, { name: { value: '哺乳動(dòng)物' } })const human = Object.create(mammal, { name: { value: '人族' } })const me = Object.create(human, { name: { value: '林語冰' } })const { name, planet } = meconsole.log(name, planet)// `林語冰` `地球`我理解這為什么這會(huì)成為建議的替代方案：
但從可讀性的角度來看，我并不完全相信它是一個(gè)有價(jià)值的選擇。
使用 with() 的吸引力不僅僅在于“干凈”的變量。它就在控制結(jié)構(gòu)中。由于其周圍的語法，很容易在 with() 語句中有意識(shí)地“存儲(chǔ)”特定任務(wù)。該代碼在詞法作用域和動(dòng)機(jī)上都與其余代碼分開，更易于推理。
請(qǐng)想象一下，您正在處理一個(gè) HTTP 請(qǐng)求，該請(qǐng)求在請(qǐng)求中傳遞某些信息，并且您以某種方式在 data 變量中讀寫它。您的目標(biāo)是使用特定屬性將記錄保存到數(shù)據(jù)庫中。以下是使用解構(gòu)屬性的方案：
const { imageUrl, width, height } = dataawait saveToDb({ imageUrl, width, height})這很好，但是需要多一行代碼來處理這些變量。另外，它們現(xiàn)在都是區(qū)塊作用域，并且可能與方法中涉及的任何其他事情發(fā)生沖突。此時(shí)可能會(huì)有若干意見：
“只需將代碼移動(dòng)到它自己的方法中即可。”我不討厭此意見。從 OOP（面向?qū)ο缶幊蹋┰O(shè)計(jì)的角度來看，這甚至可能是一件好事 —— 父方法會(huì)更精簡和集中。但此建議感覺也像是針對(duì)使用解構(gòu)賦值而引入的問題的解決方案，并且可以使用 with() 的語義來緩解。根據(jù)發(fā)生的其他情況，我可能不想創(chuàng)建一個(gè)不同的方法，但仍然希望有一個(gè)不同的作用域。
“將其全部包裹在一個(gè)臨時(shí)區(qū)塊中?！眂onst 是區(qū)塊作用域，這意味著，可以通過使用大括號(hào)創(chuàng)建新的塊作用域來包含它：
const imageUrl = 'different-image.jpg'{ const { imageUrl, width, height } = data await saveToDb({ imageUrl, width, height })}這里有某些值得褒獎(jiǎng)的奇技淫巧，但您無法讓我相信它更具可讀性。這不是黑客攻擊，但目測有點(diǎn)像黑客攻擊。
現(xiàn)在，針對(duì)同樣的需求，這一次我們訴諸 with 語句來重構(gòu)：
with (data) { await saveToDb({ imageUrl, width, height })}我依然認(rèn)為，解構(gòu)賦值是一個(gè)給力的功能（我經(jīng)常使用它），但至少在可讀性和語義方面，它并不能完全作為 with() 的替代方案。
根據(jù) with() 設(shè)計(jì)操作的本質(zhì)，它絕對(duì)不是處理對(duì)象屬性的最嚴(yán)格的最佳實(shí)踐。但我有所質(zhì)疑，鑒于代碼中實(shí)際發(fā)生的情況，以及與人體工程學(xué)和易讀性收益的權(quán)衡，這種擔(dān)憂到底有多嚴(yán)重。
請(qǐng)考慮此栗子。在我見過的大多數(shù) with() 案例中，大家使用的對(duì)象并不復(fù)雜。它們通常只是簡單的鍵值對(duì)。因此，與大多數(shù)此類案例相比，我制作了一個(gè)相當(dāng)大的案例。這是美國每個(gè)州的列表：
const states = { alabama: 'AL', alaska: 'AK', arizona: 'AZ', arkansas: 'AR', california: 'CA' //... 其余的州府}然后，我運(yùn)行了一個(gè)快速基準(zhǔn)測試來打印每個(gè)值。一項(xiàng)測試使用了 with()：
with (states) { console.log(alabama, alaska /* ...其余的屬性 */)}另一項(xiàng)測試使用解構(gòu)賦值：
const { alabama, alaska /* ...其余屬性 */ } = statesconsole.log(alabama, alaska /* ...其余屬性 */)預(yù)料之內(nèi)，with() 速度較慢，總體慢了約 23%：
圖片
但如果您仔細(xì)觀察這些數(shù)字，并將其置于現(xiàn)實(shí)世界中，就會(huì)發(fā)現(xiàn)此差異幾乎是“沒事找事”。畢竟，您在一秒鐘內(nèi)要處理數(shù)萬個(gè)操作。
別誤會(huì)我的意思。在對(duì)執(zhí)行性能高度敏感的環(huán)境中，這可能會(huì)產(chǎn)生十分有意義的變化。但這些場景可能很少，而且它們可能不應(yīng)該使用 JS。顯然，它們是用 PHP 編寫的。
最重要的是，值得指出的是，with() 遠(yuǎn)不是唯一一個(gè)在使用不當(dāng)時(shí)，可能會(huì)導(dǎo)致性能適得其反的 JS 功能。僅舉一個(gè)栗子：擴(kuò)展運(yùn)算符寫起來確實(shí)很好，但如果在我們代碼的其余部分中沒有小心使用它，事情就會(huì)變得十分敏感。
我很樂意看到一個(gè)“更好”版本的 with() 卷土從來，并進(jìn)行某些調(diào)整提高性能。
我不介意看到的一個(gè)十分具體的變化是不再搜索原型鏈。新版改進(jìn)的 with() 只會(huì)考慮從 Object.getOwnPropertyNames() 返回的對(duì)象的頂層屬性。此更改將減少解析變量所需的時(shí)間，尤其是當(dāng)您完全訪問 with() 上下文之外的變量時(shí)。
一個(gè)與此相關(guān)的有前途的基準(zhǔn)測試。我制作了一個(gè)具有 100 個(gè)鍵/值對(duì)的對(duì)象，其原型鏈有 100 層深。每個(gè)層級(jí)都有相同的一組鍵/值對(duì)。這是用來制作它的零碎代碼：
function makeComplicatedObject() { const obj = Object.fromEntries( Array.from({ length: 100 }).map((_, index) => [ `key_${index}`, `value_${index}` ]) ) return obj}// 結(jié)果：100 個(gè)鍵值對(duì)，原型鏈 100 層深度const deeplyNestedObject = Array.from({ length: 100 }).reduce( (prevObj, _current, index) => { let newObject = makeComplicatedObject() Object.setPrototypeOf(newObject, prevObj) return newObject }, makeComplicatedObject())然后，我在該深層嵌套對(duì)象和具有相同鍵/值對(duì)但沒有巨大原型鏈的另一個(gè)對(duì)象之間運(yùn)行了基準(zhǔn)測試。每個(gè)代碼片段都會(huì)簡單地記錄另一個(gè)局部變量。雖然但是，由于它位于 with() 內(nèi)部，因此它必須首先等待這些對(duì)象被爬取。
結(jié)果應(yīng)該不足為奇。該對(duì)象的“扁平”版本的搜索速度大約快 36%。
圖片
這就說得通了。它并沒有讓 with() 遍歷那個(gè)令人討厭的原型鏈。我敢打賭，99.99% 的使用 with() 的現(xiàn)實(shí)代碼也不需要這樣做。
順便一提，我在構(gòu)建自己的更“限量版”的 with() 時(shí)度過了一段有趣的時(shí)光。它使用一個(gè)簡單的 Proxy 來使 with() 認(rèn)為該對(duì)象僅在它是頂級(jí)鍵之一時(shí)“具有”屬性：
function limitedWith(obj, cb) { const keys = Object.getOwnPropertyNames(obj) const scopedObj = new Proxy(obj, { has(_target, key) { return keys.includes(key) } }) return eval(` with(scopedObj) { (${cb}.bind(this))(); } `)}盡管使用 JS 來解決驅(qū)動(dòng)引擎的原生代碼無疑可以青出于藍(lán)勝于藍(lán)，但基準(zhǔn)測試結(jié)果也不算太糟糕：
圖片
當(dāng)然，這只是桌面上的一項(xiàng)優(yōu)化。我也不討厭能夠?qū)⒛繕?biāo)作用域傳遞到 with() 的想法。默認(rèn)情況下，它將在作用域鏈中一直搜索變量。但如果傳遞特定值，它將被限制在該作用域內(nèi)：
with ((someObject, { scope: 'module' })) { // 在 someObject 的外部， // 當(dāng)且僅當(dāng)此模塊作用域會(huì)被搜索}拋開這些問題不談，當(dāng)大家不鼓勵(lì)使用某功能時(shí)，它們很可能會(huì)在有限范圍的情況下思考，并在此過程中做出若干假設(shè)。它們可能包括但不限于：
順便一提，這樣的假設(shè)通常是準(zhǔn)確的，值得牢記在心。但它們并不總是準(zhǔn)確的。它們經(jīng)常忽視工程師被迫做出的特定權(quán)衡、它們正在構(gòu)建的工具的目的或其他因素。
最好的證據(jù)是這樣一個(gè)事實(shí)：由真正聰明、有洞察力的工程師編寫的真正優(yōu)秀、信譽(yù)良好的庫，今天在它們的代碼庫中仍然有 with()。
有的庫的大部分內(nèi)容都不會(huì)在主線程中執(zhí)行，因此它與大多數(shù)其他庫相比，在一組根本不同的性能約束上運(yùn)行。這可以說是一個(gè)特例，但至少與 with() 應(yīng)該被撤銷的主張相悖。畢竟，您必須有一個(gè)非常非常好的案例，才能移除某個(gè)功能，尤其是當(dāng)它已經(jīng)成為該語言的一部分這么久的情況下。
本文鏈接：http://www.tebozhan.com/showinfo-26-58932-0.html您不知道的 JS with 語句，讓我來告訴您！
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： Apollo，真香！
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)