整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
黑粉們，我們平時(shí)衡量一部手機(jī)性能的基本辦法是什么？”
“跑個(gè)分”
“好，那如果有人跑分造假呢？”
“。。。。。。”
隨著智能手機(jī)的更新?lián)Q代速度逐漸加快，我們已經(jīng)很難再去通過時(shí)間慢慢的去了解一部手機(jī)了，好像人也如此。
于是這個(gè)時(shí)候誕生了一眾的跑分軟件，讓我們可以短時(shí)間內(nèi)更直觀的了解一樣產(chǎn)品。
而一個(gè)設(shè)備的跑分高低，已經(jīng)成為了影響我們購買決策的因素之一（錢多別說話）。
自然而然的，有的手機(jī)廠商就開始盯著這一點(diǎn)了。近日，知名跑分軟件3DMark發(fā)現(xiàn)了OPPO的兩款手機(jī)涉及跑分造假。
分別是今年“最驕傲”的OPPO Find X和OPPO F7。
3DMark發(fā)現(xiàn)這兩款手機(jī)為了取得更好的跑分成績，專門對跑分軟件進(jìn)行了效能調(diào)整，把系統(tǒng)所有資源集合起來用于跑出更高的得分。
一般這樣的操作不會(huì)被普通軟件觸發(fā)，而是遇見跑分類軟件后才會(huì)火力全開。但是當(dāng)把跑分軟件的簽名進(jìn)行修改后，這樣手機(jī)就無法識(shí)別出正在運(yùn)行的是跑分軟件。于是跑出來的分?jǐn)?shù)大跌眼鏡。
差了一大截，具體看下圖
（黑色為正式版，黃色為修改簽名版）
從圖中我們可以看出同一型號(hào)的手機(jī)，在對簽名修改后的跑分軟件分?jǐn)?shù)低得可怕，這才是它們的真實(shí)跑分。
這樣的前后變化在3DMark看來，無疑影響了跑分（基準(zhǔn)測試）的公平性，因?yàn)榕芊謺r(shí)候的高性能，用戶在日常使用中根本享受不到。
對于該事件oppo的回應(yīng)是：當(dāng)我們檢測到用戶正在運(yùn)行“需要高性能的游戲或3D基準(zhǔn)測試等應(yīng)用程序時(shí)，我們允許SoC全速運(yùn)行以獲得最流暢的體驗(yàn)，我們也從不以跑分作為宣傳重點(diǎn)”
唔，藍(lán)綠大廠確實(shí)也是從來不靠跑分說話，這一點(diǎn)相信廣大的黑粉們都是知道的。
（深圳地鐵的oppo廣告）
這邊的oppo“跑分造假”風(fēng)波意外的，讓黑馬想起了前段時(shí)間的華為，曾經(jīng)華為也有幾款設(shè)備，遭遇到了3DMark的下架，原因也是跑分作弊。
在3DMark發(fā)表聲明之后，華為也對此做出了回應(yīng)，不過華為的回應(yīng)不像是oppo這么“高冷”而是顯得非常的“接地氣”。
華為消費(fèi)者業(yè)務(wù)軟件總裁王成祿表示：“這些測試不能反映真實(shí)情況，其他公司也有類似的行為，華為不能保持沉默”
這就是大寫的明知不可為而為之啊，同時(shí)他還表示其他的手機(jī)廠商，也通過一些方法提高跑分分?jǐn)?shù)，合著你是打算拖大家下水是吧。
其實(shí)，就華為所表的態(tài)，整個(gè)手機(jī)行業(yè)還真就是在不停的跑分造假，自己的手機(jī)要是不“來點(diǎn)優(yōu)化”，怎么和其他的手機(jī)來一個(gè)對比呢？
像“偉大的”三星和“原生”的一加等，這些廠商也都在跑分?jǐn)?shù)據(jù)上造過假。
究其背后的原因還不就是因?yàn)楦偁帀毫μ螅掖蠹业呐渲没径际翘幵谕粭l水平線。市面上的應(yīng)用過多、更新過快，軟件層次不可能挨個(gè)優(yōu)化給用戶更高的體驗(yàn)，配置上來說大家都沒有太大的亮點(diǎn)。
恰好這個(gè)時(shí)候跑分的出現(xiàn)改變了自己局面，大家爭相對把自己的設(shè)備，對跑分軟件進(jìn)行針對性優(yōu)化。
在查這個(gè)跑分造假歷史的時(shí)候意外發(fā)現(xiàn)不止手機(jī)造假，瀏覽器的HTML5也在造假。
Emmm
甚至還有平板跑分也造假的
當(dāng)然，也發(fā)現(xiàn)了榮耀最早，是在2012年的年底就有跑分造假的“案底”的。
像其他的三星則是在2013年的，時(shí)候開始進(jìn)行跑分造假，HTC則是在2014年開了跑分造假。
唔，這還真的是不好說什么了，綜上所述，跑分造假確實(shí)已經(jīng)是我們的“一大特色”了，簡直就是根深蒂固啊，而這次的oppo的跑分造假，港媒報(bào)道后,也遭到了許多人的嘲笑。
或許他們不明白這已經(jīng)是，我們的“另一種傳統(tǒng)”了吧。但愿有一天，整個(gè)行業(yè)可以逐漸拋棄掉“跑分造假”。
就像愛奇藝關(guān)閉了“前臺(tái)播放量展示”一樣，你再去給自己的節(jié)目刷播放量已經(jīng)沒有任何意義了，但愿黑馬能活著見到那一天吧。
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.
過去幾天以來，我們一直在用我們的那套常規(guī) HTML5 測試套件來考驗(yàn) iOS 7 的最終發(fā)布版。正常來說，每當(dāng)迎來 iOS 的新版發(fā)布，我們都忍不住像果粉一樣喜大普奔；但這一次，也是有史以來的第一次，我們對 iOS 軟件的完成度表示失望。雖然在 SVG 和 JavaScript 方面有一些突出的性能增長，但面對如此之多的 bug 和不正常的特性，我們只能無情地為這個(gè)版本打上 beta 的標(biāo)簽。當(dāng)然，它還遠(yuǎn)遠(yuǎn)沒有敗壞到 Android 3 瀏覽器的程度——那才是無可爭議的爛瀏覽器之終極奧義——但我們?nèi)匀唤ㄗh那些以 HTML5 作為開發(fā)標(biāo)準(zhǔn)的公司暫不升級(jí)，等到 iOS 7 后續(xù)版本修復(fù)這些問題之后再說。
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 已經(jīng)對 iOS7 瀏覽器的新功能、bug 以及奇怪特性 進(jìn)行了出色的首輪總結(jié)，強(qiáng)烈建議你先讀一遍這篇文章。（譯注：也可以參考 這篇文章的中文譯版。）本文不再重復(fù)他的所有發(fā)現(xiàn)，我們只回顧一下其中兩個(gè)巨大的 bug。
首先，單個(gè)應(yīng)用對 WebSQL 存儲(chǔ)空間的需求從默認(rèn)的 5MB 申請為 50 MB 上限的過程無法正常實(shí)現(xiàn)（譯注：實(shí)際上是 iOS 7 在這方面的許可策略發(fā)生了變化），需要想辦法繞過去。
其次，“保存到主屏幕”的 web app 基本上廢掉了。似乎主屏幕最多只提供 4 個(gè)蹲位來容納 web app 圖標(biāo)，一旦你試圖突破這個(gè)數(shù)量，web app 圖標(biāo)就會(huì)相互循環(huán)覆蓋，有時(shí)甚至出現(xiàn)重復(fù)，此時(shí)手機(jī)不得不重啟才能將主屏幕恢復(fù)正常。此外，所有的外部 URL 都無法正常打開（譯注：包括可以撥打電話的 tel:偽協(xié)議鏈接），而且所有的 JavaScript 原生模態(tài)對話框（alert() 和 prompt() 等等）也都被禁用。別著急，還有，如果你的應(yīng)用使用了 AppCache（譯注：HTML5 的離線應(yīng)用緩存特性）并且你通過 hash 或其它機(jī)制來管理瀏覽進(jìn)程，那么 history 對象永遠(yuǎn)都不會(huì)更新，history.back() 方法也因此失效。
"We recommend that organizations standardized on HTML5 development, hold off on upgrading to iOS 7 until an update fixes these issues."
“我們建議那些以 HTML5 作為開發(fā)標(biāo)準(zhǔn)的公司暫不升級(jí)，等到 iOS 7 后續(xù)版本修復(fù)這些問題之后再說。”
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 還采用了一些非常討厭的設(shè)計(jì)決策。首先，無法通過 JavaScript 來隱藏地址欄（而且 Safari 也不再提供一個(gè)“全屏”按鈕）。如果你的應(yīng)用依賴于絕對定位，這個(gè)問題將破壞應(yīng)用的布局。有一個(gè)變通方案（由 Andrea Giammarchi 提議），就是要求用戶做一個(gè)動(dòng)作（比如向上滾屏），以便進(jìn)入全屏狀態(tài)。但到目前為止，還沒有一個(gè)純程序的方式可以實(shí)現(xiàn)類似的效果。而且一旦你進(jìn)入了全屏狀態(tài)，在屏幕底部區(qū)域的任意位置點(diǎn)擊，會(huì)首先呼出瀏覽器邊框（包括瀏覽器的工具欄和地址欄），而且沒有辦法能阻止這種行為。這將導(dǎo)致定位在底部的工具欄呈現(xiàn)出非常惡心的用戶體驗(yàn)（譯注：這里的工具欄是指應(yīng)用自己實(shí)現(xiàn)的工具欄）：用戶的第一次點(diǎn)擊工具欄會(huì)呼出瀏覽器的邊框，工具欄會(huì)被向上推起，然后用戶還需要移動(dòng)手指并再次點(diǎn)擊，才能最終觸發(fā)工具欄上的某個(gè)動(dòng)作按鈕。狀態(tài)欄也有著類似的問題，不過幸好有人找出了 一個(gè)變通方法。（譯注：此鏈接所描述的狀態(tài)欄問題實(shí)際上只出現(xiàn)在基于 PhoneGap 開發(fā)的混合應(yīng)用身上，并不涉及 Safari 或 web view 形態(tài)的頁面布局。下個(gè)版本的 PhoneGap 很可能會(huì)從自身層面來解決這個(gè)問題。）
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.
除了這些設(shè)計(jì)決策之外，從屏幕邊緣大約 10% 區(qū)域內(nèi)發(fā)起的左右橫掃手勢總是會(huì)被系統(tǒng)捕獲，并被視為一次后退/前進(jìn)的導(dǎo)航操作，而不會(huì)作為事件傳遞給瀏覽器。不僅如此，如果你的應(yīng)用使用了歷史記錄的 pushState 接口來管理后退/前進(jìn)行為，那么無意的橫掃動(dòng)作將導(dǎo)致頁面回到上一個(gè)狀態(tài)，本質(zhì)上相當(dāng)于后退到上了一個(gè)頁面。這很可能不是我們所期望的行為。Android 版的 Chrome 是最先引入了這種行為的瀏覽器，但后來又在 web 開發(fā)者的要求下去除了。我們也希望蘋果能盡快回到正軌。（譯注：這里提到的后退/前進(jìn)手勢只會(huì)在 Safari 下起作用，主屏幕 web app 或 web view 并沒有這兩個(gè)手勢。）
In our own testing, we discovered a number of additional bugs in the iOS 7 runtime.
在我們自己的測試中，我們還在 iOS 7 中發(fā)現(xiàn)了一些其它 bug。
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 進(jìn)行了一系列我們自己的標(biāo)準(zhǔn)性能測試，并對比 iPhone 5 上 iOS 7 和 iOS 6.1 的測試結(jié)果。在跑分方面，有一些值得注意的增長，同時(shí)也有一些無法忽視的倒退。首先，我們想指出，iOS 7 上的 JavaScript 定時(shí)器出現(xiàn)了一些奇怪的情況。在上一個(gè) iOS 版本中，定時(shí)期簡直就是夢幻般地完美：4ms 并且有著非常好的一致性（見下圖）。但 iOS 7 在進(jìn)行 John Resig 的標(biāo)準(zhǔn)定時(shí)器測試 時(shí)，結(jié)果十分奇怪：定時(shí)器的間隔在 4ms 和 12ms 之間有規(guī)律地來回?cái)[動(dòng)，與 iOS 6 相比要雜亂不少。
Figure 1A: JavaScript timer resolution: iPhone 5/iOS 7
圖 1A：JavaScript 定時(shí)器解析度：iPhone 5/iOS 7
Figure 1B: JavaScript timer resolution: iPhone 5/iOS 6
圖 1B：JavaScript 定時(shí)器解析度：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.
可能這個(gè)測試在某些方面存在局限性，但這種情況是我們以前從未見過的，于是我們又多了一個(gè)使用 requestAnimationFrame 來實(shí)現(xiàn)動(dòng)畫的理由。
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 運(yùn)算的性能漲幅幾乎達(dá)到了 4 倍。要知道在兩年前的老 MacBook 筆記本上，Safari 的 Octane 綜合得分是 5600 分，相比之下，現(xiàn)在 iOS 7 的性能已經(jīng)相當(dāng)于桌面平臺(tái)的 50% 了！這有可能是某些 JIT 技巧的功勞，也有可能是 GPU 在 iOS 7 下以某種方式分擔(dān)了 CPU 的運(yùn)算工作？
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 操作得分捏把汗，并期待蘋果在最終正式版中扭轉(zhuǎn)局面。果然，在 DOM 遍歷、存取屬性和修改操作方面，iOS 7 的性能已經(jīng)回到了 iOS 6 的水準(zhǔn)，這很好。但是 DOM 查詢的速度仍然只有 iOS 6 的 50% 左右。這對很多需要大量查詢 DOM 的 HTML5 應(yīng)用來說，會(huì)是一個(gè)很大的顧慮，這也是蘋果在下一次更新時(shí)需要重點(diǎn)考慮的問題。
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 表現(xiàn)出了少許進(jìn)步——在 Fishtank 測試和 Mindcat 性能評分中均有 10% 左右的提升。但真正令人驚訝的是 SVG 性能。得益于全新的繪圖算法，SVG 路徑繪制速度提升了 200 倍，是的，你沒有看錯(cuò)，兩百倍。在 iOS 6 中，一條 10,000 個(gè)片段的 SVG 路徑需要花費(fèi) 11 秒才能繪制完成；但在 iOS 7 中，只需要 53 毫秒。iOS 目前以 6 倍性能領(lǐng)先于 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 指標(biāo)方面也有著類似的速度提升。一些 SVG 濾鏡操作看起來已經(jīng)支持 GPU 加速——這意味著精心設(shè)計(jì)的濾鏡動(dòng)畫在 iOS 上將成為可能。不過性能表現(xiàn)還是因?yàn)V鏡而異，色彩變換（色彩矩陣與色彩曲線）和置換貼圖是最快的，但復(fù)雜的合成和光照效果仍然比較慢。
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.
接下來的這個(gè)才是極品。蘋果趕著把 iOS 7 推到臺(tái)前，結(jié)果把 SVG 動(dòng)畫這件事兒拋到九霄云外了。用 JavaScript 實(shí)現(xiàn)的 SVG 動(dòng)畫這一需求被完全地漠視了。500 個(gè)動(dòng)態(tài)的 SVG 圓圈測試 在 iOS 6 上可以輕易跑到 50 幀/秒，但在 iOS 7 上，動(dòng)畫在跑了幾幀之后就完全卡住了。我們心有不甘，又嘗試了其它一些基于 SVG 實(shí)現(xiàn) UI 交互的應(yīng)用，但我們遭遇到了同樣不忍直視的低下性能。
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 和缺陷，以及少許有誠意的進(jìn)步，我們不得不認(rèn)為，為了配合 iPhone 5s 的如期發(fā)布，一個(gè) beta 級(jí)別的系統(tǒng)就這么倉促地被推到了臺(tái)前。在某種程度上，這讓我們想起了 Android 3 的發(fā)布——為了配合 Motorola Xoom 平板電腦的發(fā)布而不得不趕著上線——結(jié)果留下了嚴(yán)重的 bug 和性能缺陷。我們急切盼望 iOS 7 后續(xù)更新的發(fā)布，同時(shí)我們希望蘋果可以履行它一直以來對品質(zhì)的承諾。
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 所采用的設(shè)計(jì)策略是十分清晰的——重消費(fèi)者內(nèi)容，輕商業(yè)應(yīng)用。我們相信，那些需要將 HTML5 應(yīng)用部署到移動(dòng)端的企業(yè)們不能依賴消費(fèi)級(jí)瀏覽器，而是需要一個(gè)專為商業(yè)應(yīng)用設(shè)計(jì)的、安全可控的移動(dòng)環(huán)境。iOS 7 更加明確地告訴我們，HTML5 商業(yè)應(yīng)用部署方式的未來就是 Sencha Space。
（譯注：你妹，翻譯了這大半天，原來是篇軟文？不過 iOS 7 這回真的讓人揪心啊，曾經(jīng)的 web 技術(shù)先鋒，曾經(jīng)的最佳 web app 平臺(tái)，如今迷失在自己曾經(jīng)的輝煌里。話說近日 iOS 7.0.2 已經(jīng)發(fā)布，不知道是否有所改觀……）
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。他曾在很多有影響力的硅谷創(chuàng)業(yè)公司（比如網(wǎng)景、Loudcloud、VMware）中擔(dān)任過多個(gè)產(chǎn)品和營銷高層職位。他獲得了斯坦福大學(xué)的 MBA 學(xué)位，以及哈佛大學(xué)的經(jīng)濟(jì)學(xué)學(xué)士學(xué)位。
點(diǎn)贊+轉(zhuǎn)發(fā)，讓更多的人也能看到這篇內(nèi)容（收藏不點(diǎn)贊，都是耍流氓-_-）
關(guān)注 ｛我｝，享受文章首發(fā)體驗(yàn)！
每周重點(diǎn)攻克一個(gè)前端技術(shù)難點(diǎn)。更多精彩前端內(nèi)容私信 我 回復(fù)“教程”
原文鏈接：https://github.com/cssmagic/blog/issues/33
近接了個(gè)需求，要求長按某個(gè)標(biāo)簽顯示刪除一個(gè)懸浮的刪除按鈕。這個(gè)需求其實(shí)在app上很常見，但是在移動(dòng)端h5中，我們沒有長按的事件，所以就需要自己模擬這個(gè)事件了。
大概效果如下：
設(shè)計(jì)思路：
由此我們可以實(shí)現(xiàn)模擬的長按事件了。
上代碼
請把重點(diǎn)放在JS上，這里貼出來完整的代碼是為了方便大家看個(gè)仔細(xì)，代碼可以拷貝直接看效果
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) {
// 處理點(diǎn)擊事件
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只有在移動(dòng)端設(shè)備上才有用，如果要看代碼示例的話請:
即點(diǎn)擊如下圖:
*請認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
