2014第2週一

2014第2週一
今天過來發現findbugs檢測報錯對long[] ids對象不能直接調用ids.toString 方法,而是要調用Arrays.toString(ids)操做 。學習liang
解析前端,我想須要回答以下幾個問題.
1.前端涉及幾種技術?分別是作什麼的?
2.在前端內部各類技術之間如何整合協做?
3.前端如何和後臺交流?
  1. HTTP:一切內容經過HTTP請求得到
  2. HTML:瀏覽器把HTML解析成DOM樹
  3. CSS:定義HTML的佈局和樣式
  4. JavaScript:提供計算能力,處理交互事件
  5. Cookie:網頁間,請求間會話保持(JS能夠操做Cookie)
  6. DHTML:JavaScript操做Dom樹(包括CSS)
  7. AJAX:JavaScript操縱HTTP
爲何會有DHTML?
咱們瞭解Http,HTML,CSS,JS的協做關係,知道DOM樹是一切的依託,咱們纔會想到經過改變DOM樹來操縱網頁內的一切.

爲何會有Ajax?
咱們瞭解DHTML的能力,殊不知道其用武之地,後來咱們想到依靠服務端指導.接下來咱們又知道全部服務端內容都是經過Http得到,天然咱們須要JavaScript可以操做的Http對象.

這些問題須要前端開發去發現,去解決.雖然你們都在跟着先賢們的步子走,不多能成爲領域的開拓者,可是否瞭解整個前端技術體系的區別是你是不是在盲目跟風. 區別是當一項新技術出現的時候是否能發現其解決的核心問題以及爲解決問題付出的額外代價.

引入新技術的須要付出的額外代價是我要強調的另外一個重點,使用DHTML的代價是什麼,嚴重依賴Ajax的代價又是什麼?瞭解這些而後咱們才能更好的權衡要不要使用.
前端的發展依然在繼續,遇到什麼問題?如何解決?
  • Cookie容量小,每次隨Http發送,是否經過JS在客戶端存儲更多數據? -- LocalStorage
  • JS單線程,可否讓JS進行大量計算的時候,頁面再也不掛起? -- WebWorkers
  • JS語言過於隨意,依賴繁雜,如何組織代碼能方便共享智慧? -- CommonJS Modules
  • Http無狀態短鏈接,可否讓客戶端更及時收到服務端消息? -- 各類Comet
  • Http頭較大沒法壓縮,沒法一個請求返回多個數據對象,怎麼辦? -- 使用SPDY協議

  • 解決問題付出什麼代價?是否涵蓋了全部經常使用瀏覽器,若是不能是否作到了漸進加強?咱們要不要這樣作?這些是作一名合格的前端,作一名對技術架構有影響力的前端,必然面對的問題.
    "Node.js 是服務器端的 JavaScript 運行環境,它具備無阻塞(non-blocking)事件驅動(event-driven)等的特點,Node.js 採用 V8 引擎,一樣,Node.js 實現了相似 Apachenginx 的web服務,讓你能夠經過它來搭建基於 JavaScript 的 Web App。"

    我想不只僅是NodeJS,當咱們要引入任何一種新技術前都必需要搞清楚幾個問題:
    1.咱們遇到了什麼問題?
    2.這項新技術解決什麼問題,是否契合咱們遇到的問題?
    3.咱們遇到問題的多種解決方案中,當前這項新技術的優點體如今哪兒?
    4.使用新技術,帶來哪些新問題,嚴重麼,咱們可否解決掉?

    咱們的問題:Server端阻塞

    如何解決阻塞問題
    解決這個問題的辦法是,創建一種事件機制,發起查詢請求以後,當即將進程交出,當數據返回後觸發事件,再繼續處理數據:

    爲何JS適合解決阻塞問題
    首先JavaScript是一種 函數式編程語言,函數編程語言最重要的數學基礎是 λ演算(lambda calculus) -- 即函數能夠接受函數看成輸入(參數)和輸出(返回值).
    函數能夠做爲其餘函數的參數輸入的這個特性,使得爲事件指定回調函數變得很容易.特別是JavaScript還支持匿名函數
    還有一個關鍵問題是,異步回調的運行上下文保持(稱狀態保持),
    其實在複雜的應用中,咱們必定會遇到這類場景.即在函數運行時須要訪問函數定義時的上下文數據( 注意:必定要區分函數定義時和函數運行時這樣的字眼和其表明的意義,否則很快就會糊塗).而在異步編程中,函數的定義和運行又分處不一樣的時間段,那麼保持上下文的問題變得更加突出了.
    不少人以爲閉包很難理解,其實咱們只要能明確須要區分函數定義和函數運行這兩個時機,記住 閉包讓函數在運行時可以訪問到函數定義時的所處做用域內的全部變量.或者說 函數定義時能訪問到什麼變量,那麼在函數運行時經過相同的變量名同樣能訪問到.

    咱們看到經過JavaScript函數式語言特性,匿名函數支持和閉包很漂亮的解決了同步編程到異步編程轉化過程當中遇到的一系列最重要的問題.但JavaScript是否就是最好的?這就要回答咱們引用新技術時須要考慮的最後一個問題了
    使用NodeJS是否帶來額外的困擾,如何解決
    性能真的是最好麼?不用比較咱們也能夠獲得結論NodeJS,作無阻塞編程性能較難作到極致.何爲極致,處理一個請求須要佔用多少內存,多少cpu資源,多少帶寬,若是有浪費就不是極致.阻塞式編程浪費了大量進程資源只是在等待,致使大量內存和cpu的浪費.NodeJs好不少,但也正是由於一些閉包等JS內建機制也會致使資源的浪費
    因此我來不負責任的預測一下,性能極端苛刻的場景,無阻塞是將來,但無阻塞發展下去,或者有更輕量的腳本引擎產生(lua?),或者V8JS引擎可能要調整能夠disable閉包,或者咱們能夠經過給JS開發靜態編譯器在代碼發佈前優化咱們的代碼.

    NodeJS還要解決什麼問題
    說了這麼多,無阻塞編程要作的還遠不止這些.首先須要一個高效的JS引擎,高效的事件池和線程池.另外幾乎全部和NodeJS交互的傳統模塊如文件系統,數據訪問,HTTP解析,DNS解析都是阻塞式的,都須要額外改造.
    正是NodeJS做者極其團隊,認清問題問題以及JS解決這些問題方面的優點.基於高效的V8 JavaScript引擎,貢獻了大量的智慧和精力解決上述大部分問題後纔有NodeJS橫空出世.
     
       


    相關文章
    相關標籤/搜索