畢業以前一直在作前端開發，畢業後就轉成作iOS開發，這二者有不少挺有意思的對比，嘗試寫下我能想到的它們的一些相同點和不一樣點。javascript
語言
前端和終端做爲面向用戶端的程序，有個共同特色：須要依賴用戶機器的運行環境，因此開發語言基本上是沒有選擇的，不像後臺想用什麼就用什麼，iOS 只能用object-c，前端只能javascript，固然iOS還能夠用RubyMotion，前端還能用GWT/CoffeeScript，但不是 主流，用的人不多，真正用了也會多出不少麻煩。iOS還能夠用蘋果新出的swift語言，後面可能用於取代object-c，還處於起步階段，先不討論。css
objc和js這二者有個有意思的對比：變量/方法命名的風格正好相反。蘋果一直鼓吹用戶體驗，寫代碼也不例外，程序命名都是用英文全稱而且要多詳 細有多詳細，力求看變量和方法名就能知道是幹嗎的，例如application:didFinishLaunchingWithOptions:。而js 由於每次都要從網絡下載，要力求減小代碼體積，因此變量方法名是儘可能用縮寫，實際上有代碼壓縮工具，不管變量名寫多長最終上線的效果是同樣的，但你們也都 習慣了用短的命名，例如上述objc的application:didFinishLaunchingWithOptions:方法在js裏習慣的命名 是:$()。html
objc與js都是動態語言，使用起來還蠻像，但objc是編譯型，速度快，不少錯誤也能在編譯過程當中被發現，js是解釋型，性能依賴於解釋引擎， 即便在強勁的v8引擎下性能也趕不上編譯型語言，語言太動態，變量徹底沒有類型，寫起來爽，debug起來稍微費點勁。一直感受js輕巧靈活放蕩不羈充滿 各類奇技淫巧，objc中規中矩沒c++ java那麼嚴肅也沒有js那麼靈活。前端
線程
前端開發幾乎不須要線程這個概念，瀏覽器實現上頁面HTML和CSS解析渲染可能與js不在同一個線程，但全部js代碼只執行在一條線程上，不會並 發執行，也就不須要考慮各類併發編程的問題。在新的JS特性中能夠建立worker任務，這樣的任務是能夠另起一條線程並行執行的，但因爲並非全部瀏覽 器都支持，不一樣線程傳遞數據各個標準定的還不同，使用場景也少，彷佛沒有大規模用起來。對於數據庫操做/發送網絡請求這樣的任務是在不一樣於js代碼執行 線程的，不過這些都由瀏覽器管理，前端無需關心也沒法影響這些線程，只需接收事件回調，不須要處理任何併發問題。html5
終端開發須要大量使用多線程，iOS有一條主線程，UI渲染都在這個線程，其餘耗時長的邏輯或者數據庫IO/網絡請求都須要本身另開線程執行，不然 會佔用主線程的時間，致使界面沒法響應用戶交互事件，或者渲染慢致使滾動卡頓。程序邏輯分佈在多個線程裏跑，須要處理好各類代碼併發執行可能帶來的數據不 一致/時序錯亂之類的問題，併發也致使有些bug難以排查，一不留神就掉坑，須要適當用一些隊列/鎖保證程序的執行順序。iOS提供了一套多線程管理的方 法GCD，已經把線程和隊列封裝得很是簡單易用功能強大，比其餘端或後臺是好不少了，但仍是會花大量功夫在處理多線程問題上。java
存儲
終端開發須要大量的數據存儲邏輯，手機APP不像瀏覽器，用戶打開瀏覽器一定是連着網，但打開一個APP時極可能是離線，也極可能處於網絡情況極差 的移動GPRS，因此必須把以前請求回來的數據保存好。保存數據後又須要與服務端最新的數據同步，若是全量同步數據量太大，耗流量速度也慢，因而須要增量 同步，須要與服務端一塊兒制定實現增量數據返回的方案，須要處理好客戶端與服務端數據一致性的問題。當數據存儲量大結構複雜時，還須要利用好有限的內存作 cache，優化各種存儲查詢性能。c++
前端在桌面端不多須要存儲，除非是one page app，不存儲天然就不須要數據更新的一系列工做，數據都是從後臺取出拼接後直接顯示到頁面上，即便像微博有能夠在頁面內不斷加載更多數據，數據也只存在 於內存，不會持久化存儲，由於桌面端網速穩定，不計流量，全部數據能夠直接從後端拿取，客戶端不必再作一套存儲。移動端那些作得很像原生APP的web 應用就跟終端開發同樣了，數據一樣保存到SQLite，存儲邏輯以及要處理的問題都差很少。web
框架
在第三方框架上web前端和iOS開發徹底相反，web原生弱小又十分開放，讓大量第三方框架和類庫能夠施展拳腳，而iOS原生強大又十分封閉，致使第三方框架沒有多少生存空間。chrome
瀏覽器一開始只爲內容型的網頁而設計，js也只是這個網頁上能加點小特效的腳本語言，在web應用時代跟不上發展，須要不少第三方庫和框架輔助，再 加上前端開發是徹底開放的領域，致使庫和框架百花齊放多如牛毛，在初期多數庫的做用集中在封裝dom操做，你們不斷重複造dom操做基礎庫的輪子，在一段 時間百家爭鳴後獨尊jQuery，在有使用庫的網站中90%以上使用jq，幾乎成了個標準基礎庫。後期你們已經再也不重複造這個基礎庫的輪子了，多了一些代 碼組織和前端架構的框架，例如一些幫助項目模塊化的框架require.js，MVC框架backbone/angular.js等。數據庫
iOS開發蘋果已提供了完整的開發框架cocoa，而這框架在每一代系統中都在升級優化和添磚加瓦，開發模式也已經定型，第三方框架沒有多少生存空 間，大量流行的開源項目是一些通用組件和庫，像網絡請求庫AFNetworking，數據庫操做庫FMDB。而一些大的框架像 beeFramework/ReactiveCocoa較難流行起來。
兼容
前端開發須要兼容大——量的瀏覽器，桌面的chrome，safari，ie6-ie10，firefox，以及各類套殼獵豹360等瀏覽器，移動 端iOS/Android各自的瀏覽器，以及無限的不一樣的屏幕尺寸。看起來挺可怕，實際上也沒那麼難搞，只是拿出來嚇唬下人。桌面端chrome /safari以及各類套殼的極速模式用的都是webkit，差別很小，firefox也大致聽從標準實現，與webkit差異不大，舊的ie6/7就需 要特別照顧，不過不少網站都不支持ie6了，移動端更是一家親，全是webkit，除了新特性上的支持程度不一，其餘差別不大。對於不一樣的屏幕尺寸，高端 點的會用響應式佈局，針對不一樣屏幕尺寸自適應到不一樣佈局，通常點的桌面端定死寬度，移動端拉伸自適應寬度就搞定。
終端開發也須要兼容各類不一樣的系統版本和手機尺寸，Android不用說，iOS也有3.5/4/4.7/5.5/9.7英寸這些尺寸，不過兼容起 來跟web同樣挺容易，就是自適應寬度，iOS的UIKit把這些都處理好了，還有autolayout，sizeClass等高級特性可用，在尺寸上並 不用花太多功夫。系統版本上iOS7爲分水嶺，iOS7先後版本UI上差別比較大，須要作一些功夫兼容，不過iOS用戶更新換代很快，預計再過一兩年 iOS7如下用戶就能夠忽略了。
性能
終端和前端都是面向用戶的，性能優化目的都是儘快呈現內容，以及讓程序在用戶操做下流暢運行。終端主要關注的是存儲/渲染性能。當一個APP存儲數 據量大，數據關係複雜時，數據查詢很容易成爲性能瓶頸，須要不斷優化數據存取的效率，規劃數據IO線程，設計內存cache，利用好終端設備有限的內存， 渲染上避免重複渲染，儘量複用視圖，尋找最高效的渲染方案。
前端關注頁面加載速度，因爲web頁面的結構/樣式/程序/資源圖片都是實時請求的，要讓頁面更快呈現內容，就要優化這些請求，讓這些資源以最快速 度加載下來，包括合併圖片/合併代碼減小請求數，壓縮代碼，並行請求，根據版本號緩存代碼請求，gzip壓縮，模塊/圖片懶加載等。此外跟終端同樣也關注 渲染性能，聽從一些規則避免頁面reflow，避免使用CSS陰影這樣耗性能的特效，用CSS3動畫代替js等。
編譯
終端開發須要編譯的過程，把程序編譯成機器語言，再與各類庫連接後生成平臺對應的可執行文件，最後由操做系統調度執行。在iOS終端開發中編譯和鏈 接的規則蘋果已經在xcode這個開發工具上封裝好，通常開發能夠不用關心，但有深層需求時仍是須要跟編譯打不少交道，例如用編譯前端Clang自定義靜 態代碼檢測規則，寫編譯腳本作自動化編譯和持續集成，打包生成靜態庫，根據連接後的可執行文件的組成優化APP體積等。
前端開發的程序則不須要編譯過程，只須要把代碼扔給瀏覽器，瀏覽器邊解析代碼邊執行。雖然js/css代碼寫完無需作任何事情瀏覽器就能夠解析執 行，但爲了上面說的性能優化，前端代碼上線前會對全部代碼和資源文件進行處理，這些處理包括：壓縮合並js/css，合併css sprite圖，處理模塊依賴，處理代碼資源版本號，處理資源定位等。這個過程很像傳統程序的編譯，把給人看的代碼優化處理成給機器看的，並解決一些依賴 關係，能夠算是前端的編譯過程。像grunt.js/fis這些工具能夠幫助完成這個編譯過程，一般前端編譯跟上線部署結合在一塊兒，做爲上線系統的一部 分。
安全
前端和終端的安全性問題上雖然不須要像後端考慮得那麼多，但仍是有些須要注意。在請求的安全上，終端和前端都同樣，用戶向後端發送的請求都須要通過 層層路由，不知道在哪裏就被截獲篡改或回放了，因而須要作一些措施防護這些狀況，最多見的就是身份驗證，可能是採用會過時的token形式代替用戶名密碼， 防止被抓包後黑客能夠永遠登錄這個帳號。數據安全要求高的會用加密傳輸，或者使用https，另外還須要看狀況處理一些DNS劫持，運營商廣告植入等問 題。
其餘安全問題終端不多考慮，在未越獄的iOS機器上系統已經幫忙保證了整個APP運行環境的安全，而在越獄的機器下惡意程序擁有root權限能夠作 任何事情，APP也難以防範。前端方面瀏覽器的特性使前端開發有幾個安全隱患，一是web頁面上任意位置均可以動態插入js代碼，瀏覽器會無區別地執行這 些代碼，二是身份驗證信息都統一保存在cookie裏，三是頁面上能夠隨意經過iframe嵌入其餘網站的頁面。形成XSS、CSRF、cookie劫持 這些攻擊手段，因此前端寫代碼時都須要考慮還這些安全問題，作好相應的防範，最簡單和重要的防範就是對全部用戶輸入輸出的內容作完整的過濾，避免頁面內被 嵌入惡意代碼。
交互/開發
最後說下對這兩個領域在交互和開發上的我的感觸。之前在作web前端時，感受web讓人機交互倒退了十年，交互都是硬邦邦的點擊—啪一下出來結果， 滾動是一格格地刷新，不少人當時在鼓吹html5能夠作出多麼炫的效果時，實際上FLASH在十年前就能夠作出來了，還比最現代的瀏覽器更流暢。 iPhone流行後，人機交互終於恢復了應有的水平，體驗上比web流暢太多，指尖交互/流暢的動畫/便捷的滑動手勢/無限制的實現，主流終於恢復或超越 了十年前Flash的水平。
但人機交互提高了，開發方式卻大倒退，web的開發方式很是先進，用戶用到的都是最新版本，發現bug能夠立刻上線秒修復，特別適用於互聯網環境下 的快速迭代，而終端APP不行，撇開iPhone的審覈不說，Android也沒法作到保證用戶用的是最新的程序，用的都是傳統的客戶端更新的方 式，bug的修復版沒法及時給到用戶，沒法一天上線幾十次，須要維護不少舊版本，開發方式倒退回web時代之前。這都是由於移動網絡不穩定以及流量有限造 成的，移動端沒法像桌面端瀏覽器那樣徹底依賴網絡，因此在移動網絡穩定流量免費以前，開發方式都不會有多大變化。
另外並不看好HTML5，網絡上說它能夠取代APP說了三四年，到如今也沒什麼戰績，原生APP能夠得到更多的系統資源，更流暢的人機交互體 驗，HTML5在這方面永遠比不上，而它在移動端網絡和流量的限制下也沒法發揮web的開發優點，因此純HTML5應用不會成爲主流，能作的就是混搭開 發，或者利用無需安裝/獲取成本低的優點，作一些輕量的東西寄生在一個平臺上。