語(yǔ)言

前端和終端作為面向用戶端的程序，有個(gè)共同特點(diǎn)：需要依賴用戶機(jī)器的運(yùn)行環(huán)境，所以開(kāi)發(fā)語(yǔ)言基本上是沒(méi)有選擇的，不像后臺(tái)想用什么就用什 么，iOS只能用Objective-C，前端只能javascript，當(dāng)然iOS還可以用RubyMotion，前端還能用 GWT/CoffieScript，但不是主流，用的人很少，真正用了也會(huì)多出很多麻煩。

這兩者有個(gè)有意思的對(duì)比：變量/方法命名的風(fēng)格正好相反。蘋果一直鼓吹用戶體驗(yàn)，寫代碼也不例外，程序命名都是用英文全稱并且要多詳細(xì)有多詳細(xì)，力求看變量和方法名就能知道是干嘛的，例如application:didFinishLaunchingWithOptions:。 而js因?yàn)槊看味家獜木W(wǎng)絡(luò)下載，要力求減少代碼體積，所以變量方法名是盡量用縮寫，實(shí)際上有代碼壓縮工具，無(wú)論變量名寫多長(zhǎng)最終上線的效果是一樣的，但大 家也都習(xí)慣了用短的命名，例如上述objc的application:didFinishLaunchingWithOptions:方法在js里習(xí)慣的 命名是:$()。

objc與js都是動(dòng)態(tài)語(yǔ)言，使用起來(lái)還蠻像，但objc是編譯型，速度快，很多錯(cuò)誤也能在編譯過(guò)程中被發(fā)現(xiàn)，js是解釋型，性能依賴于解釋引 擎，即使在強(qiáng)勁的v8引擎下性能也趕不上編譯型語(yǔ)言，語(yǔ)言太動(dòng)態(tài)，變量完全沒(méi)有類型，寫起來(lái)爽，debug起來(lái)稍微費(fèi)點(diǎn)勁。一直感覺(jué)js輕巧靈活放蕩不羈 充滿各種奇技淫巧，objc中規(guī)中矩沒(méi)c++ java那么嚴(yán)肅也沒(méi)有js那么靈活。

[[137982]]

線程

前端開(kāi)發(fā)幾乎不需要線程這個(gè)概念，瀏覽器實(shí)現(xiàn)上頁(yè)面HTML和CSS解析渲染可能與js不在同一個(gè)線程，但所有js代碼只執(zhí)行在一條線程上，不會(huì)并發(fā)執(zhí)行，也就不需要考慮各種并發(fā)編程的 問(wèn)題。在新的JS特性中可以創(chuàng)建worker任務(wù)，這樣的任務(wù)是可以另起一條線程并行執(zhí)行的，但由于并不是所有瀏覽器都支持，不同線程傳遞數(shù)據(jù)各個(gè)標(biāo)準(zhǔn)定 的還不一樣，使用場(chǎng)景也少，似乎沒(méi)有大規(guī)模用起來(lái)。對(duì)于數(shù)據(jù)庫(kù)操作/發(fā)送網(wǎng)絡(luò)請(qǐng)求這樣的任務(wù)是在不同于js代碼執(zhí)行線程的，不過(guò)這些都由瀏覽器管理，前端 無(wú)需關(guān)心也無(wú)法影響這些線程，只需接收事件回調(diào)，不需要處理任何并發(fā)問(wèn)題。

終端開(kāi)發(fā)需要大量使用多線程，iOS有一條主線程，UI渲染都在這個(gè)線程，其他耗時(shí)長(zhǎng)的邏輯或者數(shù)據(jù)庫(kù)IO/網(wǎng)絡(luò)請(qǐng)求都需要自己另開(kāi)線程執(zhí)行， 否則會(huì)占用主線程的時(shí)間，導(dǎo)致界面無(wú)法響應(yīng)用戶交互事件，或者渲染慢導(dǎo)致滾動(dòng)卡頓。程序邏輯分布在多個(gè)線程里跑，需要處理好各種代碼并發(fā)執(zhí)行可能帶來(lái)的數(shù) 據(jù)不一致/時(shí)序錯(cuò)亂之類的問(wèn)題，并發(fā)也導(dǎo)致有些bug難以排查，一不留神就掉坑，需要適當(dāng)用一些隊(duì)列/鎖保證程序的執(zhí)行順序。iOS提供了一套多線程管理 的方法GCD，已經(jīng)把線程和隊(duì)列封裝得非常簡(jiǎn)單易用功能強(qiáng)大，比其他端或后臺(tái)是好很多了，但還是會(huì)花大量功夫在處理多線程問(wèn)題上。

存儲(chǔ)

終端開(kāi)發(fā)需要大量的數(shù)據(jù)存儲(chǔ)邏輯，手機(jī)APP不像瀏覽器，用戶打開(kāi)瀏覽器必定是連著網(wǎng)，但打開(kāi)一個(gè)APP時(shí)很可能是離線，也很可能處于網(wǎng)絡(luò)狀況 極差的移動(dòng)GPRS，所以必須把之前請(qǐng)求回來(lái)的數(shù)據(jù)保存好。保存數(shù)據(jù)后又需要與服務(wù)端最新的數(shù)據(jù)同步，如果全量同步數(shù)據(jù)量太大，耗流量速度也慢，于是需要 增量同步，需要與服務(wù)端一起制定實(shí)現(xiàn)增量數(shù)據(jù)返回的方案，需要處理好客戶端與服務(wù)端數(shù)據(jù)一致性的問(wèn)題。當(dāng)數(shù)據(jù)存儲(chǔ)量大結(jié)構(gòu)復(fù)雜時(shí)，還需要利用好有限的內(nèi)存 做cache，優(yōu)化各類存儲(chǔ)查詢性能。

前端在桌面端很少需要存儲(chǔ)，除非是Single Page App，不存儲(chǔ)自然就不需要數(shù)據(jù)更新的一系列工作，數(shù)據(jù)都是從后臺(tái)取出拼接后直接顯示到頁(yè)面上，即使像微博有可以在頁(yè)面內(nèi)不斷加載更多數(shù)據(jù)，數(shù)據(jù)也只存在 于內(nèi)存，不會(huì)持久化存儲(chǔ)，因?yàn)樽烂娑司W(wǎng)速穩(wěn)定，不計(jì)流量，所有數(shù)據(jù)可以直接從后端拿取，客戶端沒(méi)必要再做一套存儲(chǔ)。移動(dòng)端那些做得很像原生APP的Web 應(yīng)用就跟終端開(kāi)發(fā)一樣了，數(shù)據(jù)同樣保存到SQLite，存儲(chǔ)邏輯以及要處理的問(wèn)題都差不多。

框架

在第三方框架上Web前端和iOS開(kāi)發(fā)完全相反，Web原生弱小又十分開(kāi)放，讓大量第三方框架和類庫(kù)可以施展拳腳，而iOS原生強(qiáng)大又十分封閉，導(dǎo)致第三方框架沒(méi)有多少生存空間。

瀏覽器一開(kāi)始只為內(nèi)容型的網(wǎng)頁(yè)而設(shè)計(jì)，js也只是這個(gè)網(wǎng)頁(yè)上能加點(diǎn)小特效的腳本語(yǔ)言，在Web應(yīng)用時(shí)代跟不上發(fā)展，需要很多第三方庫(kù)和框架輔助，再加上前端開(kāi)發(fā)是完全開(kāi)放的領(lǐng)域，導(dǎo)致庫(kù)和框架百花齊放多如牛毛，在初期多數(shù)庫(kù)的作用集中在封裝dom操 作，大家不斷重復(fù)造dom操作基礎(chǔ)庫(kù)的輪子，在一段時(shí)間百家爭(zhēng)鳴后獨(dú)尊jQuery，在有使用庫(kù)的網(wǎng)站中90%以上使用jq，幾乎成了個(gè)標(biāo)準(zhǔn)基礎(chǔ)庫(kù)。后期 大家已經(jīng)不再重復(fù)造這個(gè)基礎(chǔ)庫(kù)的輪子了，多了一些代碼組織和前端架構(gòu)的框架，例如一些幫助項(xiàng)目模塊化的框架require.js，MVC框架 backbone/angular.js等。

iOS開(kāi)發(fā)蘋果已提供了完整的開(kāi)發(fā)框架cocoa，而這框架在每一代系統(tǒng)中都在升級(jí)優(yōu)化和添磚加瓦，開(kāi)發(fā)模式也已經(jīng)定型，第三方框架沒(méi)有多少生存空間，大量流行的開(kāi)源項(xiàng)目是一些通用組件和庫(kù)，像網(wǎng)絡(luò)請(qǐng)求庫(kù)AFNetworking，數(shù)據(jù)庫(kù)操作庫(kù)FMDB。而一些大的框架像beeFramework/ReactiveCocoa較難流行起來(lái)。

兼容

前端開(kāi)發(fā)需要兼容大——量的瀏覽器，桌面的chrome，safari，ie6-ie10，firefox，以及各種套殼獵豹360等瀏覽器， 移動(dòng)端iOS/Android各自的瀏覽器，以及無(wú)限的不同的屏幕尺寸。看起來(lái)挺可怕，實(shí)際上也沒(méi)那么難搞，只是拿出來(lái)嚇唬下人。桌面端chrome /safari以及各種套殼的極速模式用的都是Webkit，差異很小，firefox也大體遵從標(biāo)準(zhǔn)實(shí)現(xiàn)，與Webkit差別不大，舊的ie6/7就需 要特別照顧，不過(guò)很多網(wǎng)站都不支持ie6了，移動(dòng)端更是一家親，全是Webkit，除了新特性上的支持程度不一，其他差異不大。對(duì)于不同的屏幕尺寸，高端 點(diǎn)的會(huì)用響應(yīng)式布局，針對(duì)不同屏幕尺寸自適應(yīng)到不同布局，一般點(diǎn)的桌面端定死寬度，移動(dòng)端拉伸自適應(yīng)寬度就搞定。

終端開(kāi)發(fā)也需要兼容各種不同的系統(tǒng)版本和手機(jī)尺寸，Android不用說(shuō)，iOS也有3.5/4/4.7/5.5/9.7英寸這些尺寸，不過(guò)兼 容起來(lái)跟Web一樣挺容易，就是自適應(yīng)寬度，iOS的UIKit把這些都處理好了，還有autolayout，sizeClass等高級(jí)特性可用，在尺寸 上并不用花太多功夫。系統(tǒng)版本上iOS7為分水嶺，iOS7前后版本UI上差異比較大，需要做一些功夫兼容，不過(guò)iOS用戶更新?lián)Q代很快，預(yù)計(jì)再過(guò)一兩年 iOS7以下用戶就可以忽略了。

性能

終端和前端都是面向用戶的，性能優(yōu)化目的都是盡快呈現(xiàn)內(nèi)容，以及讓程序在用戶操作下流暢運(yùn)行。終端主要關(guān)注的是存儲(chǔ)/渲染性能。當(dāng)一個(gè)APP存儲(chǔ)數(shù)據(jù)量大，數(shù)據(jù)關(guān)系復(fù)雜時(shí)，數(shù)據(jù)查詢很容易成為性能瓶頸，需要不斷優(yōu)化數(shù)據(jù)存取的效率，規(guī)劃數(shù)據(jù)IO線程，設(shè)計(jì)內(nèi)存cache，利用好終端設(shè)備有限的內(nèi)存，渲染上避免重復(fù)渲染，盡可能復(fù)用視圖，尋找最高效的渲染方案。

前端關(guān)注頁(yè)面加載速度，由于Web頁(yè)面的結(jié)構(gòu)/樣式/程序/資源圖片都是實(shí)時(shí)請(qǐng)求的，要讓頁(yè)面更快呈現(xiàn)內(nèi)容，就要優(yōu)化這些請(qǐng)求，讓這些資源以最 快速度加載下來(lái)，包括合并圖片/合并代碼減少請(qǐng)求數(shù)，壓縮代碼，并行請(qǐng)求，根據(jù)版本號(hào)緩存代碼請(qǐng)求，gzip壓縮，模塊/圖片懶加載等。此外跟終端一樣也 關(guān)注渲染性能，遵從一些規(guī)則避免頁(yè)面reflow，避免使用CSS陰影這樣耗性能的特效，用CSS3動(dòng)畫代替js等。

編譯

終端開(kāi)發(fā)需要編譯的過(guò)程，把程序編譯成機(jī)器語(yǔ)言，再與各種庫(kù)鏈接后生成平臺(tái)對(duì)應(yīng)的可執(zhí)行文件，最后由操作系統(tǒng)調(diào)度執(zhí)行。在iOS終端開(kāi)發(fā)中編譯和鏈接的規(guī)則蘋果已經(jīng)在xcode這個(gè)開(kāi)發(fā)工具上封裝好，一般開(kāi)發(fā)可以不用關(guān)心，但有深層需求時(shí)還是需要跟編譯打很多交道，例如用編譯前端Clang自定義靜態(tài)代碼檢測(cè)規(guī)則，寫編譯腳本做自動(dòng)化編譯和持續(xù)集成，打包生成靜態(tài)庫(kù)，根據(jù)鏈接后的可執(zhí)行文件的組成優(yōu)化APP體積等。

　前端開(kāi)發(fā)的程序則不需要編譯過(guò)程，只需要把代碼扔給瀏覽器，瀏覽器邊解析代碼邊執(zhí)行。雖然js/css代碼寫完無(wú)需做任何事情瀏覽器就可以解析執(zhí) 行，但為了上面說(shuō)的性能優(yōu)化，前端代碼上線前會(huì)對(duì)所有代碼和資源文件進(jìn)行處理，這些處理包括：壓縮合并js/css，合并css sprite圖，處理模塊依賴，處理代碼資源版本號(hào)，處理資源定位等。這個(gè)過(guò)程很像傳統(tǒng)程序的編譯，把給人看的代碼優(yōu)化處理成給機(jī)器看的，并解決一些依賴 關(guān)系，可以算是前端的編譯過(guò)程。像grunt.js/fis這些工具可以幫助完成這個(gè)編譯過(guò)程，通常前端編譯跟上線部署結(jié)合在一起，作為上線系統(tǒng)的一部 分。

安全

前端和終端的安全性問(wèn)題上雖然不需要像后端考慮得那么多，但還是有些需要注意。在請(qǐng)求的安全上，終端和前端都一樣，用戶向后端發(fā)送的請(qǐng)求都需要 經(jīng)過(guò)層層路由，不知道在哪里就被截獲篡改或回放了，于是需要做一些措施防御這些情況，最常見(jiàn)的就是身份驗(yàn)證，多是采用會(huì)過(guò)期的token形式代替用戶名密 碼，防止被抓包后黑客可以永遠(yuǎn)登陸這個(gè)賬號(hào)。數(shù)據(jù)安全要求高的會(huì)用加密傳輸，或者使用https，另外還需要看情況處理一些DNS劫持，運(yùn)營(yíng)商廣告植入等 問(wèn)題。

其他安全問(wèn)題終端很 少考慮，在未越獄的iOS機(jī)器上系統(tǒng)已經(jīng)幫忙保證了整個(gè)APP運(yùn)行環(huán)境的安全，而在越獄的機(jī)器下惡意程序擁有root權(quán)限可以做任何事情，APP也難以防 范。前端方面瀏覽器的特性使前端開(kāi)發(fā)有幾個(gè)安全隱患，一是Web頁(yè)面上任意位置都可以動(dòng)態(tài)插入js代碼，瀏覽器會(huì)無(wú)區(qū)別地執(zhí)行這些代碼，二是身份驗(yàn)證信息 都統(tǒng)一保存在cookie里，三是頁(yè)面上可以隨意通過(guò)iframe嵌入其他網(wǎng)站的頁(yè)面。造成XSS、CSRF、cookie劫持這些攻擊手段，所以前端寫 代碼時(shí)都需要考慮還這些安全問(wèn)題，做好相應(yīng)的防范，最簡(jiǎn)單和重要的防范就是對(duì)所有用戶輸入輸出的內(nèi)容做完整的過(guò)濾，避免頁(yè)面內(nèi)被嵌入惡意代碼。

交互/開(kāi)發(fā)

最后說(shuō)下對(duì)這兩個(gè)領(lǐng)域在交互和開(kāi)發(fā)上的個(gè)人感觸。以前在做Web前端時(shí)，感覺(jué)Web讓人機(jī)交互倒退了十年，交互都是硬邦邦的點(diǎn)擊—啪一下出來(lái)結(jié)果，滾動(dòng)是一格格地刷新，很多人當(dāng)時(shí)在鼓吹html5可以做出多么炫的效果時(shí)，實(shí)際上FLASH在十年前就可以做出來(lái)了，還比最現(xiàn)代的瀏覽器更流暢。iPhone流行后，人機(jī)交互終于恢復(fù)了應(yīng)有的水平，體驗(yàn)上比Web流暢太多，指尖交互/流暢的動(dòng)畫/便捷的滑動(dòng)手勢(shì)/無(wú)限制的實(shí)現(xiàn)，主流終于恢復(fù)或超越了十年前Flash的水平。

但人機(jī)交互提升了，開(kāi)發(fā)方式卻大倒退，Web的開(kāi)發(fā)方式非常先進(jìn)，用戶用到的都是最新版本，發(fā)現(xiàn)bug可以馬上上線秒修復(fù)，特別適用于互聯(lián)網(wǎng)環(huán)境下的快速迭代，而終端APP 不行，撇開(kāi)iPhone的審核不說(shuō)，Android也無(wú)法做到保證用戶用的是最新的程序，用的都是傳統(tǒng)的客戶端更新的方式，bug的修復(fù)版無(wú)法及時(shí)給到用 戶，無(wú)法一天上線幾十次，需要維護(hù)很多舊版本，開(kāi)發(fā)方式倒退回Web時(shí)代以前。這都是因?yàn)橐苿?dòng)網(wǎng)絡(luò)不穩(wěn)定以及流量有限造成的，移動(dòng)端無(wú)法像桌面端瀏覽器那 樣完全依賴網(wǎng)絡(luò)，所以在移動(dòng)網(wǎng)絡(luò)穩(wěn)定流量免費(fèi)之前，開(kāi)發(fā)方式都不會(huì)有多大變化。

另外并不看好HTML5，網(wǎng)絡(luò)上說(shuō)它可以取代APP說(shuō)了三四年，到現(xiàn)在也沒(méi)什么戰(zhàn)績(jī)，我看不到它的優(yōu)勢(shì)，原生APP可以獲得更多的系統(tǒng)資源，更流暢的人機(jī)交互體驗(yàn)，HTML5在這方面永遠(yuǎn)比不上，而它在移動(dòng)端網(wǎng)絡(luò)和流量的限制下也無(wú)法發(fā)揮Web的開(kāi)發(fā)優(yōu)勢(shì)，所以它不會(huì)成為主流，只適合做一些輕量的小東西。