91欧美超碰AV自拍|国产成年人性爱视频免费看|亚洲 日韩 欧美一厂二区入|人人看人人爽人人操aV|丝袜美腿视频一区二区在线看|人人操人人爽人人爱|婷婷五月天超碰|97色色欧美亚州A√|另类A√无码精品一级av|欧美特级日韩特级

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

緩存分區(qū)可提高安全關(guān)鍵型多核應(yīng)用程序的CPU利用率

星星科技指導(dǎo)員 ? 來源:嵌入式計(jì)算設(shè)計(jì) ? 作者:TIM KING ? 2022-11-08 14:24 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

緩存分區(qū)減少了關(guān)鍵任務(wù)的最壞情況下的執(zhí)行時(shí)間,從而提高了 CPU 利用率,尤其是對(duì)于多核應(yīng)用程序。

多核處理器 (MCP) 的可認(rèn)證、安全關(guān)鍵型軟件應(yīng)用程序的開發(fā)人員面臨的最大挑戰(zhàn)之一是管理對(duì)共享資源(如緩存)的訪問。MCP 顯著增加緩存爭(zhēng)用,導(dǎo)致最壞情況執(zhí)行時(shí)間 (WCET) 超過平均案例執(zhí)行時(shí)間 (ACET) 100% 或更多。由于安全關(guān)鍵型開發(fā)人員必須為 WCET 制定預(yù)算,因此平均分配的任務(wù)(關(guān)鍵和非關(guān)鍵)的時(shí)間超過了所需的時(shí)間,從而導(dǎo)致 CPU 利用率顯著降低。解決此問題的一種方法是利用支持緩存分區(qū)的 RTOS,它使開發(fā)人員能夠以減輕爭(zhēng)用和減少 WCET 的方式綁定和控制干擾模式,從而在不影響安全關(guān)鍵性的情況下最大化可用 CPU 帶寬。

緩存爭(zhēng)用

在簡(jiǎn)單的雙核處理器配置(圖 1)中,每個(gè)內(nèi)核都有自己的 CPU 和 L1 緩存。兩個(gè)內(nèi)核共享一個(gè)二級(jí)緩存。(請(qǐng)注意,未顯示共享內(nèi)存和可選 L3。

圖1:雙核配置,無需緩存分區(qū)

pYYBAGNp9jOAc1p6AAAzASo43tM277.jpg

在此配置中,在核心 0 上執(zhí)行的應(yīng)用程序與在核心 1 上執(zhí)行的應(yīng)用程序競(jìng)爭(zhēng)整個(gè)二級(jí)緩存。(請(qǐng)注意,同一內(nèi)核上的應(yīng)用程序也會(huì)相互競(jìng)爭(zhēng) L2;緩存分區(qū)也適用于這種情況。如果核心 0 上的應(yīng)用程序 A 使用的數(shù)據(jù)映射到與核心 1 上的應(yīng)用程序 B 相同的緩存行,則會(huì)發(fā)生沖突。

例如,假設(shè) A 的數(shù)據(jù)駐留在 L2 中;對(duì)該數(shù)據(jù)的任何訪問都將花費(fèi)很少的處理器周期。但假設(shè) B 訪問的數(shù)據(jù)恰好映射到與 A 的數(shù)據(jù)相同的 L2 緩存行。此時(shí),必須從 L2 中逐出 A 的數(shù)據(jù)(包括對(duì) RAM 的潛在“寫回”),并且必須將 B 的數(shù)據(jù)從 RAM 中引入緩存。處理此碰撞所需的時(shí)間通常由 B 收取。然后,假設(shè) A 再次訪問其數(shù)據(jù)。由于該數(shù)據(jù)不再位于 L2 中(B 的數(shù)據(jù)在其位置),因此必須從 L2 中逐出 B 的數(shù)據(jù)(包括潛在的“寫回”到 RAM),并且 A 的數(shù)據(jù)必須從 RAM 中恢復(fù)到緩存中。處理此碰撞所需的時(shí)間通常由 A 收取。

大多數(shù)時(shí)候,A和B很少會(huì)遇到這樣的碰撞。在這些情況下,它們各自的執(zhí)行時(shí)間可以被視為“平均情況”(ACET)。但是,有時(shí),它們的數(shù)據(jù)訪問會(huì)以高頻率發(fā)生沖突。在這些情況下,它們各自的執(zhí)行時(shí)間必須被視為“最壞情況”(WCET)。

在開發(fā)可認(rèn)證的安全關(guān)鍵型軟件時(shí),必須為最壞情況的行為預(yù)算應(yīng)用程序的執(zhí)行時(shí)間。此類軟件必須有足夠的時(shí)間預(yù)算才能在每次執(zhí)行時(shí)完成其預(yù)期功能,以免導(dǎo)致不安全的故障情況。安全關(guān)鍵型 RTOS 必須強(qiáng)制實(shí)施時(shí)間分區(qū),以便每個(gè)應(yīng)用程序都有固定的 CPU 時(shí)間預(yù)算來執(zhí)行。

由于多個(gè)內(nèi)核上的多個(gè)應(yīng)用程序可能會(huì)產(chǎn)生對(duì) L2 緩存的爭(zhēng)用,因此 MCP 上的 WCET 通常比 ACET 高得多。由于可認(rèn)證的安全關(guān)鍵型應(yīng)用程序必須有時(shí)間預(yù)算來容納其 WCET,這種情況會(huì)導(dǎo)致大量預(yù)算但未使用的時(shí)間,從而導(dǎo)致 CPU 利用率顯著下降。

緩存分區(qū)

緩存分區(qū)通過減少 WCET 來提高 CPU 利用率,從而減少必須預(yù)算以容納 WCET 的時(shí)間量。同樣,在簡(jiǎn)單的雙核處理器配置(圖 2)中,每個(gè)內(nèi)核都有自己的 CPU 和 L1 緩存,并且兩個(gè)內(nèi)核共享一個(gè) L2 緩存。

圖2:具有緩存分區(qū)的雙核配置

poYBAGNp9jWAU6wnAABFE6kB0AU379.jpg

在此配置中,RTOS 對(duì) L2 緩存進(jìn)行分區(qū),以便每個(gè)內(nèi)核都有自己的 L2 段,這意味著內(nèi)核 0 上的應(yīng)用程序使用的數(shù)據(jù)將僅緩存在內(nèi)核 0 的 L2 分區(qū)中。同樣,核心 1 上的應(yīng)用程序使用的數(shù)據(jù)將僅緩存在核心 1 的 L2 分區(qū)中。這種分區(qū)消除了不同內(nèi)核上的應(yīng)用程序通過 L2 沖突相互干擾的可能性。如果沒有這種干擾,應(yīng)用程序 WCET 和 ACET 之間的增量通常比沒有緩存分區(qū)的情況要低得多。通過限制和控制這些干擾模式,緩存分區(qū)使應(yīng)用程序執(zhí)行時(shí)間更具確定性,并使開發(fā)人員能夠更嚴(yán)格地預(yù)算執(zhí)行時(shí)間,從而保持較高的處理器利用率。

測(cè)試環(huán)境和應(yīng)用程序

為了演示緩存分區(qū)的優(yōu)勢(shì),DDC-I 使用 Deos(其可認(rèn)證、安全關(guān)鍵、時(shí)間和空間分區(qū)的 RTOS)來運(yùn)行一套四個(gè)內(nèi)存密集型測(cè)試應(yīng)用程序,所有這些應(yīng)用程序都具有一系列數(shù)據(jù)/代碼大小、順序和隨機(jī)訪問策略以及各種工作集大?。?/p>

只讀

只寫

復(fù)制

代碼執(zhí)行

測(cè)試是在具有 32 KB L1 數(shù)據(jù)緩存、24 KB L1 指令緩存和 512 KB 統(tǒng)一 L2 緩存的 1.6 GHz 凌動(dòng)處理器 (x86) 上進(jìn)行的。請(qǐng)注意,雖然這些測(cè)試使用了單核 x86 處理器,但 Deos 的緩存分區(qū)功能同樣適用于在同一內(nèi)核上執(zhí)行的應(yīng)用程序(這些應(yīng)用程序也競(jìng)爭(zhēng) L2)。此外,它不依賴于 x86 處理器所特有的任何功能,并且同樣適用于其他處理器類型(如 ARM 或 PowerPC)。

測(cè)試是在有和沒有“緩存垃圾箱”應(yīng)用程序的情況下運(yùn)行的,該應(yīng)用程序從L2中逐出測(cè)試應(yīng)用程序數(shù)據(jù)/代碼,并使用自己的數(shù)據(jù)/代碼“臟”L2。實(shí)際上,從測(cè)試應(yīng)用程序的角度來看,緩存垃圾程序?qū)?L2 置于最壞情況狀態(tài)。也就是說,緩存垃圾箱模擬真實(shí)場(chǎng)景,其中不同的應(yīng)用程序同時(shí)運(yùn)行并爭(zhēng)用共享的 L2 緩存。

每個(gè)測(cè)試應(yīng)用程序在三種情況下執(zhí)行。在場(chǎng)景 1 中,在沒有緩存分區(qū)或緩存垃圾的情況下執(zhí)行,測(cè)試應(yīng)用程序?qū)⒏?jìng)爭(zhēng)整個(gè) 512 KB 二級(jí)緩存以及 RTOS 內(nèi)核和各種調(diào)試工具。此測(cè)試建立基線平均性能,其中每個(gè)測(cè)試都以“平均”數(shù)量的 L2 爭(zhēng)用執(zhí)行。

在不使用緩存分區(qū)的場(chǎng)景 2 中,測(cè)試應(yīng)用程序與 RTOS 內(nèi)核、場(chǎng)景 1 中使用的同一組調(diào)試工具以及惡意緩存垃圾程序應(yīng)用程序競(jìng)爭(zhēng)整個(gè) 512 KB 二級(jí)緩存。此測(cè)試建立基線最壞情況性能,其中每個(gè)測(cè)試在來自其他應(yīng)用程序(主要是緩存垃圾程序)的最壞情況下執(zhí)行 L2 干擾。

在使用緩存分區(qū)和緩存垃圾的場(chǎng)景 3 中,將創(chuàng)建三個(gè) L2 分區(qū):

分配給測(cè)試應(yīng)用程序的 256 KB 分區(qū)

分配給 RTOS 內(nèi)核的 64 KB 分區(qū)以及方案 1 和方案 2 中使用的同一組調(diào)試工具

分配給惡意緩存垃圾程序應(yīng)用程序的 192 KB 分區(qū)。

此方案建立了優(yōu)化的最壞情況性能,其中每個(gè)測(cè)試在其自己的 L2 分區(qū)內(nèi)執(zhí)行,不受其他應(yīng)用程序(包括緩存垃圾程序)的干擾。

緩存分區(qū)結(jié)果、優(yōu)勢(shì)

圖 3 顯示了只讀測(cè)試應(yīng)用程序的結(jié)果。

圖3:緩存分區(qū)對(duì)只讀測(cè)試的影響

pYYBAGNp9jaAJhwZAABLOKtqL98240.jpg

例如,在沒有緩存分區(qū)和緩存垃圾的情況下(方案 1,ACET),只讀測(cè)試在工作集大小為 512 KB 的情況下,每次執(zhí)行的平均時(shí)間為 105 微秒。在方案 2(沒有分區(qū)的 WCET,添加了緩存垃圾箱)中,對(duì)于相同的 512 KB 工作集,測(cè)試平均每次執(zhí)行 400 微秒,增加了 280%。添加緩存分區(qū)(方案 3,帶緩存垃圾的 WCET)時(shí),平均執(zhí)行時(shí)間降至 117 微秒,僅比 ACET 高 11%。

這些結(jié)果證明了緩存分區(qū)對(duì)于每個(gè)周期執(zhí)行大量讀取的應(yīng)用程序的有效性。盡管由于量級(jí)差異,此處很難辨別,但當(dāng)應(yīng)用程序的工作集大小適合其使用的緩存分區(qū)(在本例中為 256 KB)時(shí),對(duì)邊界 WCET 的影響更為明顯。由于緩存的性質(zhì),此結(jié)果是預(yù)期的。也就是說,嵌入式實(shí)時(shí)應(yīng)用程序的工作集大小往往相對(duì)較小,因此我們預(yù)計(jì)緩存分區(qū)將使大多數(shù)應(yīng)用程序受益。

只寫測(cè)試的結(jié)果與只讀測(cè)試相似,但對(duì)于較小的工作集更明顯。對(duì)于較大的工作集,結(jié)果顯示具有和不具有緩存分區(qū)的 WCET 之間的差異相對(duì)較小。

復(fù)制測(cè)試的結(jié)果與只讀測(cè)試相似,但對(duì)于較小的工作集更明顯。對(duì)于較大的工作集,結(jié)果不那么顯著,但仍然顯示出具有緩存分區(qū)的 WCET 的顯著改進(jìn)(大約 2 倍)。

代碼執(zhí)行測(cè)試的結(jié)果與只讀測(cè)試類似,但稍微不那么引人注目。

請(qǐng)注意,在同一緩存分區(qū)中執(zhí)行的應(yīng)用程序可能會(huì)相互干擾。但是,與在具有共享緩存的不同內(nèi)核上執(zhí)行的應(yīng)用程序之間可能發(fā)生的不可預(yù)測(cè)的干擾模式相比,此類干擾通常更容易分析和綁定。在這些情況下,如果干擾不可預(yù)測(cè),則可以將應(yīng)用程序映射到單獨(dú)的緩存分區(qū)。

基準(zhǔn)測(cè)試結(jié)果清楚地表明,緩存分區(qū)提供了一種有效的方法來綁定和控制 MCP 上共享緩存中的干擾模式。特別是,在對(duì)緩存進(jìn)行分區(qū)時(shí),可以更嚴(yán)格地綁定和控制 WCET。這允許應(yīng)用程序開發(fā)人員設(shè)置相對(duì)緊湊但安全的執(zhí)行時(shí)間預(yù)算,從而最大限度地提高 MCP 利用率。

當(dāng)然,不同的應(yīng)用和硬件配置的結(jié)果會(huì)有所不同,并且需要額外的RTOS功能才能成功認(rèn)證基于安全關(guān)鍵型MCP的系統(tǒng)。無論如何,這些結(jié)果代表了在使用MCP托管可認(rèn)證的安全關(guān)鍵應(yīng)用程序的目標(biāo)方面的重大進(jìn)步。

審核編輯:郭婷

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • 處理器
    +關(guān)注

    關(guān)注

    68

    文章

    20255

    瀏覽量

    252321
  • cpu
    cpu
    +關(guān)注

    關(guān)注

    68

    文章

    11279

    瀏覽量

    225015
收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評(píng)論

    相關(guān)推薦
    熱點(diǎn)推薦

    GPU 利用率<30%?這款開源智算云平臺(tái)讓算力不浪費(fèi) 1%

    作為 AI 開發(fā)者,你是否早已受夠這些困境:花數(shù)百萬采購的 GPU 集群,利用率常年低于 30%,算力閑置如同燒錢;跨 CPU/GPU/NPU 異構(gòu)資源調(diào)度難如登天,模型訓(xùn)練卡在資源分配環(huán)節(jié);部署
    的頭像 發(fā)表于 01-26 14:20 ?184次閱讀

    華為發(fā)布AI容器技術(shù)Flex:ai,算力平均利用率提升30%

    決方案。 ? 當(dāng)前,AI產(chǎn)業(yè)正處于高速發(fā)展的黃金時(shí)期,海量算力需求如潮水般涌來。然而,算力資源利用率偏低的問題卻成為了產(chǎn)業(yè)發(fā)展的關(guān)鍵桎梏。具體表現(xiàn)為,小模型任務(wù)常常獨(dú)占整卡,導(dǎo)致大量資源閑置;大模型任務(wù)又因單機(jī)算力不足而難以支撐;更有大量缺乏GPU
    的頭像 發(fā)表于 11-26 08:31 ?7605次閱讀

    內(nèi)存與數(shù)據(jù)處理優(yōu)化藝術(shù)

    ,避免了數(shù)組索引的額外計(jì)算。 選擇合適的數(shù)據(jù)類型同樣重要。如果一個(gè)變量只需要表示0或1,使用最小所需的數(shù)據(jù)類型就比使用較大的類型更好,因?yàn)樗加脙?nèi)存更少,可能提高緩存利用率。 對(duì)于浮點(diǎn)運(yùn)算,在不需要
    發(fā)表于 11-14 07:46

    普迪飛 secureWISE 全鏈路守護(hù)方案:讓 Fab 生產(chǎn) “遠(yuǎn)程可控、數(shù)據(jù)管、安全溯”!

    PDF超高安全遠(yuǎn)程監(jiān)控激活設(shè)備全生命周期價(jià)值secureWISE是一款遠(yuǎn)程設(shè)備監(jiān)控與訪問系統(tǒng),基于工業(yè)物聯(lián)網(wǎng)(IIoT)平臺(tái),顯著提升設(shè)備運(yùn)行時(shí)長(zhǎng)、利用率的可視性,進(jìn)而優(yōu)化設(shè)備健康狀態(tài)與功能表
    的頭像 發(fā)表于 09-15 18:08 ?515次閱讀
    普迪飛 secureWISE 全鏈路守護(hù)方案:讓 Fab 生產(chǎn) “遠(yuǎn)程可控、數(shù)據(jù)<b class='flag-5'>可</b>管、<b class='flag-5'>安全</b><b class='flag-5'>可</b>溯”!

    設(shè)備利用率算不清?智能管理系統(tǒng)自動(dòng)分析數(shù)據(jù),生成可視化報(bào)表幫你降本

    當(dāng)設(shè)備數(shù)據(jù)自動(dòng)流轉(zhuǎn)生成可視化報(bào)表,企業(yè)才算真正掌握降本增效主動(dòng)權(quán)。曾經(jīng) Excel 里的利用率 “糊涂賬”,變成清晰可追溯的 “明白錢”。制造業(yè)競(jìng)爭(zhēng)日益激烈的今天,誰能讓設(shè)備數(shù)據(jù)說話,誰就能在成本控制上占先機(jī)。
    的頭像 發(fā)表于 09-12 10:04 ?646次閱讀
    設(shè)備<b class='flag-5'>利用率</b>算不清?智能管理系統(tǒng)自動(dòng)分析數(shù)據(jù),生成可視化報(bào)表幫你降本

    從 “被動(dòng)維修” 到 “主動(dòng)管理”:這套系統(tǒng)讓設(shè)備利用率提升 30%

    從 “被動(dòng)維修” 到 “主動(dòng)管理”,是設(shè)備管理模式的轉(zhuǎn)變,更是數(shù)字化轉(zhuǎn)型的關(guān)鍵一步。在激烈的市場(chǎng)競(jìng)爭(zhēng)中,能讓設(shè)備穩(wěn)定高效運(yùn)行的企業(yè),才能在效率與成本上占據(jù)優(yōu)勢(shì)。這套提升設(shè)備利用率 30% 的系統(tǒng),為企業(yè)高質(zhì)量發(fā)展提供了有效路徑。
    的頭像 發(fā)表于 09-04 10:04 ?853次閱讀
    從 “被動(dòng)維修” 到 “主動(dòng)管理”:這套系統(tǒng)讓設(shè)備<b class='flag-5'>利用率</b>提升 30%

    高性能緩存設(shè)計(jì):如何解決緩存偽共享問題

    多核高并發(fā)場(chǎng)景下, 緩存偽共享(False Sharing) 是導(dǎo)致性能驟降的“隱形殺手”。當(dāng)不同線程頻繁修改同一緩存行(Cache Line)中的獨(dú)立變量時(shí),CPU
    的頭像 發(fā)表于 07-01 15:01 ?762次閱讀
    高性能<b class='flag-5'>緩存</b>設(shè)計(jì):如何解決<b class='flag-5'>緩存</b>偽共享問題

    海光DCU率先展開文心系列模型的深度技術(shù)合作 FLOPs利用率(MFU)達(dá)47%

    海光DCU實(shí)現(xiàn)文心4.5模型高效適配; FLOPs利用率突破47%。 2025年6月30日,在百度文心4.5系列大模型正式開源當(dāng)日,海光信息技術(shù)股份有限公司宣布其深度計(jì)算單元(DCU)率先完成對(duì)該系
    的頭像 發(fā)表于 07-01 14:35 ?2294次閱讀

    Linux系統(tǒng)性能指南

    Linux服務(wù)器運(yùn)行了很多應(yīng)用,在高負(fù)載下,服務(wù)器可能會(huì)出現(xiàn)性能瓶頸,例如CPU利用率過高、內(nèi)存不足、磁盤I/O瓶頸等,從而導(dǎo)致系統(tǒng)卡頓,服務(wù)無法正常運(yùn)行等問題。所以針對(duì)以上問題,可以通過調(diào)整內(nèi)核參數(shù)和系統(tǒng)的相關(guān)組件,優(yōu)化應(yīng)用程序
    的頭像 發(fā)表于 06-23 14:12 ?1787次閱讀
    Linux系統(tǒng)性能指南

    拼版怎么拼好,板廠經(jīng)常說利用率太低,多收費(fèi)用?

    做板的時(shí)候,板廠經(jīng)常說我拼版利用率太低,要多收取費(fèi)用,哪位大神知道怎么算利用率
    發(fā)表于 05-14 13:42

    mes工廠管理系統(tǒng):如何讓設(shè)備利用率提升50%?

    在制造業(yè)競(jìng)爭(zhēng)日益激烈的今天,設(shè)備利用率直接決定了企業(yè)的盈利能力。許多工廠管理者都在思考同一個(gè)問題:如何在不增加設(shè)備投資的情況下,讓現(xiàn)有產(chǎn)能發(fā)揮出最大價(jià)值?MES工廠管理系統(tǒng)正是解決這一難題的金鑰匙
    的頭像 發(fā)表于 05-09 15:55 ?814次閱讀
    mes工廠管理系統(tǒng):如何讓設(shè)備<b class='flag-5'>利用率</b>提升50%?

    MCU緩存設(shè)計(jì)

    從Flash或外部存儲(chǔ)器讀取的指令,減少CPU因等待指令加載而停滯,適用于實(shí)時(shí)性要求高的場(chǎng)景(如中斷服務(wù)程序)。 D-Cache?:緩存從Flash、SRAM或外部存儲(chǔ)器讀取的數(shù)據(jù),加速變量與堆棧的讀寫操作。 TCM(緊耦合內(nèi)存
    的頭像 發(fā)表于 05-07 15:29 ?1113次閱讀

    DeepSeek MoE架構(gòu)下的網(wǎng)絡(luò)負(fù)載如何優(yōu)化?解鎖90%網(wǎng)絡(luò)利用率關(guān)鍵策略

    、All-to-All等),網(wǎng)絡(luò)面臨高并發(fā)、低延遲、無損傳輸?shù)膰?yán)苛需求。然而,傳統(tǒng)以太網(wǎng)的網(wǎng)絡(luò)利用率長(zhǎng)期徘徊在35%~40%,成為制約AI算力釋放的關(guān)鍵瓶頸。
    的頭像 發(fā)表于 04-28 12:04 ?889次閱讀
    DeepSeek MoE架構(gòu)下的網(wǎng)絡(luò)負(fù)載如何優(yōu)化?解鎖90%網(wǎng)絡(luò)<b class='flag-5'>利用率</b>的<b class='flag-5'>關(guān)鍵</b>策略

    TECS OpenStack資源池主機(jī)磁盤分區(qū)使用率過高的問題處理

    某運(yùn)營(yíng)商TECS資源池上報(bào)“主機(jī)磁盤分區(qū)使用率過高”的告警,如下圖所示。
    的頭像 發(fā)表于 03-21 09:47 ?1025次閱讀
    TECS OpenStack資源池主機(jī)磁盤<b class='flag-5'>分區(qū)</b>使<b class='flag-5'>用率</b>過高的問題處理

    程序開發(fā)必須知道的5個(gè)技巧:提升效率與用戶體驗(yàn)的權(quán)威指南

    提升1秒加載速度降低7%的用戶流失。 交互流暢性:利用微信小程序的setData合并更新機(jī)制,減少頻繁渲染導(dǎo)致的卡頓,并通過加載動(dòng)畫緩解等待焦慮。 二、 80%的用戶僅使用小程序20
    發(fā)表于 03-14 14:51