黑粉们，我们平时衡量一部手机性能的基本办法是什么？”

“跑个分”

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

“。。。。。。”

随着智能手机的更新换代速度逐渐加快，我们已经很难再去通过时间慢慢的去了解一部手机了，好像人也如此。

于是这个时候诞生了一众的跑分软件，让我们可以短时间内更直观的了解一样产品。

而一个设备的跑分高低，已经成为了影响我们购买决策的因素之一（钱多别说话）。

自然而然的，有的手机厂商就开始盯着这一点了。近日，知名跑分软件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打开调时窗
• 切换到模拟移动设备

即点击如下图: