整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
004 年 Google Maps 的面世標志著 Java 桌面時代的終結，也改變了桌面環境下“跨平臺”的基本定義。
本文作者以個人視角對 Java 桌面發展歷程做了回顧，內容來自他在上世紀九十年代后期擔任 Java 開發者時的所見所感，主要講述曾經的“殺手級”桌面語言 Java 是為何從 21 世紀開始頹勢盡顯、步入衰落的。值得一提的是，作者如今在做一款開發者友好型 Java 桌面部署工具（jDeploy），其實他還是希望 Java 可以重拾風采，再度變得對桌面開發具有吸引力。
本文是該回顧系列文章中的第二篇，在上期文章中，作者回顧了 Java 制霸桌面的鴻圖如何在 1999 至 2005 的短短幾年間煙消云散。當初的 Java 可謂志得意滿、憑 Applet 小程序技驚四座，下決心要在互聯網時代下重新定義“桌面”?；ヂ摼W的未來在于“跨平臺”，而 Java 的血管中涌動的正是“跨平臺”的血液，優勢在握！可遺憾的是，事后來看，此跨平臺似乎并非彼跨平臺。接下來，讓我們繼續跟著作者的腳步去看看，具體在 2004 至 2007 年間，Java 桌面又經歷了什么。
2002 年左右，我在客服中心為客戶提供計算機與打印機技術支持。我和小伙伴們擠在小小的隔間里，面對著一款桌面程序。通過這款軟件，我們可以快速查詢客戶和產品信息，并把通話中的重要信息記錄進去。
在典型的客服來電中，我們會詢問客戶的產品序列號，再把結果輸入系統。如果他們之前就打過電話，系統就會輸出窗口，里面包含產品的完整歷史記錄和之前的求助細節。在參考其他同事留下的事由記錄后，我還能操作界面中的選項卡和功能按鈕，例如幫客戶更換新機。
我不記得這款軟件叫什么名字了，可能是為公司或者客服中心專門定制的吧。印象里這應該是 PeopleSoft（仁科公司，2005 年已被甲骨文收購）的產品，但我也不太確定?？傊@款桌面軟件運行在 Windows 2000 系統上，肯定不是 Web 應用程序。它其實挺復雜，里面包含不少菜單和表單；不過一旦上手，整個使用體驗相當棒——速度快、反應靈敏，幾乎沒有任何延遲。以輸入電話號碼查詢客戶記錄為例，我們只需要在“電話”字段里輸入號碼，其余空白表格就會立刻被客戶信息填充完整。
據我所知，這款程序肯定不是用 Swing 編寫的。但如今全球各地無數公司都在使用由 Swing 編寫的企業級桌面軟件，它們在使用體驗上跟我當初接觸的這款程序非常相似。換句話說，Swing 已經滿足了我們在 2001、2002 年那會對于桌面業務軟件的全部期望和想象。
在工作半年之后，上邊來了新指示，要求我們用 Web 應用程序替換掉之前的桌面軟件。據說新系統會讓我們的工作更輕松，但在第一節培訓課剛剛過去十分鐘后，我們就意識到這根本就是胡說八道：新系統簡直爛透了！
我不太記得當時使用的是 IE 5.5 還是 IE 6 了，總之就是前 AJAX 時代的 Web 環境。現在在產品字段中輸入序號后，系統會彈出一個窗口，上面寫著“正在加載……請勿關閉此窗口”。幾秒后，窗口自行消失，客戶詳細信息出現在表單當中。反正每當需要從服務器獲取內容時，這個倒霉窗口就會跳出來。領導還提醒我們別隨便在瀏覽器里點“刷新”，說是這樣會破壞系統狀態。于是每每出現問題，我就只能先登出、再重新登錄。
我不太理解公司為什么要用這款“傻了吧唧”的 Web 應用程序替代之前的桌面軟件?？赡苁浅鲇诔杀究紤]吧，畢竟跟桌面軟件相比，Web 應用程序的開發和維護成本都更低?；蛘呤擒浖虖娦惺?，比如“Web 才是未來，每個人都必須接受！”但，真有這么強勢的乙方嗎？
無論如何，這里透露出一個重要的信息：Web 應用程序還沒等發展完善，就已經開始蠶食桌面軟件的生存空間。唯一的問題就是 Web 應用需要多久才能追平桌面軟件的使用體驗。而事實證明，用不了多久。
再回到 Java 這邊。熱情的支持者們正不斷擴大 Java 帝國的桌面版圖，對 WORA（一次編寫、隨處運行）的熱情也引導他們最終邁向跨平臺小程序與“本機”應用程序之間的秘密山谷。那時候的 Java IDE 主要面向三大構建目標：
從 2022 年的角度回顧，Java 身上其實有很多顯而易見的問題。應用程序可以作為 Web 部署、也可以按本機部署，但這兩種形式都沒有一丁點“原生”感。Web 部署的小程序運行在自己的“沙箱”內并被集成到網頁當中，整個運行過程又慢又遲鈍。
雖然 Java 總想在 Web 和桌面之間建起一道橋梁，但它自身卻被 Web 所裹挾。到 2002 年，很多企業開始把原本的桌面軟件功能遷移到 Web 端。這些 Web 應用程序的構建、維護和部署成本確實比桌面軟件低得多，代價就是在用戶體驗上做出妥協。
大約也是在這個時候，Java 開始推崇“富互聯網應用”的概念，希望把好 Web 應用跟差 Web 應用區分開來。但到 2004 年 Google Maps 正式亮相時，Java 的小把戲徹底宣告破產。Google Maps 以令人震驚的效果為富 Web 應用程序樹立了標桿，而人家用的是 HTML5。
我最近又看了一次 Bill Atkinson 第一次向蘋果愛好者們展示 MacPaint 的舊視頻。在他第一次通過鼠標用畫筆工具繪出圖案時，現場一片“哇哦”和掌聲。這就叫開創性。我第一次看到 Google Maps 也是類似的感覺，地圖可以無縫縮放、萬向平移，壓根看不出來任何拼接的痕跡。這里使用的全新技術被稱為 AJAX（異步 JavaScript 與 XML），這也是人們第一次能夠在 Web 應用程序中向服務器后臺無縫發出請求?，F在這一切當然被視為理所當然，可 2004 年那會，開發者需要絞盡腦汁才能把那些讓人想吐的框架或者彈窗隱藏起來，確保不用刷新整個頁面就能從服務器處加載新數據。
身為 Web 開發者，我當然對其中的無窮可能性心生向往。但從桌面開發的角度看，這場歷史性的變革似乎沒有給桌面、特別是 Java 帶來任何影響。
在 HTML5 之前，“跨平臺”的意思是“跨 Windows、Mac 和 Linux”，所以跨的范圍還是在桌面范疇之內。當時我并沒意識到，但現在來看 HTML5 的亮相代表著新平臺時代的降臨——它將成為客戶端應用程序的客觀標準；更重要的是，Java 支持不了這個平臺。突然之間，WORA 理念就出現空白了——Swing 應用程序適用于一切平臺，除了最重要的那個：網絡瀏覽器。
那 Java 桌面開發者們都跑哪去了？方向主要有三：
2000 年初，JavaScript 開發工具尚處于起步階段。大多數 Web 開發者只能使用文本編輯器來編寫.js 文件。簡單的驗證腳本和交互設計倒是沒問題，但這種粗糙的方法肯定不能擴展并支持大型企業應用程序項目。另外，當時的 JavaScript 語言還不具備開發者在重構等重要操作時所需要的功能，例如靜態類型。
相比之下，Java 已經擁有一套全面的開發工具，能夠輕松擴展至任何規模的項目。到 2004 年，領先且成熟的 Java IDE 已經成為開發環境中的標桿，其中的靜態類型更是大大簡化了大型項目的維護難度。到這時，唯一的遺憾就是 Java 應用程序無法在網絡瀏覽器中運行（只有小程序可以）。
為了解決這個難題，Google 打造出 GWT（Google Web Toolkit）。這是一套 Java 到 JavaScript 的編譯器加運行時庫，允許開發者借助 Java 那一整套領先的開發工具編寫應用程序，再把成果部署成 JavaScript 應用的形式在瀏覽器內原生運行。這套運行時庫包含諸多核心 Java API（例如 java.lang、java.util 等）的實現，確保業務邏輯能夠在 GWT 應用程序與服務器應用程序間順暢共享。
在用戶界面方面，GWT 也提供自己的功能部件，其實質就是以 Java 的形式將各部件與瀏覽器中的本機 HTML 部件相綁定。雖然我們還是沒法直接使用 Swing 代碼、大部分第三方庫也不在支持之列，但我們至少可以用到自己最熟悉的 Java 開發環境和核心 API。
所以這不能算是讓 Java 真正走進了瀏覽器——標準 JavaSE 庫仍然大部分不受支持，線程等核心功能也無法起效。但至少對多數用例來說，這已經夠了。
Google 用 GWT 開發出很多流行一時的 HTML5 應用程序，其中最著名的就是 Gmail，這個項目還催生出一個規模不大、但卻相當活躍的開源社區。雖然影響力已經今非昔比，但這個社區直到現在也仍然存在。與此同時，JavaScript 工具的逐步改進也在擠占 GWT 的生存空間，過去十年來誕生的一系列更為現代的解決方案也允許我們在瀏覽器中更“無腦”地使用 Java。
HTML5 的出現顛覆了 Java 制霸桌面的野心，但這里也有好消息。由于不必分神于桌面端，Java 在服務器端迎來了全面發展。Java 做好了戰斗準備、努力滿足開發者對后端服務的種種新需求——畢竟沒有后端，再好的 Web 應用也出不來。
Java 在服務器端的受歡迎程度在接下來幾年中持續增長，也吸引到整個生態系統的高度關注。第三方庫不斷涌現，而 2005 年 Maven 的誕生也讓第三方庫的使用不再復雜繁瑣。無需額外下載、不必尋找依賴項，直接把片段粘貼到 pom 文件中，它就能自動下載一切相應依賴項。
Java 的開發工具也在不斷改進，這在很大程度上要歸功于 Java 在服務器端的優勢地位。這些改進也對桌面開發者產生了積極影響，讓我們用上了跟服務器端相同的 IDE、編譯器、虛擬機和庫。然而，代表 Java 世界“最后的堅持”的這幫桌面開發者眼界還是沒能打開，仍在圍著 UI 庫的改進和部署打轉。
遇到問題時，我的習慣是上 Google 搜一搜，看看有沒有其他人遇到或者已經解決過相同的問題。但在 Swing 開發上，我發現最新的搜索結果也基本是 2005 年左右的內容了，之后基本再無新增。在找不到答案時，我偶爾會寫一篇問題分析博文。而在兩年后再次遇到類似問題時，我在 Google 上找到的就是自己兩年前那篇博文……說真的，現在還有喘氣的 Swing 開發者嗎？感覺真的說不好。
從各個方面來看，Web 的興起讓“桌面應用”的概念清晰了起來。Java 最初的跨平臺客戶端開發愿景并沒有把瘦客戶端（主要與遠程服務器交互）跟本機完整桌面應用程序區分開來。這不僅提高了理解難度，更讓安全模型的設計有些無所適從。Java 理解中的“平臺”就是計算機本身，所以會使用笨拙的沙箱來限制可能引發安全威脅的 API 訪問，例如訪問文件系統。這是 Java 一切安全漏洞的根源，也是導致 Java 被逐出瀏覽器世界的原因。
這種基于“沙箱”的開發體驗相當糟糕，因為我們很容易意外“越界”并觸發安全異常。最終結果是，幾乎所有客戶端都會請求對系統進行“可信”訪問，這樣也就完全繞過了沙箱的限制。
相比之下，HTML5 在 Web 和桌面之間設立了明確的邊界。Web 應用程序默認無權訪問客戶端計算機，而瀏覽器才是那個“平臺”，這就讓客戶端應用程序的安全保障變得更輕松、更易行。
經過此番變革，“桌面”的范疇變得更小，以往很多被視為“桌面應用程序”的軟件現在被劃入“客戶端應用程序”類別。具體來講，如果應用程序只負責在用戶與服務器交互時提供 UI，那它就屬于客戶端應用程序?！白烂妗边@個概念現在指的就是那些以某種方式與本機設備相集成的應用程序，包括訪問文件系統（開發工具、文件轉換工具等）、調用瀏覽器中不存在的某些平臺本機 API、以及執行算力密集型任務的軟件。
這倒不是說“客戶端”應用程序跟“桌面”應用程序間就毫無交集——當然有，這兩者都涉及 GUI，而且不少現代桌面應用程序也都需要接入服務器。所以無論是桌面還是客戶端應用程序，都能享受到 GUI 工具包改進、媒體（音頻/視頻）及網絡等技術層面的改進成果。
2004 年，我曾在 Mac 和 Windows 上都開發出一些商用級別的 Java 桌面應用程序。HTML5 對這類應用程序基本沒有任何直接影響。結合自身需求，Swing 還是完全夠用，我用來構建本機捆綁包的各種桌面部署工具也都能正常起效。
但很遺憾，科技行業就是個不進則退的世界。在接下來的幾年中，Web 平臺一路突飛猛進、而 Swing 卻始終停滯不前。到 2007 年，Swing 已經到了不變革、就消亡的危難關頭。它需要響應 HTML5 這波歷史性潮流，而最終答案就是 JavaFX。這是一種新奇的 Java UI 工具包，能夠把 Java 帶入 GPU 加速、場景圖、3D 圖形、Web 視圖的現代新世界，同時支持 MP3 和 MP4 等現代音視頻編解碼器。
在下一篇文章中，我們將回顧 JavaFX 的火爆人氣、深遠影響，以及 2011 年 Mac 應用商店出現前 Java 領域的其他發展趨勢。別小瞧 Mac 應用商店，它的出現堪稱對 Java for Mac 桌面開發生態的“斬首行動”。
原文鏈接：
https://jdeploy.substack.com/p/the-decline-and-fall-of-java-on-the-970
了解更多軟件開發與相關領域知識，點擊訪問 InfoQ 官網：https://www.infoq.cn/，獲取更多精彩內容！
作為一名Web開發者，可能你并沒有對這個“H5”這個字眼投入太多的關注，但實際上它早已不知不覺進入到你的開發中，并且總有一天會讓你不得不正視它，了解它并運用它
打個比方：《海賊王》中的主角路飛在“頂上戰爭兩年前”，會在一些危急關頭“不經意”地使用霸王色霸氣，但對”霸氣“的結構體系和具體運用都不太了解，這讓他在香波地群島等諸多重大戰役中大吃苦頭。此后， 他不惜花費兩年時間跟隨雷利修煉霸氣。因為，如果不去了解這個嶄新的戰斗方法的話，他們在殘酷的新世界一天也生存不了。
咳咳， 回到主題，為什么我們要學HTML5呢？
1. 了解HTML5的囊括范圍的一大好處是：當你不小心使用了一個H5的東東的時候（例如你試圖通過百度找到的答案解決一個緊張的需求），你會很及時的關注它的兼容性
2. H5有些新增的特性也許你從沒接觸過，也感覺無需用到它。但就在不久的將來，你可能就會用到，甚至依賴于它（畢竟這就是HTML的未來）
在下面， 我將學習H5中的知識點分成兩類：主要知識點和針對特定功能的知識點，其中對主要知識點的部分，從學習成本的角度對其進行了難度分級
（僅屬個人觀點！如有改進意見，歡迎討論）
一.主要知識點
（從需求層面上來說，普及范圍相對較廣）
相對容易的部分：
1.在線和離線事件（Online/Offline） （相對容易）
2. 眾多的新增元素 如<output>， <progress>等 （相對容易）
3. history關于歷史狀態管理的API （相對容易）
4 Storage（localStorage和sessionStorage） （相對容易）
相對較難的部分：
5. Web Worker （相對較難）
6. canvas （相對較難）
7. indexedDB （相對較難）
8. 拖放操作 （相對較難）
9. Web Sockets (相對較難)
二. 針對特定功能的知識點
（對需求來說，主要針對某一方面的特殊需求場景）
1. 對音視頻的支持
2. Camera API （操作攝像頭）
3. WebGL （3D圖像）
4. 地理位置定位 （geolocation對象）
本文主要講述H5中主要知識點中，學習成本相對較高的四個點（僅個人觀點）：
一.Web Worker
二.canvas
三.indexedDB
四.拖放操作
【注意】因為下面介紹的H5的特性在一些比較老的瀏覽器里可能遇到兼容性問題，所以你在使用前必須要能力檢測，例如這樣
Web Worker的機制讓你能夠創建一個在后臺線程運行的腳本，這個腳本不會對我們當前執行任務的腳本造成任何干擾（例如阻塞），同時Web Worker提供了一套API使你能夠在當前腳本和后臺腳本間進行數據的互相傳輸（worker）
“一套API， 兩個對象”
我們現在已知的關于Web Worker的機制是： 有一個當前腳本， 和一個在后臺運行的worker腳本，所以我們問題的關鍵就落在了這兩個腳本的通信（數據交互）上
通過
生成了“兩個對象”（你可能會問：為什么是兩個不是一個呢？請往下看）
“第一個”對象是我們在當前腳本中通過構造函數顯式創建出來的worker對象，它擁有一套API：postMessage和onmessage,通過postMessage方法可以向worker腳本（上文worker.js）發送數據， 通過onmessage方法可以從worker腳本接收數據
“第二個”對象是在Web Worker腳本（上文的worker.js）中隱式創建出來的全局變量對象，它叫DedicatedWorkerGlobalScope（這個時候在work.js全局變量對象是它而不是Window!!）,而它也擁有一套API：postMessage和onmessage,通過postMessage方法可以向當前執行任務的腳本發送數據， 通過onmessage方法可以從當前執行任務的腳本接收數據
【注意】關于DedicatedWorkerGlobalScope
1. 它是在Web Worker腳本中生成的特殊的全局變量對象，也就是在全局執行環境中使用this指向的不是Window而是它
2. 它不能像Windows那樣通過變量名直接訪問，但在Web Worker腳本中你能通過this取到它
所以現在數據傳遞方向有兩條：
1. 調用當前腳本中worker對象的postMessage方法， 然后在Web Worker腳本（上文的worker.js）中通過onmessage這個回調方法接收數據
2. 調用Web Worker腳本中的this.postMessage方法（this指向DedicatedWorkerGlobalScope），然后在當前腳本中worker對象的onmessage回調方法接收數據
看到這里可能有點懵，來讓我們通過一個例子看看1中的數據傳遞：
先看示例吧，這是我們的目錄結構
index.html:
main.js:
worker.js:
點擊按鈕后，在main.js中調用worker對象的postMessage方法， 這個數據就被發給了work.js中的全局變量對象DedicatedWorkerGlobalScope， 所以我們在work,js中通過this.onmessage接收數據并輸出
【注意】postMessage傳遞的參數會被“原封不動”地傳遞給onmessage中event對象的data屬性
例如：
postMessage([1,2,3]) ——> this.onmessage = function (e) { } 中 e.data === [1,2,3]
postMessage({a:1,b: 2}) ——> this.onmessage = function (e) { } 中 e.data === {a:1,b: 2}
我們上面的例子展現的是從當前任務腳本向worker腳本傳遞數據，那么同樣的道理，我們也能從work腳本向當前任務腳本傳遞數據（方式相同）
例子：
index.html：
同上
main.js：
worker.js:
demo如下
點擊傳遞數據輸出：
cancas是H5新增的一個標簽，把canvas翻譯過來就是畫布，顧名思義，這是用來”畫畫的“，那畫畫的”畫筆“是什么呢？ 它就是和canvas元素對象對應的一個”上下文對象“（context）,這里的這個上下文對象可能和你印象中的”上下文“有較大的差異，它只是個單純的包含了一系列“繪畫”方法的對象，下面我們介紹的關于canvas的內容都要圍繞這個"canvas上下文對象"展開
我們可以通過這種方式取得canvas上下文對象：
假設這是我們的HTML：
這樣取得上下文對象：
下面展現的是上下文對象的一些繪制圖形的方法（它們都可以被ctx調用）
上面的x,y代表相對于canvas畫布左上角的橫縱坐標：
例子：
html部分：
JS部分：
【注意】. canvas標簽內的內容（例如上面的文本）是否呈現取決于瀏覽器是否支持canvas，如果支持，則不出現，如果不支持，則會呈現出來
demo:
我們以上面的為基礎稍作修改：
demo:
demo:
這里要稍微提一下， 也許上面的那些繪制圖形，繪制文本的操作對你來說都沒有觸動，因為它們離我們的直接需求似乎還有一定的距離，但我想接下來的這幾個上下文API你或許有些興趣。
例如我們可能有一個需求是載入已有的圖片，對它截圖（裁剪）后保存為一張新的圖片，這個時候我們就可以使用到canvas的繪制圖片，裁剪圖片，保存圖片的API了
通過canvas上下文對象的drawImage方法可直接繪制圖片
我們可以通過下面的一段代碼動態獲取img元素對象
廢話不多說，直接上demo!
在相同目錄下有這么一張圖片
JS代碼：
demo:
我們發現， 圖片加載完成后被寫入了畫布當中！
canvas上下文對象的clip方法可根據路徑對canvas畫布進行裁剪
讓我們在原來的基礎上添加一點東西：
【注意】clip方法的調用要在drawImage方法之前，否則不能成功！ 也就是說要“先裁剪，再畫圖”
canvas的保存和導出
我們通過document.getElementById("canvas")取得的畫布對象，有一個toDataURL()方法，可將當前畫布作為一張圖片，并返回其base64編碼格式的數據，這在保存圖片的時候非常有用
toDataURL接受兩個參數：圖片類型和質量參數
canvas.toDataURL(圖片類型，質量參數)
看下面的例子
控制臺輸出了base64格式的數據：
我們通過網上的還原軟件看看會把這個base64數據還原成什么圖片：
正是我們想要的圖片
indexedDB是存在于瀏覽器中的數據庫，它和一般的數據庫一樣有寫改刪查的功能，不同之處在于：常見的數據庫一般是在服務器上，并且要求我們的應用在線時才可以工作，而indexedDB使得在離線的時候讀取數據成為了可能。下面，我就給大家介紹一下這個“駐扎”在瀏覽器上的特殊的數據庫吧
我們首先要做的事情，當然是創建（或打開）一個數據庫，這要用到indexedDB對象的open方法
它接收兩個參數： 數據庫名稱和數據庫版本（第二個參數是可選的）
調用open方法時候，如果對應名稱的數據庫不存在，則創建一個新的數據庫，如果已存在，則打開已存在的那個數據庫
需要說明的是， indexedDB里面絕大多數操作都是異步的， 上述的indexedDB.open并不會立即創建一個數據庫， 你需要在異步的回調里面判斷數據庫是否創建成功，并對可能出現的錯誤做判斷和處理
只有在onsuccess回調中，你才能通過request.result取得創建成功的數據庫
通過open返回的request對象有三個回調：
onsuccess 每次創建/打開數據庫時候都會調用
onerror 創建/打開數據庫發生錯誤的時候調用
onupgradeneeded 數據庫版本變化的時候調用 （onupgradeneeded 是我們唯一可以修改數據庫結構的地方）
open一個indexedDB數據庫后，一般在onupgradeneeded回調中初始化（或修改）數據庫結構（劃重點?。。?/strong>
這包括兩個方面的操作：
1. 通過db.createObjectStore創建對象存儲空間,并取得ObjectStore對象（類似于SQL數據庫中的建表操作）
2. 通過調用ObjectStore.createIndex創建該存儲空間內的索引( 以便于提高查詢時候的速度)
具體的可看下面的例子：
運行一下， 然后讓我們看看效果：
打開chrome的Application面板，點擊左欄的Storage下的indexedDB使其展開
就可以看到我們新創建的phwDataBase數據庫， 以及它內部的people數據存儲空間了
（右邊展示的是people數據存儲空間的具體內容，因為現在什么數據都還沒添加，所以key和value兩列下是沒有內容的）
看了上面的代碼你可能會有些疑惑
onupgradeneeded 和onsuccess回調的關系是怎樣的？ 為什么我們必須在.onupgradeneeded中初始化數據庫的結構，而不是在onsuccess中？
這主要是由兩個回調調用的時機決定的：
1.對 onsuccess回調，在每次數據庫創建/打開的時候都會調用（不僅是第一次創建的時候會調用，每次打開的時候也都會調用）
2. 對onupgradeneeded回調，在open提供第二個版本參數的前提下：
2.1 第一次調用open方法創建一個新的數據庫的時候，onupgradeneeded一定會被調用
2.2 第二次或以后open該數據庫，只在版本參數改變的時候， onupgradeneeded才會被調用
【注意】在缺少第二個版本參數的情況下，onupgradeneeded永遠不會被調用?。?/p>
所以說：
1.open數據庫的時候，最(yi)好(ding)要帶上第二個參數（版本參數）
2. 修改數據庫結構（例如創建和刪除對象存儲空間以及構建和刪除索引。）要在onupgradeneeded回調中運行
（很顯然每次打開都會被調用的onsuccess并不適合用于初始化數據庫結構）
首先說一下，在下面的展示例子中，我們的HTML是這樣的
demo:
這里要說明一下的是，indexedDB的操作是以事務為基礎的。 所以，對存儲空間（objectStore）的操作都要基于事務來進行。 具體點說，就是需要先通過db.transaction()方法取得transaction對象，然后再通過transaction.objectStore()方法取得目標objectStore，再然后才能調用objectStore的API進行“寫改刪查”
打個比方， 如果說我們存儲的數據是糧食的話， objectStore就是一個個并排的糧倉，你可以往里面運糧食，也可以把糧食運出去， 但你對“糧食”做任何行為前， 都要和糧倉門前的守衛—— transaction（事務）“打聲招呼”，得到準許才能進入糧倉
有兩個方法要說一下
1. transaction方法
transaction 方法 一般接受兩個參數，并返回一個事務對象。
1.1第一個參數是一個數組， 一個我們希望事務能夠操作的objectStore所組成的數組，如果你希望這個事務能夠操作所有的objectStore,那么傳入空數組[]即可
1.2 第二個參數是一個字符串， 默認是“onlyread”, 如果我們有需要對數據進行寫操作的需求的話可傳入“readwrite”
例如我們下面的一行代碼：
2. transaction.objectStore方法
這個方法接受一個參數： 指定的objectStore的名稱， 方法返回的是獲取到的objectStore
例如我們下面的一行代碼：
寫操作的關鍵在于objectStore.add(XXX);方法，其中XXX是我們初始化objectStore時候寫入的“主鍵”
也就是 var objectStore = db.createObjectStore("people", { keyPath: "id" }); （這段代碼在上面）中keyPath的值——id
demo:
點擊“增加數據”后彈出
再看看application面板下的indexedDB:
我們已經成功添加了三條數據進去了
刪操作的關鍵在于objectStore.delete(XXX);方法，其中XXX是我們初始化objectStore時候寫入的“主鍵”
也就是 var objectStore = db.createObjectStore("people", { keyPath: "id" }); 中keyPath的值——id
點擊上面的“刪除數據”按鈕（刪除id = 1的數據）
再來看看, id為1的那一行已經被刪除了
刪操作的關鍵在于objectStore.get(XXX);方法
demo:
點擊“獲取數據”按鈕,彈出
（這里固定查找id為2的數據）
遍歷數據需要用到游標
通過 objectStore.openCursor()可創建一個游標對象（cursor）, 這個cursor對象包含兩個屬性值： key和value
key就是我們一直說的那個“主鍵”， 而value是我們存入的時候的那個對象，通過 cursor.continue方法可以使得游標向下移動
點擊“遍歷全部數據”按鈕，看看控制臺
我們通過objectStore.get方法，通過查找主鍵的方式查找對應的對象數據的方式是很快的。
但如果我們通過非主鍵的數據去查找對應的那個對象就非常慢了，這個時候我們需要創建一個索引并通過索引來查找， 從而獲得較快的速度：
點擊“通過索引獲取數據”按鈕：
好！ 現在讓我們對indexedDB做一個小小的總結：
1. indexedDB是面向對象的， 與傳統的以二維表為基礎的數據庫不同
2. IndexedDB是一個事務型數據庫系統
3. indexedDB大多數API都是異步的，這意味著調用一個方法你不能馬上得到關鍵的那個對象，而在對應的success回調中才能取得
一個典型的拖放操作是這樣開始的：用戶用鼠標選中一個可拖動的（draggable）元素，移動鼠標到一個可放置的（droppable）元素，然后釋放鼠標。 在操作期間，會觸發一系列的拖放類型的事件
其中我們主要關心的事件有三個：
1. ondragstart 發生在可拖拽(draggable)的元素上, 在元素被拖動的時候調用
2. ondragover 發生在可放置（droppable）的元素上， 當某被拖動的對象在可放置對象范圍內（上方）時觸發此事件
3. ondrop 發生在可放置（droppable）的元素上，當釋放鼠標使可拖拽元素“放進”可放置元素內的瞬間觸發。
需思考的問題：
1. 如何使得被拖拽元素可拖拽？（因為元素默認的行為是不可拖拽的），以及如何使得被放置的容器元素可放置？ （因為元素默認是不可放置的）
對前者， 我們可以為元素設置draggable屬性，并且設置為true
對后者， 我們可以在被放置的容器元素中的ondragover事件里通過event.preventDefault();阻止默認行為——禁止放置
2.如何實現“脫 — 放”過程的數據傳遞？
這里首先需要知道的是，當我們拖動一個圖片到另一個地方的時候，我們是不能“直接把圖片拖拽進去”的，也就是說，我們還是要通過以下的思路實現拖放：
在被放置的元素中取得被拖拽元素的相關數據（如id），然后通過appendChild之類的API實現添加被拖拽的元素，從而模擬整個拖拽的過程
也就是說， 拖拽其實可分為三個過程： 拖動—傳遞被拖動元素的數據（如id）—在容器元素中添加該元素
關鍵在于如何在被拖動元素和被放置元素中傳遞數據，這可以通過event.dataTransfer對象來實現
dataTransfer可以通過setData方法添加拖動數據，并通過getDate方法取得拖動數據，我們可以在
ondragstart事件和ondrop事件中調用這兩個方法， 實現關鍵性的數據傳遞。
具體請看下面的例子：
拖拽前
拖拽后
參考資料：
HTML5-MDN https://developer.mozilla.org/zh-CN/docs/Web/Guide/HTML/HTML5
【完】
TML5不僅擁有強大的應用功能和廣泛的使用范圍，而且它的學習門檻也比Java、C++、Javascript等語言低很多，可以說是非常適合作為零基礎小白打開IT世界大門的第一把鑰匙！
接下來，小編就和大家一起來了解一下，到底什么是HTML5？它究竟好在哪？
HTML5是什么
從技術層面來說，HTML5就是HTML5+CSS3+JS的合集。HTML5用于實現我們能夠看到的所有網站，是包含一定特效的移動端營銷網頁，簡單概括，就是用代碼實現一張由設計師設計好的網頁圖片。HTML5做出的作品也會被稱為場景應用，有些作品與移動端PPT類似。經常能見到的形式就是滑動翻頁。
HTML5的基本組成
HTML5=HTML+CSS+JavaScript
HTML指的是結構，使整個網頁中有標題，有列表，有圖片等。
CSS指樣式，也就是標題文字的字體大小、顏色、字體；圖片的大??；某個塊的背景色或背景圖等
JS即JavaScript，指的是行為，例如在網頁上四處飄動的廣告；圖片滾動；瀏覽淘寶時鼠標移動到商品時，放大商品的效果等。
如果說HTML是人體的骨架，CSS就好比人體的血肉架，JavaScript就好比人的各類動作，這些合在一起基本就是前端工程師的基本要求了。
HTML5未來發展前景
HTML5作為移動互聯網的行業新貴，它的快速發展撼動著Android和iOS在應用層面的地位。
由于HTML5的富媒體化與富應用化，目前還沒有一門前端的開發語言能取代HTML5的主流開發地位，無論做PC端網站還是App應用，前端樣式均由HTML5開發，毫無疑問，未來幾年，HTML5依然會是Web應用的最佳解決方案，就業前景十分廣闊。
免責聲明：內容和圖片源自網絡，版權歸原作者所有，如有侵犯您的原創版權請告知，我們將盡快刪除相關內容。
IT行業、互聯網、開發語言（Java、前端HTML5、Python、UI/UE、云計算、自動化測試、大數據、人工智能、物聯網、游戲開發、網絡安全、GO語言、PHP）相關資訊，大連千鋒會第一時間送到大家身邊，也可以關注微信公眾號【dalianqianfengjiaoyu】了解相關行業資訊。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
