黑粉們，我們平時衡量一部手機性能的基本辦法是什么？”

“跑個分”

“好，那如果有人跑分造假呢？”

“。。。。。。”

隨著智能手機的更新換代速度逐漸加快，我們已經很難再去通過時間慢慢的去了解一部手機了，好像人也如此。

于是這個時候誕生了一眾的跑分軟件，讓我們可以短時間內更直觀的了解一樣產品。

而一個設備的跑分高低，已經成為了影響我們購買決策的因素之一（錢多別說話）。

自然而然的，有的手機廠商就開始盯著這一點了。近日，知名跑分軟件3DMark發現了OPPO的兩款手機涉及跑分造假。

分別是今年“最驕傲”的OPPO Find X和OPPO F7。

3DMark發現這兩款手機為了取得更好的跑分成績，專門對跑分軟件進行了效能調整，把系統所有資源集合起來用于跑出更高的得分。

一般這樣的操作不會被普通軟件觸發，而是遇見跑分類軟件后才會火力全開。但是當把跑分軟件的簽名進行修改后，這樣手機就無法識別出正在運行的是跑分軟件。于是跑出來的分數大跌眼鏡。

差了一大截，具體看下圖

（黑色為正式版，黃色為修改簽名版）

從圖中我們可以看出同一型號的手機，在對簽名修改后的跑分軟件分數低得可怕，這才是它們的真實跑分。

這樣的前后變化在3DMark看來，無疑影響了跑分（基準測試）的公平性，因為跑分時候的高性能，用戶在日常使用中根本享受不到。

對于該事件oppo的回應是：當我們檢測到用戶正在運行“需要高性能的游戲或3D基準測試等應用程序時，我們允許SoC全速運行以獲得最流暢的體驗，我們也從不以跑分作為宣傳重點”

唔，藍綠大廠確實也是從來不靠跑分說話，這一點相信廣大的黑粉們都是知道的。

（深圳地鐵的oppo廣告）

這邊的oppo“跑分造假”風波意外的，讓黑馬想起了前段時間的華為，曾經華為也有幾款設備，遭遇到了3DMark的下架，原因也是跑分作弊。

在3DMark發表聲明之后，華為也對此做出了回應，不過華為的回應不像是oppo這么“高冷”而是顯得非常的“接地氣”。

華為消費者業務軟件總裁王成祿表示：“這些測試不能反映真實情況，其他公司也有類似的行為，華為不能保持沉默”

這就是大寫的明知不可為而為之啊，同時他還表示其他的手機廠商，也通過一些方法提高跑分分數，合著你是打算拖大家下水是吧。

其實，就華為所表的態，整個手機行業還真就是在不停的跑分造假，自己的手機要是不“來點優化”，怎么和其他的手機來一個對比呢？

像“偉大的”三星和“原生”的一加等，這些廠商也都在跑分數據上造過假。

究其背后的原因還不就是因為競爭壓力太大，而且大家的配置基本都是處在同一條水平線。市面上的應用過多、更新過快，軟件層次不可能挨個優化給用戶更高的體驗，配置上來說大家都沒有太大的亮點。

恰好這個時候跑分的出現改變了自己局面，大家爭相對把自己的設備，對跑分軟件進行針對性優化。

在查這個跑分造假歷史的時候意外發現不止手機造假，瀏覽器的HTML5也在造假。

Emmm

甚至還有平板跑分也造假的

當然，也發現了榮耀最早，是在2012年的年底就有跑分造假的“案底”的。

像其他的三星則是在2013年的，時候開始進行跑分造假，HTC則是在2014年開了跑分造假。

唔，這還真的是不好說什么了，綜上所述，跑分造假確實已經是我們的“一大特色”了，簡直就是根深蒂固啊，而這次的oppo的跑分造假，港媒報道后,也遭到了許多人的嘲笑。

或許他們不明白這已經是，我們的“另一種傳統”了吧。但愿有一天，整個行業可以逐漸拋棄掉“跑分造假”。

就像愛奇藝關閉了“前臺播放量展示”一樣，你再去給自己的節目刷播放量已經沒有任何意義了，但愿黑馬能活著見到那一天吧。

e've been testing the final release of iOS 7 over the last few days against our usual battery of HTML5 tests. Normally we're effusive about new releases of iOS to the point of fanboy-dom, but this time, and for the first time ever, we're disappointed in the execution of iOS software. Although there are some impressive performance gains in SVG and JavaScript, the sheer number of bugs and broken features, clearly mark this release as a beta. While nowhere as bad as the Android 3 browser -- our all time champ of broken web releases -- we recommend that organizations standardized on HTML5 development hold off upgrading until an iOS update fixes these issues.

過去幾天以來，我們一直在用我們的那套常規 HTML5 測試套件來考驗 iOS 7 的最終發布版。正常來說，每當迎來 iOS 的新版發布，我們都忍不住像果粉一樣喜大普奔；但這一次，也是有史以來的第一次，我們對 iOS 軟件的完成度表示失望。雖然在 SVG 和 JavaScript 方面有一些突出的性能增長，但面對如此之多的 bug 和不正常的特性，我們只能無情地為這個版本打上 beta 的標簽。當然，它還遠遠沒有敗壞到 Android 3 瀏覽器的程度——那才是無可爭議的爛瀏覽器之終極奧義——但我們仍然建議那些以 HTML5 作為開發標準的公司暫不升級，等到 iOS 7 后續版本修復這些問題之后再說。

iOS 7 Bugs & Features

iOS 7 的 bug 和特性

Max Firtman has already done an excellent first pass about the new features, bugs and quirks in iOS 7's web runtime. If you haven't read his post, you should read it now. We will not repeat all the findings here; but to review, there are two very big bugs in iOS 7. First, WebSQL permissions to increase the default 5MB of space for an app to the previously permitted 50MB limit no longer work correctly, and require a workaround. Second, "Save to Home Screen" apps are basically broken. Once more than four apps are saved to home screen, the save slots are recycled and sometimes duplicated, and the phone has to be rebooted in order to clear itself. Further, any external URI no longer opens correctly and all JavaScript modal dialogs (alert, prompt etc.) are disabled. Finally, If your app uses AppCache and you are managing state via hash or other mechanisms, the history object will never update, disabling history.back.

Max Firtman 已經對 iOS7 瀏覽器的新功能、bug 以及奇怪特性 進行了出色的首輪總結，強烈建議你先讀一遍這篇文章。（譯注：也可以參考 這篇文章的中文譯版。）本文不再重復他的所有發現，我們只回顧一下其中兩個巨大的 bug。

首先，單個應用對 WebSQL 存儲空間的需求從默認的 5MB 申請為 50 MB 上限的過程無法正常實現（譯注：實際上是 iOS 7 在這方面的許可策略發生了變化），需要想辦法繞過去。

其次，“保存到主屏幕”的 web app 基本上廢掉了。似乎主屏幕最多只提供 4 個蹲位來容納 web app 圖標，一旦你試圖突破這個數量，web app 圖標就會相互循環覆蓋，有時甚至出現重復，此時手機不得不重啟才能將主屏幕恢復正常。此外，所有的外部 URL 都無法正常打開（譯注：包括可以撥打電話的 tel:偽協議鏈接），而且所有的 JavaScript 原生模態對話框（alert() 和 prompt() 等等）也都被禁用。別著急，還有，如果你的應用使用了 AppCache（譯注：HTML5 的離線應用緩存特性）并且你通過 hash 或其它機制來管理瀏覽進程，那么 history 對象永遠都不會更新，history.back() 方法也因此失效。

"We recommend that organizations standardized on HTML5 development, hold off on upgrading to iOS 7 until an update fixes these issues."

“我們建議那些以 HTML5 作為開發標準的公司暫不升級，等到 iOS 7 后續版本修復這些問題之后再說。”

Beyond these major bugs, there are also some very troublesome design decisions in iOS 7. First, there is no way to hide the URL bar using JavaScript (and the user no longer has a "full screen" button in mobile Safari). This will throw a wrench into layouts if your app relies on absolute positioning. One workaround, suggested by Andrea Giammarchi, is to ask the user to take an action (such as swiping up) in order to reset into full-screen. But there is no programmatic way to do this (as of yet). And once you are in full-screen, tapping anywhere in the bottom region first summons the browser chrome and there is no way to cancel this. This makes for poor UX for bottom-positioned toolbars: the first user tap summons the browser chrome, which boosts the tool-bar up the page, and then requires the user to tap again to take an action. There are related problems with the status bar which can be worked around.

拋開這些重大 bug 不談，iOS 7 還采用了一些非常討厭的設計決策。首先，無法通過 JavaScript 來隱藏地址欄（而且 Safari 也不再提供一個“全屏”按鈕）。如果你的應用依賴于絕對定位，這個問題將破壞應用的布局。有一個變通方案（由 Andrea Giammarchi 提議），就是要求用戶做一個動作（比如向上滾屏），以便進入全屏狀態。但到目前為止，還沒有一個純程序的方式可以實現類似的效果。而且一旦你進入了全屏狀態，在屏幕底部區域的任意位置點擊，會首先呼出瀏覽器邊框（包括瀏覽器的工具欄和地址欄），而且沒有辦法能阻止這種行為。這將導致定位在底部的工具欄呈現出非常惡心的用戶體驗（譯注：這里的工具欄是指應用自己實現的工具欄）：用戶的第一次點擊工具欄會呼出瀏覽器的邊框，工具欄會被向上推起，然后用戶還需要移動手指并再次點擊，才能最終觸發工具欄上的某個動作按鈕。狀態欄也有著類似的問題，不過幸好有人找出了 一個變通方法。（譯注：此鏈接所描述的狀態欄問題實際上只出現在基于 PhoneGap 開發的混合應用身上，并不涉及 Safari 或 web view 形態的頁面布局。下個版本的 PhoneGap 很可能會從自身層面來解決這個問題。）

In addition to these decisions, right and left swipe gestures within about 10 percent of display edge are always grabbed by iOS and treated as a forward/back request, and not passed to the browser. Furthermore, if you've built back/forward behavior into your app using history push-state, then accidental swipes will load the previous state as if it was a prior web-site. This will probably be unexpected behavior. Chrome for Android was the first browser to introduce this behavior, but has now removed it based on feedback from web developers. We hope Apple follows suit quickly.

除了這些設計決策之外，從屏幕邊緣大約 10% 區域內發起的左右橫掃手勢總是會被系統捕獲，并被視為一次后退/前進的導航操作，而不會作為事件傳遞給瀏覽器。不僅如此，如果你的應用使用了歷史記錄的 pushState 接口來管理后退/前進行為，那么無意的橫掃動作將導致頁面回到上一個狀態，本質上相當于后退到上了一個頁面。這很可能不是我們所期望的行為。Android 版的 Chrome 是最先引入了這種行為的瀏覽器，但后來又在 web 開發者的要求下去除了。我們也希望蘋果能盡快回到正軌。（譯注：這里提到的后退/前進手勢只會在 Safari 下起作用，主屏幕 web app 或 web view 并沒有這兩個手勢。）

In our own testing, we discovered a number of additional bugs in the iOS 7 runtime.

在我們自己的測試中，我們還在 iOS 7 中發現了一些其它 bug。

• On iPad, an orientation change when an input is focused shifts content unpredictably, and causes screen rendering artifacts.
• 在 iPad 上，當一個輸入框獲得焦點時，屏幕旋轉會導致頁面內容無規律地偏移，以及屏幕渲染錯亂。
• Launching and quitting the same home screen app several times can hard lock the device requiring a hardware reboot.
• 啟動并退出同一個主屏幕 web app 數次之后，會導致設備鎖死，只能通過硬件重啟來解決。
• requestAnimationFrame animations do not appear to background correctly, and cause performance degradation in RAF animations on the active page. This defeats one of the major purposes of using RAF animations.
• requestAnimationFrame 動畫（以下簡稱 RAF 動畫）在后臺運作不正常，而且會導致當前頁面的 RAF 動畫性能下降。這一點直接滅掉了 RAF 動畫的最大優勢。
• On iPad, if the document body is set to 100 percent height, content is shifted upwards by 20px in landscape mode. This can be worked around by calling window.scrollTo(0, 0) on the orientationchange event.
• 在 iPad 上，如果 body 的高度被設置為 100% 時，在橫屏狀態下，內容會向上偏移大約 20px。還好這也是可以補救的，我們在 orientationchange 事件上調用一次 window.scrollTo(0, 0) 就可以了。（譯注：這個方法真的好嗎？如果我在豎屏狀態下滾動到一半再旋轉為橫屏呢……）
• In certain cases, resizing a composited layer (an element with 3D transform) does not repaint it correctly. Instead, the cached bitmap is stretched.
• 在某些情況下，一個經過渲染合成的圖層（比如一個具有 3D 變形屬性的元素）在改變大小時無法正確地重繪。僅僅是把已緩存的位圖（即以前渲染完成的結果）拉伸一下完事，并沒有重新渲染生成。
• CSS Animations will sometimes fire before implicit z-indexes have been calculated, resulting in incorrect z layering during an animation.
• CSS 動畫啟動時，隱式的 z-index 并不會被計算，這導致動畫期間圖層的堆疊不正確。（譯注：“隱式的 z-index”是指定位元素未明確設置 z-index 的情況。）
• Scripts running within Web Workers are not suspended unless either the originating page is explicitly killed, or the Safari process is explicitly terminated. Neither switching to another tab, nor minimizing Safari, nor turning off the screen seem to stop Worker execution. This is a serious issue that allows any web page to drain the battery of an iOS 7 device and slow down performance of the whole system without a user alert.
• 在 Web Worker 內運行的腳本永遠不會停止，除非發起 Web Worker 的頁面被強制關閉，或者 Safari 進程被強制終止。切換到另一個頁面、最小化 Safari（譯注：即切換到后臺）或者鎖屏都無法停止 Web Worker 的運行。這是一個很嚴重的問題，它放任任意網頁在沒有任何提示的情況下把電池耗光，并拖慢整個系統的性能。

Performance Characteristics

性能評估

In addition to feature/bug testing, we also put iOS 7 through a battery of our standard performance tests on an iPhone 5 running iOS 6.1 vs. iOS 7. There are some remarkable increases in benchmark performance as well as some very notable misses. First up, we want to note that something odd has happened to the JavaScript timer on iOS 7. In previous versions, iOS had an exceptionally well implemented timer: 4ms with extremely good consistency (see below). But using John Resig's standard timer test resulted in this odd profile: a timer that jumps between 4ms and 12ms with clockwork regularity and much more noise than iOS 6.

除了特性測試和 bug 測試之外，我們對 iOS 7 進行了一系列我們自己的標準性能測試，并對比 iPhone 5 上 iOS 7 和 iOS 6.1 的測試結果。在跑分方面，有一些值得注意的增長，同時也有一些無法忽視的倒退。首先，我們想指出，iOS 7 上的 JavaScript 定時器出現了一些奇怪的情況。在上一個 iOS 版本中，定時期簡直就是夢幻般地完美：4ms 并且有著非常好的一致性（見下圖）。但 iOS 7 在進行 John Resig 的標準定時器測試 時，結果十分奇怪：定時器的間隔在 4ms 和 12ms 之間有規律地來回擺動，與 iOS 6 相比要雜亂不少。

Figure 1A: JavaScript timer resolution: iPhone 5/iOS 7

圖 1A：JavaScript 定時器解析度：iPhone 5/iOS 7

Figure 1B: JavaScript timer resolution: iPhone 5/iOS 6

圖 1B：JavaScript 定時器解析度：iPhone 5/iOS 6

Perhaps this is a limitation of the test in some way, but it's certainly nothing we've ever seen before, and one more reason to make sure that you use requestAnimationFrame for JavaScript animation.

可能這個測試在某些方面存在局限性，但這種情況是我們以前從未見過的，于是我們又多了一個使用 requestAnimationFrame 來實現動畫的理由。

In good news, raw JavaScript performance has increased substantially. SunSpider 1.0 is about 15% faster on iOS 7 vs iOS 6.1, and iOS 7's Octane score is 70% better vs. iOS 6. Some Octane tests showed dramatic speed-ups: Navier-Stokes performance increased by almost 4x. By comparison, Safari on my 2 year old MacBook clocks in at 5,600 -- so iOS 7 is now 50% as fast as desktop Safari on Octane! This is either some serious JIT hacking, or we also speculate that there may be some GPU offloading of general computation in iOS 7?

好消息還是有的，純 JavaScript 性能有了大幅度的提升。與 iOS 6 相比，iOS 7 的 SunSpider 1.0 跑分提升了 15%，Octane 跑分提升了 70%。部分 Octane 測試顯示出了驚人的速度增長：Navier-Stokes 運算的性能漲幅幾乎達到了 4 倍。要知道在兩年前的老 MacBook 筆記本上，Safari 的 Octane 綜合得分是 5600 分，相比之下，現在 iOS 7 的性能已經相當于桌面平臺的 50% 了！這有可能是某些 JIT 技巧的功勞，也有可能是 GPU 在 iOS 7 下以某種方式分擔了 CPU 的運算工作？

Figure 2: Octane Benchmark - iPhone 5 iOS 6 vs. iOS 7 (higher is better)

圖 2：Octane 性能評分：iPhone 5 iOS 6 與 iOS 7 相比（得分越高越好）

But it's not all good news on the performance front. During the iOS 7 beta, we were concerned at the very slow DOM interaction benchmarks that we were seeing from Dromaeo on iOS 7, and expected that Apple would get performance back to snuff before final release. For DOM traversal, attributes and modification, performance is now back at iOS 6 levels, which is good. However DOM Query is still 50% of iOS 6 speed. This is a major concern for the many HTML5 apps that perform high numbers of DOM queries, and this needs to be on Apple's fix-list for its next update.

不過在性能方面并不都是好消息。在 iOS 7 的 beta 期間，我們就曾為 iOS 7 在 Dromaeo 測試上超低的 DOM 操作得分捏把汗，并期待蘋果在最終正式版中扭轉局面。果然，在 DOM 遍歷、存取屬性和修改操作方面，iOS 7 的性能已經回到了 iOS 6 的水準，這很好。但是 DOM 查詢的速度仍然只有 iOS 6 的 50% 左右。這對很多需要大量查詢 DOM 的 HTML5 應用來說，會是一個很大的顧慮，這也是蘋果在下一次更新時需要重點考慮的問題。

Figure 3: Dromaeo benchmark - iOS 6 vs iOS 7 (iOS 6=1.00 - higher is better)

圖 3：Dromaeo 性能評分：iOS 6 與 iOS 7 相比（iOS 6 的得分換算為 1.00，得分越高越好）

Graphics Performance

圖形性能

Test of Canvas performance show a minor improvement in iOS 7 -- about 10% in the Fishtank test and on Mindcat microbenchmarks. But SVG is the real revelation. Thanks to a switch to a new drawing algorithm, SVG Path drawing speed has improved 200x. Yes that's literally 200 times faster. In iOS 6, a 10,000 segment SVG path took about 11 seconds to draw. In iOS 7 that's now 53 milliseconds. iOS is now 6x faster than the Surface RT -- the previous champ at SVG drawing performance.

在 Canvas 性能方面，iOS 7 表現出了少許進步——在 Fishtank 測試和 Mindcat 性能評分中均有 10% 左右的提升。但真正令人驚訝的是 SVG 性能。得益于全新的繪圖算法，SVG 路徑繪制速度提升了 200 倍，是的，你沒有看錯，兩百倍。在 iOS 6 中，一條 10,000 個片段的 SVG 路徑需要花費 11 秒才能繪制完成；但在 iOS 7 中，只需要 53 毫秒。iOS 目前以 6 倍性能領先于 Surface RT——上一代的 SVG 性能之王。

Figure 4: SVG Path Drawing Benchmark (lower is better)

圖 4：SVG 路徑繪制性能評分（得分越少越好）

Other SVG capabilities experience similar speed-ups. Some SVG Filter operations now appear to be GPU accelerated -- which means that meaningful filter animations are now possible on iOS. But performance is dependent on specific filters. Color transformations (Color Matrix & Color Curves) and displacementMaps are fast. Complex compositing and lighting effects are still slow.

其它的 SVG 指標方面也有著類似的速度提升。一些 SVG 濾鏡操作看起來已經支持 GPU 加速——這意味著精心設計的濾鏡動畫在 iOS 上將成為可能。不過性能表現還是因濾鏡而異，色彩變換（色彩矩陣與色彩曲線）和置換貼圖是最快的，但復雜的合成和光照效果仍然比較慢。

And now the real killer. In the rush to get iOS 7 out the door, making sure SVG animation via JavaScript was fast seems to have been dropped on the floor. Animating SVG with JavaScript is now a hit or miss proposition. Animating 500 SVG circles used to be 50 fps on iOS 6. On iOS 7, the animation simply freezes after a few frames. We tried other apps that have interactive UI elements built with SVG, and we saw a similar severe performance degradation.

接下來的這個才是極品。蘋果趕著把 iOS 7 推到臺前，結果把 SVG 動畫這件事兒拋到九霄云外了。用 JavaScript 實現的 SVG 動畫這一需求被完全地漠視了。500 個動態的 SVG 圓圈測試 在 iOS 6 上可以輕易跑到 50 幀/秒，但在 iOS 7 上，動畫在跑了幾幀之后就完全卡住了。我們心有不甘，又嘗試了其它一些基于 SVG 實現 UI 交互的應用，但我們遭遇到了同樣不忍直視的低下性能。

iOS 7: A Beta Release of Web

iOS 7 在 web 方面仍未成熟

Given all these bugs and issues, combined with some genuine major advances, it's hard not to interpret this as a beta release that was rushed into production for the release of the iPhone 5S. In a way, it reminds us of the Android 3 release -- which was rushed into production for the Motorola Xoom tablet -- with severe bugs and performance deficiencies. We're eagerly awaiting the release of the first update for iOS 7 when we hope Apple delivers on its usual commitment to quality.

綜合所有這些 bug 和缺陷，以及少許有誠意的進步，我們不得不認為，為了配合 iPhone 5s 的如期發布，一個 beta 級別的系統就這么倉促地被推到了臺前。在某種程度上，這讓我們想起了 Android 3 的發布——為了配合 Motorola Xoom 平板電腦的發布而不得不趕著上線——結果留下了嚴重的 bug 和性能缺陷。我們急切盼望 iOS 7 后續更新的發布，同時我們希望蘋果可以履行它一直以來對品質的承諾。

But beyond bugs, the design decisions in iOS 7 clearly privilege consumer content over business applications. We remain convinced that Enterprises that want to deploy HTML5 applications to mobile devices can't rely on consumer browsers and need a secure and predictable mobile environment designed for business applications. iOS 7 has convinced us that more than ever that the future of HTML5 app deployment for business is Sencha Space.

但是拋開這些 bug 不談，iOS 7 所采用的設計策略是十分清晰的——重消費者內容，輕商業應用。我們相信，那些需要將 HTML5 應用部署到移動端的企業們不能依賴消費級瀏覽器，而是需要一個專為商業應用設計的、安全可控的移動環境。iOS 7 更加明確地告訴我們，HTML5 商業應用部署方式的未來就是 Sencha Space。

（譯注：你妹，翻譯了這大半天，原來是篇軟文？不過 iOS 7 這回真的讓人揪心啊，曾經的 web 技術先鋒，曾經的最佳 web app 平臺，如今迷失在自己曾經的輝煌里。話說近日 iOS 7.0.2 已經發布，不知道是否有所改觀……）

Written by Michael Mullany

作者介紹

Michael Mullany is Sencha's CEO. He has held various product and executive marketing roles at influential Silicon Valley startups Netscape, Loudcloud, and VMware. He holds an MBA from Stanford University and a BA in economics from Harvard College.

Michael Mullany 是 Sencha 的 CEO。他曾在很多有影響力的硅谷創業公司（比如網景、Loudcloud、VMware）中擔任過多個產品和營銷高層職位。他獲得了斯坦福大學的 MBA 學位，以及哈佛大學的經濟學學士學位。

希望本文能幫助到您！

點贊+轉發，讓更多的人也能看到這篇內容（收藏不點贊，都是耍流氓-_-）

關注 ｛我｝，享受文章首發體驗！

每周重點攻克一個前端技術難點。更多精彩前端內容私信 我 回復“教程”

原文鏈接：https://github.com/cssmagic/blog/issues/33

近接了個需求，要求長按某個標簽顯示刪除一個懸浮的刪除按鈕。這個需求其實在app上很常見，但是在移動端h5中，我們沒有長按的事件，所以就需要自己模擬這個事件了。

大概效果如下：

設計思路：

• 放棄click事件，通過判斷按的時長來決定是單擊還是長按
• 使用touchstart和touchend事件
• 在touchstart中開啟一個定時器，比如在600ms后顯示一個長按菜單
• 在touchend中清除這個定時器，這樣如果按下的時間超過600ms，那么長按菜單已經顯示出來了，清除定時器不會有任何影響；如果按下的時間小于600ms，那么touchstart中的長按菜單還沒來得及顯示出來，就被清除了。

由此我們可以實現模擬的長按事件了。

上代碼

請把重點放在JS上，這里貼出來完整的代碼是為了方便大家看個仔細，代碼可以拷貝直接看效果

css中大部分只是做了樣式的美化，還有一開始讓刪除按鈕隱藏起來

HTML:

<!DOCTYPE html>
<html lang="en">
<head>
 <meta charset="UTF-8">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
 <meta http-equiv="X-UA-Compatible" content="ie=edge">
 <title>Document</title>
 <link rel="stylesheet" type="text/css" href="./longpress.css" />
</head>
<body>
 <div class="container">
 <div class="label" id="label">長按我</div>
 <div class="delete_btn">刪除</div>
 </div>
 <script src="./longpress.js"></script>
</body>
</html>

JS

let timer=null
let startTime=''
let endTime=''
const label=document.querySelector('.label')
const deleteBtn=document.querySelector('.delete_btn')
label.addEventListener('touchstart', function () {
 startTime=+new Date()
 timer=setTimeout(function () {
 deleteBtn.style.display='block'
 }, 700)
})
label.addEventListener('touchend', function () {
 endTime=+new Date()
 clearTimeout(timer)
 if (endTime - startTime < 700) {
 // 處理點擊事件
 label.classList.add('selected')
 }
})

CSS

.container {
 position: relative;
 display: inline-block;
 margin-top: 50px;
}
.label {
 display: inline-block;
 box-sizing: border-box;
 width: 105px;
 height: 32px;
 line-height: 32px;
 background-color: #F2F2F2;
 color: #5F5F5F;
 text-align: center;
 border-radius: 3px;
 font-size: 14px;
}
.label.selected {
 background-color: #4180cc;
 color: white;
}
.delete_btn {
 display: none;
 position: absolute;
 top: -8px;
 left: 50%;
 transform: translateX(-50%) translateY(-100%);
 color: white;
 padding: 10px 16px;
 background-color: rgba(0, 0, 0, .7);
 border-radius: 6px;
 line-height: 1;
 white-space: nowrap;
 font-size: 12px;
}
.delete_btn::after {
 content: '';
 width: 0;
 height: 0;
 border-width: 5px;
 border-style: solid;
 border-color: rgba(0, 0, 0, .7) transparent transparent transparent;
 position: absolute;
 bottom: -9px;
 left: 50%;
 transform: translateX(-50%);
}

ps: touchstart和touchend只有在移動端設備上才有用，如果要看代碼示例的話請:

• 用chrome
• F12打開調時窗
• 切換到模擬移動設備

即點擊如下圖: