整合營銷服務商

          電腦端+手機端+微信端=數據同步管理

          免費咨詢熱線:

          Java企業級項目的模塊劃分與代碼架構思路

          Java企業級項目的模塊劃分與代碼架構思路

          、模塊劃分

          (一)基于功能特性

          1. 用戶管理模塊:負責用戶的注冊、登錄、信息管理、權限分配等功能。例如:用戶信息的錄入、驗證用戶登錄憑證、更新用戶角色和權限等。
          2. 產品管理模塊:處理與產品相關的業務邏輯,如產品的添加、查詢、修改、刪除,以及產品的分類、庫存管理等。比如:產品信息的存儲與檢索、產品庫存數量的增減、產品分類的維護等。
          3. 訂單管理模塊:管理訂單的生成、處理、跟蹤和結算等功能。像訂單的創建、訂單狀態的更新(如待支付、已支付、已發貨、已完成等)、訂單的查詢與統計等。

          (二)基于業務流程

          1. 銷售業務模塊:涵蓋從客戶線索獲取、銷售機會管理、報價、合同簽訂到銷售訂單生成的整個銷售流程。例如:客戶線索的收集與分配、銷售機會的評估與跟進、合同的生成與審批等。
          2. 采購業務模塊:負責采購計劃制定、供應商管理、采購訂單生成與執行、采購入庫等采購相關業務。比如:供應商信息的維護、采購申請的審批、采購訂單的下達與跟蹤等。

          (三)基于技術架構

          1. 前端模塊:包含與用戶界面相關的代碼,如 HTML、CSS、JavaScript 等用于構建 Web 應用的前端頁面。例如使用 Vue.js 或 React 框架構建的前端應用代碼。
          2. 后端服務模塊:實現業務邏輯和數據處理的后端代碼,如使用 Java Spring Boot 框架開發的服務端應用。像控制器(Controller)、服務(Service)、數據訪問對象(DAO)等相關代碼。
          3. 數據庫模塊:涉及數據庫的設計、創建、數據遷移腳本,以及數據庫連接配置和數據持久化相關的代碼。比如數據庫表結構的定義(SQL 腳本)、數據訪問層(Data Access Layer,DAL)的代碼等。

          二、代碼架構

          (一)分層結構

          1. controller 層(控制器層):用于處理 HTTP 請求和響應,將請求路由到相應的服務層方法,并將服務層返回的結果轉換為合適的響應格式。示例:UserController.java 用于處理與用戶相關的請求,ProductController.java 用于處理與產品相關的請求。
          2. service 層(服務層):實現業務邏輯,調用數據訪問層方法進行數據操作,并對業務流程進行控制和協調。例如:UserService.java 提供用戶相關的業務邏輯實現,如用戶注冊、登錄驗證等;ProductService.java 實現產品相關的業務邏輯,如產品添加、查詢等。
          3. repository 層或者dao層(數據訪問對象層):負責與數據庫進行交互,執行數據的增刪改查操作。比如:UserDao.java 用于對用戶表進行數據操作,ProductDao.java 用于對產品表進行數據操作。
          4. model 層(實體層):定義與數據庫表對應的實體類,用于表示數據對象。例如:User.java 對應用戶表的實體類,Product.java 對應產品表的實體類。
          5. utils 層(工具類層):存放一些通用的工具類,如日期處理、字符串處理、加密解密等工具類。像 DateUtils.java 用于日期相關的處理,StringUtils.java 用于字符串的操作。



          (二)按照模塊劃分目錄

          1. 在項目根目錄下,根據模塊創建相應的子目錄如 user 模塊目錄,product 模塊目錄,order 模塊目錄等。
          2. 每個模塊目錄下,按照分層結構組織代碼以 user 模塊為例,目錄結構可能為:user/controller/UserController.javauser/service/UserService.javauser/repository/UserDao.javauser/model/User.java

          者 | 敘帝利

          鏈接 | www.cnblogs.com/nzbin/p/7073601.html

          前言

          這篇文章我已經醞釀了半年之久,或者說拖沓了這么久吧。想說的東西很多,卻又無從說起。如今輕量級框架如雨后春筍,層出不窮。我想每個人都應該歸納總結工作中的常見需求,編寫一套適合自己的 CSS 框架。

          在之前的文章中,我提到了面向對象的 CSS(比如 BEM、OOCSS、SMACSS,詳見 http://vanseodesign.com/css/dry-principles/)。這是一種思想,并不涉及具體的 CSS 問題,主要是類命名的策略!現在仍然有很多人對于前端框架的認識還停留在表面,認為 Bootstrap 是后端人員專用,前端沒必要等等。

          我不知道這種說法從何而來,我最開始也不喜歡使用框架,或許和很多人的想法一樣,畏懼新知識、害怕難以駕馭、遇到問題的時候無法解決等等。最關鍵的一點是很多人認為框架的樣式是固定的,修改起來太麻煩,還不如自己根據設計圖寫起來方便。

          為什么使用框架

          為什么使用框架?答案顯而易見,效率。除此之外,使用框架或者研究框架的意義還有很多,比如面向對象思想的具體實現。在上一家公司工作的時候,開始的幾個項目我也是用最原始的方法書寫 CSS 。項目之中最讓我頭疼的就是類的命名。我想大多數人都是根據功能去命名,這就造成了很多的冗余,相同的組件可能寫很多次。簡單舉一個例子,如下圖,個人中心的登錄界面。

          很多人包括我剛開始的時候可能會選擇下面的類命名及布局方式,其通用性非常差:

          <div class="login-area"> <div class="login-img"> <img src="..." /> </div> <div class="login-text"> <a href="...">請點擊登錄</a> </div></div>

          然而了解 Bootstrap 的人應該一眼就發現上圖就是一個 media 對象,無非一些小細節需要調整一下:

          <div class="media"> <div class="media-left"> <img src="..." /> </div> <div class="media-body media-middle"> <a href="...">請點擊登錄</a> </div></div>

          為了讓文字與圖片居中對齊,我們可以使用 Bootstrap 的.media-middle的輔助類。如果在工作中還要根據需求自定義一些輔助類調整細節,當然這是一個移動端的例子,可以選擇移動端框架相關的 media 對象。

          另外,在項目改版的時候,原始的方法的修改更是慘不忍睹,可以說是噩夢,冗長的 CSS 文件、混亂的功能劃分、類名、色值等等。最后也只能硬著頭皮一點一點修改。那一刻我才體會到框架的意義以及前端工具的重要性。我從工作中總結出,要么你可以熟練的使用某一個框架,要么就自己實現一個框架

          前端框架對比

          目前市面上前端框架主要分重量級與輕量級。重量級主要有 Bootstrap、Semantic、UIkit、Foundation 等,輕量級有 Pure、Skeleton、Miligram 等。經常關注前端動態的工程師會發現輕量級框架每年都層出不窮。在我上面提到的主流輕量級框架之外還有很多類似的框架。

          我一直問自己,為什么要重復造輪子。經過研究,我發現這些輕量級框架其實大多都不能勝任工作需求,而且模仿的痕跡很重,基本上都或多或少的有 Bootstrap 的影子。那么這些輕量級框架有沒有意義呢?當然有。但是就我個人觀點,選擇輕量級框架反倒不如自己實現一個框架。因為大多輕量級框架就像是工作總結,是根據自己的業務需求實現的。所以大多不具有通用性。

          前端框架的對比主要以 Bootstrap、Semantic、UIkit 為主,因為我個人感覺這三個最具有代表性,而且設計風格各有特色。Foundation 也有很多大公司在用,但以我個人觀點,無論是框架的易用性還是設計風格,相比其它幾個框架稍遜一籌。

          其中 Bootstrap 和 Semantic 是面向對象的最好體現。

          我先說一下 Bootstrap 的優勢,不是設計風格,不是模塊,不是特效,而是柵格,響應式柵格。Bootstrap 的柵格在與其它框架對比中占有絕對優勢,無論是柵格的劃分還是類名的風格都堪稱經典。如果讀者有心看一下 Bootstrap 的 Less 源文件,就會感受到 Bootstrap 對于響應式柵格的獨具匠心。其實在 Bootstrap 之前也有很多柵格方案,但是給人的感覺就是不夠利索,類名繁瑣不好記。而后來的很多框架,尤其輕量級的框架大多都有 Bootstrap 的影子。

          下面我們通過對比幾個框架的柵格和按鈕來看一下類命名的策略。

          Bootstrap

          <div class="row"> <div class="col-md-8"></div> <div class="col-md-4"></div></div><button class="btn btn-primary" type="submit">Button</button>

          Semantic

          <div class="ui grid"> <div class="ten wide column"></div> <div class="six wide column"></div></div>

          <button class="ui primary basic button">Primary</button>

          Foundation

          <div class="row"> <div class="small-3 columns"></div> <div class="small-9 columns"></div></div>

          <button type="button" class="primary button">Primary</button>

          UIkit

          <div class="uk-grid"> <div class="uk-width-1-2"></div> <div class="uk-width-1-2"></div></div>

          <button class="uk-button uk-button-primary" type="button">Primary</button>

          Pure

          <div class="pure-g"> <div class="pure-u-1-2"></div> <div class="pure-u-1-2"></div></div>

          <button class="pure-button pure-button-primary">A Primary Button</button>

          通過上面的對比,大家應該已經發現了這些框架的命名策略的不同。不可否認,Bootstrap 的命名最經典。

          之前在網上看到有人討論關于框架的易用性,有人說 Bootstrap 的類名太長,然而通過上面幾個框架的對比,Bootstrap 的類并不繁瑣,而且用預處理器編寫框架時嵌套會比較靈活。

          Semantic 的類名最簡潔,通過多個定語的修飾組成一句話,確實很有意思。但是過多的修飾類在編寫框架時會稍顯凌亂,有利有弊,因人而異吧。

          Foundation 的柵格應該是最豐富的,策略上類似 Bootstrap,只是對公共屬性進行了拆分,大家也可以看看其中的具體細節。

          UIkit 和 Pure 的策略相同,都加了前綴以區分其它框架,但是很顯然類名過于冗長了。我在編寫框架時也這樣想過,但是最終放棄了這種方式。

          關于 CSS 預處理器

          CSS 預處理器早已不是什么新鮮事,但是真正能夠在工作中運用的人有多少呢?熟練使用預處理器特性的人又有多少呢?

          我之前工作的時候也沒有用預處理器,因為不用,所以也意識不到預處理器的好處。主要是覺得麻煩,因為要使用編譯器編譯一下,還不如直接寫 CSS 方便。但是在項目維護的時候就意識到預處理器的好處。

          后來在幾個項目中嘗試了預處理器,但是對于模塊化的寫法不太明確。預處理器作為工具,可以實現模塊化編寫 CSS,那么應該如何劃分模塊?另外,預處理器有很多特性,但是大多數人剛開始只用到變量和嵌套,其它的特性幾乎很少用到。我相信在自己動手實現一個輕量級框架的過程中,我們可以對預處理器有一個全面的了解。

          目前流行的預處理器有 Less,Sass,Stylus 三個,選擇哪個完全是看自己的習慣。我最開始因為 Bootstrap 了解的 Less,但是因為習慣選擇了 Sass,其次 Sass 的功能要更全面一些。

          無論是工作還是自己寫項目,都要搭建一個項目環境,也就是安裝一系列的 npm 包。相比刀耕火種的開發方式,使用工具開發的前期準備過程稍顯麻煩,然而一旦環境建好,后期的開發將會游刃有余。

          Miligram 這個輕量級框架在 Github 上有很高人氣,但是說實話,用處并不大。不過這個框架的構建方式非常值得學習。雖然 CSS 對于很多人來說很簡單,但是真要去寫一個框架,還是非常棘手,這時候就需要借鑒一些優秀的框架。

          編寫框架大致會用到的 npm 如下:

          --autoprefixer--node-sass--npm-run-all--rimraf--onchange

          其實最主要的就是一個 node-sass,其它的都是輔助 CSS 文件的生成修改,大家感興趣的話可以去 npm 官網搜索這些插件,了解具體用法,如有不懂可以給我留言,我就不啰嗦了。

          編寫輕量級框架

          終于到了本篇文章的重頭戲。

          簡單介紹一下,我給自己編寫的框架取名 Snack,原意“快餐”,主要表達簡單之意。雖然是輕量級框架,但我并不想拿輕量級做為噱頭,畢竟體量輕意味著某些功能的缺失以及疏漏。這個框架的意義更多的是交流學習,我試圖借鑒其它框架的優秀之處,盡量簡化類名,以及嘗試探索一些更通用的組件。

          大多數的輕量級框架只是 CSS 框架,不涉及 JS 部分,主要用于網頁的布局。我之所以打算自己編寫框架,是因為工作中重復的東西太多,通過框架可以很好的將這些零散組件整合到一起。另一方面,寫個小項目,學點新知識是一件趣事。

          編寫框架是去年想做的事情,但因為時間原因,拖了很久。寫框架之初我曾陷入一個誤區,我打算設計一些比較前衛的樣式,立體的按鈕、浮動的面板等,比如下圖中的風格。

          https://dribbble.com/shots/524593-Soft-Interface-Black

          但是在斷斷續續編寫框架的過程中,我逐漸找到了方向,上圖的樣式只是一種皮膚,編寫框架之初不應該把重點放在這上面。當然,好的 UI 設計也是框架成功的一部分。

          模塊劃分

          編寫框架的第一步就是要確定框架應該包含哪些模塊。因為是輕量級框架,所以模塊肯定沒有重量級框架那么全面,只有核心的一些組件。通過比較一些輕量級框架以及工作總結,大致常用的模塊包括柵格、媒體、按鈕、排版、表單、表格、面板以及輔助工具。

          在常用的這幾個組件中,需要重點關注的是柵格、表單及面板,媒體組件也很重要,但是自由發揮的空間不大,我直接用了 Bootstrap 的媒體組件。

          命名策略

          首先是類命名的層次與結構。類命名一直是我比較糾結的地方,剛開始工作的時候為了起一個見名知意又簡潔的類名總是抓耳撓腮。我在編寫框架時盡量避免與 Bootstrap 的類名重疊,但也不能完全避免。對比其他框架會發現,這種情況不可避免的會出現,畢竟類名會有一定的規律性以及層次性。在這一點上我比較喜歡 Bootstrap 的風格。下面和 Bootstrap 的表單做一個對比。

          Bootstrap 的表單結構及類名

          --div.form-horizontal --div.form-group --label.control-label --input.form-control

          Snack 的表單結構及類名

          --div.form-row --div.form-item --label.form-label --input.form-field

          這個表單結構整體而言還算不錯,只是個別地方需要修改。有一些框架不給input等元素起類名,而是給父元素一個類名,個人對這種做法表示疑問,不起類名會降低框架編寫及使用的靈活性。

          第二個策略是組件的修飾,比如按鈕及面板都存在多個語境(顏色、大小等),在這一點上我編寫框架時做了一些簡化,風格上有些 Semantic 的影子。

          <button class="btn primary">primary</button><table class="table bordered striped">...</table><div class="boxes primary">...</div>

          關于修飾類的策略是一個仁者見仁智者見智的問題,至于哪種方法更好,還需要在編寫框架的過程中摸索。

          柵格系統

          演示示例: https://nzbin.github.io/snack/#grid

          任何框架必須建立在柵格的基礎上才能靈活布局。我在前面提到了 Bootstrap 的精華就是柵格系統。柵格系統的編寫需要使用預處理器的循環功能,否則就要做無謂的重復勞動了。我遇到過一些輕量級框架是用 Less 編寫的,其柵格系統就沒有用循環,這樣的源碼稍顯唐突,可能是作者對 Less 的循環功能不熟,當然 Less 本身的循環比較弱,用起來有些別扭。

          關于預處理器的循環,可以參照我之前翻譯的 《CSS 預處理器中的循環》,比較詳細地對比了三種流行預處理器的循環功能。簡單說一下,Less 沒有循環,但可以用遞歸實現,而 Sass 和 Stylus 有真循環。

          我編寫的柵格系統也是默認 12 列,但是后來發現 12 列的柵格缺少最常用的列寬(比如 10%、20%、30%等),比如下面 CodePen 展示的例子用 12 列柵格是無法完成的,所以我又添加了 10 列柵格,但仍然無法面面俱到,不過已經很靈活了。

          柵格的使用和 Bootstrap 是一樣的,除了 12 列柵格外,10 列柵格以及均分柵格都要添加.cols-

          <!-- 默認 12 列柵格,所以省略 cols-12 --><div class="row"> <div class="col-5"></div> <div class="col-7"></div></div>

          <!-- 10 列柵格 --><div class="row cols-10"> <div class="col-3"></div> <div class="col-7"></div></div>

          這個柵格并沒有響應式,只有一個斷點,小屏手機上的話所有柵格都會單行顯示。一方面,這樣的設計符合大多數輕量級框架的初衷;另一方面,我打算再寫一個針對移動端的框架,畢竟 Web 端和移動端的風格差距較大,按照業務需求分開會更好。不過最近我更改了源文件,為響應式預留了擴展方式。

          表單

          演示示例: https://nzbin.github.io/snack/#forms

          在上面的命名策略中已經展示了 Snack 表單的基本結構,基本表單除了結構之外,樣式上并沒有太多可以討論的地方。在此說一下表單中checkbox的結構調整,先看一下 Bootstrap 的checkbox結構。

          <!-- checkbox --><div class="checkbox"> <label> <input type="checkbox" value=""> checkbox </label></div>
          <!-- checkbox-inline --><label class="checkbox-inline"> <input type="checkbox" id="inlineCheckbox1" value="option1"> checkbox</label>

          以上兩種結構不能有偏差,稍有偏差樣式就會錯亂,靈活性較差。其次我在想兩種結構能不能整合在一起,增強靈活性。想了很久,找到了方法,Snack 結構如下:

          <!-- checkbox --><div class="checkbox"> <label> <input type="checkbox" value=""> checkbox </label></div>
          <!-- checkbox-inline --><div class="checkbox inline"> <label> <input type="checkbox" value=""> checkbox </label></div>

          也可以將樣式直接加到label標簽上。另外,如果將input移到label標簽外也是沒有問題的,如下:

          <!-- checkbox --><div class="checkbox"> <input type="checkbox" id="checkbox1" value=""> <label for="checkbox1">checkbox</label></div>
          <!-- checkbox-inline --><div class="checkbox inline"> <input type="checkbox" id="inlineCheckbox1" value=""> <label for="inlineCheckbox1">checkbox</label></div>

          這種結構有一個好處,就是可以自定義input樣式,詳見下面的 CodePen 的scss文件。radio的設置和checkBox是一樣的。

          輔助類

          輔助類是一系列類的組合,比如字號大小、顏色值、padding、margin 以及左右浮動等。在一些 Bootstrap 搭建的后臺管理系統中尤為常見,這樣布局起來就會比較靈活。以下是一個邊框的輔助類。

          .border-left-right { border-left: 1px solid #eee; border-right: 1px solid #eee;}.border-top-bottom { border-top: 1px solid #eee; border-bottom: 1px solid #eee;}.border-left { border-left: 1px solid #eee;}.border-right { border-right: 1px solid #eee;}.border-top { border-top: 1px solid #eee;}.border-bottom { border-bottom: 1px solid #eee;}

          關于助類的更多內容可以搜索閱讀這篇文章《如何編寫通用的 Helper Class》

          盒組件

          演示示例: https://nzbin.github.io/snack/#boxes

          盒組件是我整個框架中比較滿意的一個模塊。之所以要做這個組件主要是覺得 Bootstrap 的 list 組件和 panel 組件可以整合到一起。當然,這樣的做法有利有弊。盒組件在后臺管理系統的布局中表現的尤為突出。

          其命名也是多種多樣,比如 panel、widget、portlet、ibox、card等,每個后臺管理系統框架都會對這個組件進行深度開發,可見其在布局上的重要性。給一個組件起一個合適的類名也很關鍵,想了很久,最后用了box的類名,當然一般情況下盡量不要用box,因為這個類名比較寬泛。下面的 CodePen 模擬了 Bootstrap 的 list 及 panel 組件。

          主題

          給框架添加主題是一件有趣的事情。Snack 的默認主題是白色,因為喜歡黑色,最后添加了暗夜主題,編寫主題只需改變組件的顏色。演示文檔 的頁面用了暗夜主題,點擊上方的紅色按鈕可以切換主題。

          總結

          如果大家問我那個框架更好,我會毫不猶豫的選擇 Bootstrap。在工作中可以根據需求的難易進行框架選擇,如果業務比較重,最好根據 Bootstrap 進行二次開發;反之,可以選擇一些輕量級框架,最好還是根據自己的需求造輪子,如果大家愿意選擇或是借鑒我的框架,那會是我的榮幸。

          Github: https://github.com/nzbin/snack

          Docs: https://nzbin.github.io/snack

          eb前端技術由html、css和 javascript三大部分構成,是一個龐大而復雜的技術體系,其復雜程度不低于任何一門后端語言。而我們在學習它的時候往往是先從某一個點切入,然后不斷地接觸和學習新的知識點,因此對于初學者很難理清楚整個體系的脈絡結構。本文將對Web前端知識體系進行簡單的梳理,對應的每個知識點點到為止,不作詳細介紹。目的是幫助大家審查自己的知識結構是否完善,如有遺漏或不正確的地方,希望共勉。

          HTML 篇

          1、BOM

          BOM 是 Browser Object Model

          的縮寫,即瀏覽器對象模型,當一個瀏覽器頁面初始化時,會在內存創建一個全局的對象,用以描述當前窗口的屬性和狀態,這個全局對象被稱為瀏覽器對象模型,即BOM。BOM的核心對象就是window,window

          對象也是BOM的頂級對象,其中包含了瀏覽器的 6個核心模塊:

          document -

          即文檔對象,渲染引擎在解析HTML代碼時,會為每一個元素生成對應的DOM對象,由于元素之間有層級關系,因此整個HTML代碼解析完以后,會生成一個由不同節點組成的樹形結構,俗稱DOM樹,document

          用于描述DOM樹的狀態和屬性,并提供了很多操作DOM的API。

          frames - HTML 子框架,即在瀏覽器里嵌入另一個窗口,父框架和子框架擁有獨立的作用域和上下文。

          history - 以棧(FIFO)的形式保存著頁面被訪問的歷史記錄,頁面前進即入棧,頁面返回即出棧。

          location - 提供了當前窗口中加載的文檔相關信息以及一些導航功能。

          navigator - 用來描述瀏覽器本身,包括瀏覽器的名稱、版本、語言、系統平臺、用戶特性字符串等信息。

          screen - 提供了瀏覽器顯示屏幕的相關屬性,比如顯示屏幕的寬度和高度,可用寬度和高度。

          2、DOM 系統

          DOM 是 Document Object Model 的縮寫,即 文檔對象模型,是所有瀏覽器公共遵守的標準,DOM

          將HTML和XML文檔映射成一個由不同節點組成的樹型結構,俗稱DOM樹。其核心對象是document,用于描述DOM樹的狀態和屬性,并提供對應的DOM操作API。隨著歷史的發展,DOM

          被劃分為1級、2級、3級,共3個級別:

          1級DOM - 在1998年10月份成為W3C的提議,由DOM核心與DOM

          HTML兩個模塊組成。DOM核心能映射以XML為基礎的文檔結構,允許獲取和操作文檔的任意部分。DOM

          HTML通過添加HTML專用的對象與函數對DOM核心進行了擴展。

          2級DOM - 鑒于1級DOM僅以映射文檔結構為目標,DOM

          2級面向更為寬廣。通過對原有DOM的擴展,2級DOM通過對象接口增加了對鼠標和用戶界面事件(DHTML長期支持鼠標與用戶界面事件)、范圍、遍歷(重復執行DOM文檔)和層疊樣式表(CSS)的支持。同時也對DOM

          1的核心進行了擴展,從而可支持XML命名空間。

          3級DOM -

          通過引入統一方式載入和保存文檔和文檔驗證方法對DOM進行進一步擴展,DOM3包含一個名為“DOM載入與保存”的新模塊,DOM核心擴展后可支持XML1.0的所有內容,包括XML

          Infoset、 XPath、和XML Base。

          瀏覽器對不同級別DOM的支持情況如下所示:

          從圖中可以看出,移動端常用的 webkit 內核瀏覽器目前只支持DOM2,而不支持DOM3 。

          新手福利獲取方式:

          1.在你手機的右上角有【關注】選項,或點擊我的頭像,點擊關注!(關注我)

          2.關注后,手機客戶端點擊我的主頁面,右上角有私信,請私信發我:html

          其實作為一個開發者,有一個學習的氛圍跟一個交流圈子特別重要這里請私信我“html”不管你是小白還是大牛歡迎入住大家一起交流成長。小編會在里面不定期分享干貨源碼,包括我精心整理的一份零基礎教程。歡迎各位感興趣的的小伙伴。

          學習思路:

          3、事件系統

          事件是用戶與頁面交互的基礎,到目前為止,DOM事件從PC端的 鼠標事件(mouse) 發展到了 移動端的 觸摸事件(touch) 和

          手勢事件(guesture),touch事件描述了手指在屏幕操作的每一個細節,guesture 則是描述多手指操作時更為復雜的情況,總結如下:

          第一根手指放下,觸發 touchstart,除此之外什么都不會發生

          手指滑動時,觸發touchmove

          第二根手指放下,觸發 gesturestart

          觸發第二根手指的 touchstart

          立即觸發 gesturechange

          任意手指移動,持續觸發 gesturechange

          第二根手指彈起時,觸發 gestureend,以后將不會再觸發 gesturechange

          觸發第二根手指的 touchend

          觸發touchstart (多根手指在屏幕上,提起一根,會刷新一次全局touch) _ ___

          彈起第一根手指,觸發 touchend

          更多關于手勢事件的介紹請參考:

          gesture事件處理復雜手勢

          DOM2.0 模型將事件處理流程分為三個階段,即 事件捕獲階段事件處理階段事件冒泡階段, 如圖所示:

          事件捕獲 :當用戶觸發點擊事件后,頂層對象document 就會發出一個事件流,從最外層的DOM節點向目標元素節點傳遞,最終到達目標元素。

          事件處理 :當到達目標元素之后,執行目標元素綁定的處理函數。如果沒有綁定監聽函數,則不做任何處理。

          事件冒泡 :事件流從目標元素開始,向最外層DOM節點傳遞,途中如果有節點綁定了事件處理函數,這些函數就會被執行。

          利用事件冒泡原理可以實現 事件委托

          ,所謂事件委托,就是在父元素上添加事件監聽器,用以監聽和處理子元素的事件,避免重復為子元素綁定相同的事件。當目標元素的事件被觸發以后,這個事件就從目標元素開始,向最外層元素傳遞,最終冒泡到父元素上,父元素再通過event.target

          獲取到這個目標元素,這樣做的好處是,父元素只需綁定一個事件監聽,就可以對所有子元素的事件進行處理了,從而減少了不必要的事件綁定,對頁面性能有一定的提升。

          4、HTML解析過程

          瀏覽器加載 html 文件以后,渲染引擎會從上往下,一步步來解析HTML標簽,大致過程如下:

          用戶輸入網址,瀏覽器向服務器發出請求,服務器返回html文件;

          渲染引擎開始解析 html 標簽,并將標簽轉化為DOM節點,生成 DOM樹;

          如果head 標簽中引用了外部css文件,則發出css文件請求,服務器返回該文件,該過程會阻塞后面的解析;

          如果引用了外部 js 文件,則發出 js 文件請求,服務器返回后立即執行該腳本,這個過程也會阻塞html的解析;

          引擎開始解析 body 里面的內容,如果標簽里引用了css 樣式,就需要解析剛才下載好的css文件,然后用css來設置標簽的樣式屬性,并生成渲染樹;

          如果 body 中的 img 標簽引用了圖片資源,則立即向服務器發出請求,此時引擎不會等待圖片下載完畢,而是繼續解析后面的標簽;

          服務器返回圖片文件,由于圖片需要占用一定的空間,會影響到后面元素的排版,因此引擎需要重新渲染這部分內容;

          如果此時 js 腳本中運行了 style.display="none",布局被改變,引擎也需要重新渲染這部分代碼;

          直到 html 結束標簽為止,頁面解析完畢。

          5、重繪 和 回流

          當渲染樹中的一部分(或全部)因為元素的規模尺寸,布局,隱藏等改變而需要重新構建。這就稱為回流。比如上面的img文件加載完成后就會引起回流,每個頁面至少需要一次回流,就是在頁面第一次加載的時候。

          當渲染樹中的一些元素需要更新屬性,而這些屬性只是影響元素的外觀,風格,而不會影響布局的,比如 background-color。則就叫稱為重繪。

          從上面可以看出,回流必將引起重繪,而重繪不一定會引起回流。會引起重繪和回流的操作如下:

          添加、刪除元素(回流+重繪)

          隱藏元素,display:none(回流+重繪),visibility:hidden(只重繪,不回流)

          移動元素,比如改變top,left的值,或者移動元素到另外一個父元素中。(重繪+回流)

          對style的操作(對不同的屬性操作,影響不一樣)

          還有一種是用戶的操作,比如改變瀏覽器大小,改變瀏覽器的字體大小等(回流+重繪)

          另外,transform

          操作不會引起重繪和回流,是一種高效率的渲染。這是因為transform屬于合成屬性,對合成屬性進行transition/animation

          動畫時將會創建一個合成層,這使得動畫元素在一個獨立的層中進行渲染,當元素的內容沒有發生改變,就沒必要進行重繪,瀏覽器會通過重新復合來創建動畫幀。

          6、本地存儲

          本地存儲最原始的方式就是 cookie,cookie 是存放在本地瀏覽器的一段文本,數據以鍵值對的形式保存,可以設置過期時間。 但是 cookie

          不適合大量數據的存儲,因為每請求一次頁面,cookie 都會發送給服務器,這使得 cookie

          速度很慢而且效率也不高。因此cookie的大小被限制為4k左右(不同瀏覽器可能不同,分HOST),如下所示:

          Firefox和Safari允許cookie多達4097個字節,包括名(name)、值(value) 和 等號。

          Opera允許cookie多達4096個字節,包括:名(name)、值(value) 和 等號。

          Internet Explorer允許cookie多達4095個字節,包括:名(name)、值(value) 和 等號。

          在所有瀏覽器中,任何cookie大小超過限制都被忽略,且永遠不會被設置。

          html5 提供了兩種在客戶端存儲數據的新方法:localStorage 和 sessionStorage, 它們都是以key/value

          的形式來存儲數據,前者是永久存儲,后者的存儲期限僅限于瀏覽器會話(session),即當瀏覽器窗口關閉后,sessionStorage中的數據被清除。

          localStorage的存儲空間大約5M左右(不同瀏覽器可能不同,分

          HOST),這個相當于一個5M大小的前端數據庫,相比于cookie,可以節約帶寬,但localStorage在瀏覽器隱私模式下是不可讀取的,當存儲數據超過了localStorage

          的存儲空間后會拋出異常。

          此外,H5還提供了逆天的websql和

          indexedDB,允許前端以關系型數據庫的方式來存儲本地數據,相對來說,這個功能目前應用的場景比較少,此處不作介紹。

          7、瀏覽器緩存機制

          瀏覽器緩存機制是指通過 HTTP 協議頭里的 Cache-Control (或 Expires) 和 Last-Modified (或 Etag)

          等字段來控制文件緩存的機制。

          Cache-Control 用于控制文件在本地緩存有效時長。最常見的,比如服務器回包:Cache-Control:max-age=600

          表示文件在本地應該緩存,且有效時長是600秒 (從發出請求算起)。在接下來600秒內,如果有請求這個資源,瀏覽器不會發出 HTTP

          請求,而是直接使用本地緩存的文件。

          Last-Modified 是標識文件在服務器上的最新更新時間。下次請求時,如果文件緩存過期,瀏覽器通過 If-Modified-Since

          字段帶上這個時間,發送給服務器,由服務器比較時間戳來判斷文件是否有修改。如果沒有修改,服務器返回304告訴瀏覽器繼續使用緩存;如果有修改,則返回200,同時返回最新的文件。

          Cache-Control 通常與 Last-Modified 一起使用。一個用于控制緩存有效時間,一個在緩存失效后,向服務查詢是否有更新。

          Cache-Control 還有一個同功能的字段:Expires。Expires 的值一個絕對的時間點,如:Expires: Thu, 10 Nov

          2015 08:45:11 GMT,表示在這個時間點之前,緩存都是有效的。

          Expires 是 HTTP1.0 標準中的字段,Cache-Control 是 HTTP1.1

          標準中新加的字段,功能一樣,都是控制緩存的有效時間。當這兩個字段同時出現時,Cache-Control 是高優化級的。

          Etag 也是和 Last-Modified 一樣,對文件進行標識的字段。不同的是,Etag

          的取值是一個對文件進行標識的特征字串。在向服務器查詢文件是否有更新時,瀏覽器通過 If-None-Match

          字段把特征字串發送給服務器,由服務器和文件最新特征字串進行匹配,來判斷文件是否有更新。沒有更新回包304,有更新回包200。Etag 和

          Last-Modified 可根據需求使用一個或兩個同時使用。兩個同時使用時,只要滿足基中一個條件,就認為文件沒有更新。

          另外有兩種特殊的情況:

          手動刷新頁面(F5),瀏覽器會直接認為緩存已經過期(可能緩存還沒有過期),在請求中加上字段:Cache-Control:max-age=0,發包向服務器查詢是否有文件是否有更新。

          強制刷新頁面(Ctrl+F5),瀏覽器會直接忽略本地的緩存(有緩存也會認為本地沒有緩存),在請求中加上字段:Cache-Control:no-cache

          (或 Pragma:no-cache),發包向服務重新拉取文件。

          8、History

          用戶訪問網頁的歷史記錄通常會被保存在一個類似于棧的對象中,即history對象,點擊返回就出棧,跳下一頁就入棧。 它提供了以下方法來操作頁面的前進和后退:

          window.history.back( ) 返回到上一個頁面

          window.history.forward( ) 進入到下一個頁面

          window.history.go( [delta] ) 跳轉到指定頁面

          HTML5 對History Api 進行了增強,新增了兩個Api 和一個事件,分別是pushState、replaceState 和

          onpopstate:

          pushState是往history對象里添加一個新的歷史記錄,即壓棧。

          replaceState 是替換history對象中的當前歷史記錄。

          當點擊瀏覽器后退按鈕或 js調用history.back 都會觸發 onpopstate 事件。

          與其類似的還有一個事件:onhashchange,onhashchange是老API,瀏覽器支持度高,本來是用來監聽hash變化的,但可以被利用來做客戶端前進和后退事件的監聽,而onpopstate是專門用來監聽瀏覽器前進后退的,不僅可以支持hash,非hash的同源

          url 也支持。

          9、HTML5離線緩存

          HTML5離線緩存又叫Application

          Cache,是從瀏覽器的緩存中分出來的一塊緩存區,如果要在這個緩存中保存數據,可以使用一個描述文件(manifest file),列出要下載和緩存的資源。

          manifest 文件是簡單的文本文件,它告知瀏覽器被緩存的內容(以及不緩存的內容)。manifest 文件可分為三個部分:

          - CACHE MANIFEST - 在此標題下列出的文件將在首次下載后進行緩存

          - NETWORK - 在此標題下列出的文件需要與服務器的連接,且不會被緩存

          - FALLBACK - 在此標題下列出的文件規定當頁面無法訪問時的回退頁面(比如 404 頁面)

          離線緩存為應用帶來三個優勢:

          離線瀏覽 - 用戶可在應用離線時使用它們

          速度 - 已緩存資源加載得更快

          減少服務器負載 - 瀏覽器將只從服務器下載更新過或更改過的資源。

          10、Web語義化 和 SEO

          Web語義化是指使用語義恰當的標簽,使頁面有良好的結構,頁面元素有含義,能夠讓人和搜索引擎都容易理解。

          SEO是指在了解搜索引擎自然排名機制的基礎之上,對網站進行內部及外部的調整優化,改進網站在搜索引擎中關鍵詞的自然排名,獲得更多的展現量,吸引更多目標客戶點擊訪問網站,從而達到互聯網營銷及品牌建設的目標。

          搜索引擎通過爬蟲技術獲取的頁面就是由一堆 html 標簽組成的代碼,人可以通過可視化的方式來判斷頁面上哪些內容是重點,而機器做不到。

          但搜索引擎會根據標簽的含義來判斷內容的權重,因此,在合適的位置使用恰當的標簽,使整個頁面的語義明確,結構清晰,搜索引擎才能正確識別頁面中的重要內容,并予以較高的權值。比如h1~h6這幾個標簽在SEO中的權值非常高,用它們作頁面的標題就是一個簡單的SEO優化。


          主站蜘蛛池模板: 亚洲av乱码一区二区三区按摩 | 中文字幕人妻AV一区二区| 日本视频一区在线观看免费| 国产一区在线观看免费| 精品国产一区二区三区不卡| 伊人久久大香线蕉av一区| 一区二区三区免费电影| 免费无码一区二区三区蜜桃大| 国产精品高清一区二区三区不卡| 日韩精品在线一区二区| 看电影来5566一区.二区| 亚洲av无码天堂一区二区三区 | 亚洲综合在线一区二区三区| 麻豆AV一区二区三区久久| 国产精品无码一区二区三级| 国产成人无码AV一区二区在线观看 | 少妇激情av一区二区| 免费日本一区二区| 国产AV午夜精品一区二区入口| 亚洲乱码一区二区三区在线观看 | 国产精品被窝福利一区 | 日韩一区二区三区无码影院| 国产成人久久精品一区二区三区 | 国产精品一区电影| 老鸭窝毛片一区二区三区| 成人精品视频一区二区| 成人精品一区久久久久| 在线日韩麻豆一区| 精彩视频一区二区| 国产精品 一区 在线| 日本一区二区三区在线观看 | 中文乱码人妻系列一区二区| 日本高清一区二区三区| 国产一区二区在线|播放| 动漫精品专区一区二区三区不卡| 亚洲日韩国产一区二区三区| 亚洲一区二区三区香蕉| 精品人妻AV一区二区三区| 国产精品一区不卡| 亚洲中文字幕无码一区| 中文字幕av一区|