備做一個網頁版聊天界面，表情啊、圖片啊、上傳文件啊都應該要有，視頻就算了，語音還是要的。

本文記錄的是在網頁上用GitHub上的Recorder進行在線錄音和上傳到服務器，前幾天升了一下級，以后有時間再專門寫一篇記錄。

錄音代碼

本示例代碼支持PC、Android、IOS(僅Safari)中使用，如果用RecordApp可增加對IOS(微信瀏覽器、小程序)的支持。

看萬遍代碼不如行動一遍，新建一個html文件，把下面三段代碼復制到文件內，雙擊瀏覽器打開就能進行測試。

<!-- 先加載js錄音庫，注意：你應該把js clone到本地使用 --><meta charset="utf-8" />
<script src="https://xiangyuecn.github.io/Recorder/recorder.mp3.min.js"></script>
<input type="button" onclick="startRec()" value="開始錄音">
<hr>
<input type="button" onclick="playRec()" value="結束并播放">
<input type="button" onclick="uploadRec()" value="結束并上傳">
<script>
var rec;
function startRec(){
 rec=Recorder();//使用默認配置，mp3格式
 
 //打開麥克風授權獲得相關資源
 rec.open(function(){
 //開始錄音
 rec.start();
 },function(msg,isUserNotAllow){
 //用戶拒絕了權限或瀏覽器不支持
 alert((isUserNotAllow?"用戶拒絕了權限，":"")+"無法錄音:"+msg);
 });
};
</script>

上傳服務器代碼

<script>
function uploadRec(){
 //停止錄音，得到了錄音文件blob二進制對象，想干嘛就干嘛
 rec.stop(function(blob,duration){
 /*
 blob文件對象，可以用FileReader讀取出內容
 ，或者用FormData上傳，本例直接上傳二進制文件
 ，對于普通application/x-www-form-urlencoded表單上傳
 ，請參考github里面的例子
 */
 var form=new FormData();
 form.append("upfile",blob,"recorder.mp3"); //和普通form表單并無二致，后端接收到upfile參數的文件，文件名為recorder.mp3
 
 //直接用ajax上傳
 var xhr=new XMLHttpRequest();
 xhr.open("POST","http://baidu.com/修改成你的上傳地址");//這個假地址在控制臺network中能看到請求數據和格式，請求結果無關緊要
 xhr.onreadystatechange=function(){
 if(xhr.readyState==4){
 alert(xhr.status==200?"上傳成功":"測試請先打開瀏覽器控制臺，然后重新錄音，在network選項卡里面就能看到上傳請求數據和格式了");
 }
 }
 xhr.send(form);
 },function(msg){
 alert("錄音失敗:"+msg);
 });
};</script>

立即播放代碼

<script>
function playRec(){
 //停止錄音，得到了錄音文件blob二進制對象，想干嘛就干嘛
 rec.stop(function(blob,duration){
 var audio=document.createElement("audio");
 audio.controls=true;
 document.body.appendChild(audio);
 
 //非常簡單的就能拿到blob音頻url
 audio.src=URL.createObjectURL(blob);
 audio.play();
 },function(msg){
 alert("錄音失敗:"+msg);
 });
};</script>

Recorder

GitHub地址：https://github.com/xiangyuecn/Recorder

在線測試: https://xiangyuecn.github.io/Recorder/

Recorder用于html5錄音，為一個純粹的js庫，支持大部分已實現getUserMedia的移動端、PC端瀏覽器，包括騰訊Android X5內核(QQ、微信)。

錄音默認輸出mp3格式，另外可選wav格式（此格式錄音文件超大）；有限支持ogg、webm、amr格式；支持任意格式擴展（前提有相應編碼器）。

小巧：如果對錄音文件大小沒有特別要求，可以僅僅使用錄音核心+wav編碼器，源碼不足300行，壓縮后的recorder.wav.min.js不足4kb。mp3使用lamejs編碼，壓縮后的recorder.mp3.min.js開啟gzip后54kb。

由于IOS(11.X、12.X)上只有Safari支持getUserMedia，其他瀏覽器均不支持H5錄音，因此額外針對IOS對Recorder進行了進一步的兼容封裝，升級成了RecordApp，用于支持微信（含瀏覽器、小程序web-view），另外RecordApp對Hybrid App也提供了更加優秀的支持。

由于RecordApp需要微信公眾(訂閱)號提供JsSDK錄音支持，所以開發難度會大些，但支持的環境更多。Recorder拿來就能用，具體使用哪個請參考下表：

最后

如果這個庫有幫助到您，請 Star 一下。

原文作者：高堅果兄弟

原文地址：https://www.cnblogs.com/xiangyuecn/p/10772227.html

小白！對象方法里面調用自己的屬性怎么調用？”

“this.語法調用啊！”

老朱說：“沒事我就是隨便問問，今天我們繼續完善昨天的彈窗控件，還是打開昨天建的那個javascript文件里的代碼吧！”

小白說：“好嘞，早就準備好了！”

老朱又重新看了一遍代碼說道：“小白，你說彈窗有哪幾個地方是需要設置的？”

小白想了想說：“提示的標題、提示的內容、還有點了確定要觸發的事件！”

“恩，這三個是比較關鍵的，如果要設置這三個內容，我們是不是應該先給Layer三個屬性？”

“恩，我了解你的意思了，稍等，我把屬性加上！”

“奇怪了，我加上這三個屬性后，在html里面讓標題和內容動態變化怎么會取不到值呢？”

老朱對小白說道：“代碼一眼看上去沒有問題，你可能會想在既然alert方法中能獲取到html屬性的值，為什么獲取不到title和content的值呢？其實你在這里控制臺輸出一下可以看到，這三個值都可以直接在alert方法中輸出。但是有一個點你不要忘了，我們在alert中拿到的html屬性值在使用alert方法之前已經進行過計算，html屬性是取不到title和content的值的，這塊等你詳細了解javaScript對象的機制以后就會明白，現在我們先不用深究，你用之前已經學到的知識想一想還有沒有別的辦法？”

小白想了一會，突然說道：“我知道了，把html屬性改成方法進行賦值就可以了！稍等我再改一下。”

“這次沒有問題了，我把html改成了方法，然后在alert中將title和content的值賦了進去，彈窗不報undefined錯誤了！”

老朱高興的說道：“是啊！這樣我們在頁面中給彈窗（Layer）的title和content賦值以后，通過alert就可以直接彈出結果了，你試試！”

“果然可以使用了！”

老朱跟小白說：“你現在通過設定屬性才能彈窗，能不能實現這樣一個功能，直接通過alert方法也可以實現彈窗提示信息。”

小白想了想說道：“可以，我把alert方法加上參數就可以了！”

“好了，這下不但能夠通過屬性修改標題（title）和內容（content），通過alert方法也可以直接賦值了！”

“小白，這種方法確實可以實現我們想要的功能，不過為了方便我們給alert傳遞的參數最好改成一個javaScript對象，這樣我們就不用考慮傳遞參數的順序了。你再改改吧！”

“改好了，現在傳遞參數的時候傳遞一個Object對象就可以了。這塊我再消化消化吧！感覺信息量有點大。”

老朱跟小白說：“其實也沒多少吧！只不過我們一直在改，點擊確定的事件還沒做呢，還有關閉按鈕，還有動畫效果，還有……”

“唉～我還是先熟悉一下今天說的這點內容吧！”

想學H5的朋友可以關注老爐，您的關注是我持續更新《小白HTML5成長之路》的動力！

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