從0到1構(gòu)建"跨平臺"應(yīng)用

?

偶然翻到去年2月份內(nèi)部分享的 PPT ，主要是關(guān)于內(nèi)部推廣 React Native，當(dāng)時自我感覺良好，現(xiàn)在看來簡直就像小丑的表演，為了不遺忘這段表演，特地回顧一下并記錄下來，也希望各位多多指教！

?

自我介紹

大家好，我是來自互聯(lián)網(wǎng)應(yīng)用產(chǎn)品部的前端開發(fā)，今天給大家分享的主題是 『從0到1構(gòu)建"跨平臺"應(yīng)用』。國際慣例，首先先自我介紹一下，我叫胡琦，江湖 人稱“Copy攻城獅”，百度"Copy攻城獅"或者谷歌“胡琦”應(yīng)該都能找到我。我的經(jīng)歷 和經(jīng)驗都很簡單，精通JavaScript、Java、Python、PHP各種語言的“Hello World”寫法，熟練掌握“CV”技能，因此被稱為“Copy攻城獅”。雖然做了快4年的前端，依舊也只懂皮毛，基本沒有形成自己的技術(shù)體系，真·前端打雜，還懇請各位大佬多多指教，當(dāng)然我也會爭取早日擺脫CV大法，實現(xiàn)技術(shù)積累質(zhì)的飛躍。

Github: https://github.com/hu-qi

公眾號: 胡琦

前端"跨平臺"發(fā)展史

"跨平臺"我特意加了引號；提到跨平臺，可能1000個程序員會有1000種看法。有人認為“跨平臺”指支持多種操作系統(tǒng)的軟件，如MYSQL、Apache；也有人認為”跨平臺”指可在不同操作系統(tǒng)上進行軟件開發(fā)的編程語言，如Java。我今天提到的“跨平臺”僅僅是我對前端開發(fā)過程中的“跨平臺”的認識，隨著大前端技術(shù)的突飛猛進，jQuery成為了萬千前端開發(fā)調(diào)侃的最佳對象，因此，我對前端“跨平臺”發(fā)展史的研究也將jQuery作為時間軸標志。前jQuery時期，主要是跨瀏覽器，因為微軟沒有遵循ECMA-262（JavaScript規(guī)范文檔）與W3C（HTML與CSS的規(guī)范文檔）另起爐灶，導(dǎo)致前端兼容問題的出現(xiàn)，典型的相信早期前端面試都會問到的CSS Hack，屬性級Hack（如IE6能識別下劃線“”和星號“”，IE7能識別星號“”，但不能識別下劃線” ”，而firefox兩個都不能認識）、選擇符級Hack（比如IE6能識別html .class{}，IE7能識別+html .class{}或者*:first-child+html .class{}）、IE條件注釋Hack等等。jQuery時期面臨的”跨平臺”問題依舊是瀏覽器兼容問題，只不過更偏向于DOM兼容，前期也很多解讀jQuery源碼的教程，很大一部分會提到一些兼容谷歌、火狐、IE不同版本的實現(xiàn)。后jQuery時期，隨著HTML5的發(fā)展和移動web的流行，”跨平臺”開始要解決PC端和移動web端的兼容問題，Bootstrap.js、響應(yīng)式布局、REM布局解決方案遍地開花。到今天，三大前端框架Angular.js、Vue.js、React，前端開發(fā)開始涉及到Android、IOS、PC桌面應(yīng)用等，前端“跨平臺”迎來了新的機遇和挑戰(zhàn)。未來，大前端技術(shù)涵蓋JavaScript、小程序，甚至Flutter，前端“跨平臺”將會延伸到智慧屏、智能手表等等。

技術(shù)選型脫離實際業(yè)務(wù)需求場景，談技術(shù)選型都是耍流氓！現(xiàn)在我們的需求是什么？構(gòu)建“跨平臺”應(yīng)用！就我們現(xiàn)在的項目而言，前期的需求就很明確—開發(fā)某應(yīng)用的Android和IOS版本， 鑒于團隊之前在歷史項目上的積累，以及對現(xiàn)有移動端跨平臺方案的調(diào)研分析和實踐，我們選用React Native作為應(yīng)用一期的開發(fā)框架。

google的flutter、facebook的react native；阿里的weex；京東的Taro；ionic早期依賴AngularJS, 滴滴的卡梅隆、騰訊的hippy ……，百花齊放。當(dāng)時列出表格對各技術(shù)進行了分析對比，前端技術(shù)選型是個很痛苦的過程，選擇實在是太多了，另外如果不考慮團隊現(xiàn)有技術(shù)儲備的話google的Flutter也是絕佳的選擇。話又說回來，沒有哪一種技術(shù)是一勞永逸的，只有適合自己業(yè)務(wù)場景的才是最合適的。

前面的技術(shù)選型對比主要來源于各大平臺的主流判斷，還包括github上的一些信息反饋。總得來說是一些理論上的觀點和其他大公司的一些實踐認知。 而我們在理論的基礎(chǔ)上，還需要去初步驗證技術(shù)選型。最好的方法是從“HelloWorld”開始。屬于JavaScript陣營的框架，基本離不開對Node.js的依賴，package.json是標配；基于其他語言的跨平臺框架也會有類似的包管理文件。另外，關(guān)于開發(fā)環(huán)境的安裝，這里就不一一贅述，既然是跨平臺開發(fā)最起碼就需要Android、IOS或者Web開發(fā)環(huán)境，選擇不同的開發(fā)框架，可能還會要求安裝額外的環(huán)境之類的。對于環(huán)境的搭建，我想說一定要有耐心，遇到問題不要灰心，基本上我們踩到的坑或多或少別人也踩過，這里建議大家勤動手多記錄，一是鞏固自己掌握的，二是方便后來人及時脫坑。另外，翻墻工具應(yīng)該算是開發(fā)必備，雖然絕大多數(shù)依賴都有國內(nèi)鏡像，但是有些莫名其妙的bug在翻墻的環(huán)境下就不存在。 這里我分別安裝了flutter、React Native、Weex、Taro的腳手架工具，并初始化了’helloWorld’項目。

既然是“跨平臺”框架，從Helloworld的項目結(jié)構(gòu)中，或多或少能看出一些端倪。像flutter、React Native、Weex都直接有名字為android、ios的文件夾或文件；而Taro編譯成 原生應(yīng)用是需要先編譯成React Native代碼的。通過展開關(guān)鍵開發(fā)目錄，不難看出Flutter和React Native都需要開發(fā)者自動引入或配置路由，而Weex基于Vue.js,因為我初始化 項目是選用的vue-router，所以會存在路由文件；Taro腳手架初始化項目直接推薦使用了typeScript?？磥韺W(xué)一波TypeScript勢在必行??！從HelloTaro目錄結(jié)構(gòu)中也能看出這個 框架初期的定位和微信小程序有著千絲萬縷的關(guān)系，更適合來做兼容多端小程序。一般來說，默認的項目結(jié)構(gòu)不足以支撐開發(fā)，正式開發(fā)之前我們要確定目錄結(jié)構(gòu)、編碼規(guī)范， 甚至項目組件化、工程化等等。

“四化”

這里“四化”只得是規(guī)范化、組件化、模塊化、工程化，是項目開發(fā)的必然結(jié)果，也是項目開發(fā)的必經(jīng)之路，未來還會向智能化的方向發(fā)展。當(dāng)然這些只是抽象的事物，需要具體的案例來闡述。按照Tencent Now直播前端工程化的實踐分享，我將“四化”分為三個階段，也是前端開發(fā)的三個層次。規(guī)范化是基礎(chǔ)，每個開發(fā)都有自己獨特的開發(fā)習(xí)慣，開發(fā)前期，我們經(jīng)過討論指定一份開發(fā)規(guī)范，包括命名規(guī)范、代碼規(guī)范等等，并且在開發(fā)實踐中不斷完善；規(guī)范化的指定和執(zhí)行抹平了開發(fā)過程中存在的各種差異；當(dāng)然實際上我們做得還不夠，代碼review這塊就沒有很好的堅持執(zhí)行下去。模塊化、組件化其實一開始的作用不會很明顯，但隨著業(yè)務(wù)的拓展，模塊化、組件化的優(yōu)勢就會凸顯出來。至于工程化，我覺得是當(dāng)前項目的敗筆，我們項目中的工程化程度遠遠不足，也直接導(dǎo)致了“發(fā)串生成包”的“事故”,這也恰恰說明了工程化的重要性。

從0開始的話，我建議大家先要站在工程化的高度來布局整個項目架構(gòu)。當(dāng)然，如果有了沉淀，我們只需將過去成熟的方案制作成CLI腳手架甚至是鏡像，后面開發(fā)只需拉取之前的工程化項目，直接從1開始開發(fā)。首先我們要有規(guī)范，規(guī)范怎么定？可以學(xué)習(xí)借鑒開源項目，比如Taro，官方文檔中就推薦了開發(fā)規(guī)范，從工程化的角度，我們至少要引用一種代碼掃碼工具，如Lint，通過配置文件將我們制定的規(guī)范應(yīng)用到項目中；甚至還可以通過一些配置來統(tǒng)一代碼開發(fā)工具，如EditorConfig等；其次模塊化，組件化這部分，如果我們沒有自己的沉淀可以直接借助第三方開源的成熟方案，比如引用第三方UI庫加以定制化，模塊化、組件化具體體現(xiàn)在代碼結(jié)構(gòu)、項目目錄結(jié)構(gòu)。最后適當(dāng)加些自動化測試、自動部署、實時監(jiān)測等，使得前端項目工程化。理想化的前端工程化，是我只要安裝一個腳手架，通過運行腳手架中定義的某些命令就能生成直接可用的項目，再開發(fā)的時候只需注重業(yè)務(wù)。比如攜程之前開源的CRN，甚至修改了React Native底層，做了性能優(yōu)化，內(nèi)部再實現(xiàn)了豐富的命令可以在初始化項目的時候?qū)⑴涮椎腢I、測試、打包部署等工具集成進來，比如之前接觸到的粵省事腳手架 weshop，包括現(xiàn)在那些開源的框架比如Taro、Hipy等等，基本上都或多或少實現(xiàn)了工程化。那接下來，我們也實現(xiàn)一個簡單的腳手架，初始化時直接拉取某個項目代碼。

一個簡單的模板拉取小工具 - cliclicli

實現(xiàn)的功能簡單到不能再簡單，就是從git上拉取項目；卻是前端工程化不可或缺的一環(huán)，就像前面提到的，我們有了沉淀，將成果托管在我們的git私服和npm私服上，通過拉取整個項目快速運用到新的項目中； 如果更完善的話，我們沉淀的成果隨著項目的累積可以不斷的優(yōu)化、提煉。核心代碼就是拉取項目寫入本地。之前接觸的粵省事就是這種開發(fā)方式，工具非常完善，一行命令就把之前積累的一些工程化成果呈現(xiàn) 出來，一行代碼不用寫就能跑起一個完整的小程序。類比一下，同樣，現(xiàn)在我們只執(zhí)行幾行命令，一個clicli視頻APP就出具雛形。當(dāng)然，前端工程化是需要大家共同積累的，也不僅僅局限于前端。講到現(xiàn)在，不知道 大家對我所講的會不會有什么意見。是不是都以為我會講怎么擼代碼？我不知道負責(zé)web和管理端的前端同事以及其他后端同事有沒有去了解過APP端的項目代碼，我認為大家不要拘泥于某一個框架或者某一種語言， 其實項目工程化對我們都提出了新的挑戰(zhàn)。就比如，前端開發(fā)也有必要了解shell、熟悉Node.js,盡管是一個個的小細節(jié)，需要我們大量的經(jīng)驗積累！

我在拉取模板的時候遇到了點點差錯—git clone速度慢，一般來說如果是內(nèi)網(wǎng)gitlab和npm的話是不存在這個問題的。解決方案是修改host文件，添加到git一些域名解析并刷DNS。另外還犯了個常識性的錯誤，開發(fā)目錄不能有中文路徑！通過目錄結(jié)構(gòu)我們可以看出這是一個簡單的業(yè)務(wù)實現(xiàn)，component下放的是頁面（也可認為是業(yè)務(wù)模塊）；wdiget下面放的是組件，如果有了解過flutter，那一定對wdiget不陌生。因為頁面簡單，沒有進行路由拆分，也沒有對網(wǎng)絡(luò)請求層做詳細封裝，但二次封裝了播放器、Icon。

如果模板項目中工程化程度比較高的話，那我們基本可以直接得到一個最小可用的應(yīng)用，包括測試、打包、發(fā)布、部署等，基本都以一行命令或者自動完成。

后記

現(xiàn)在回顧之前的內(nèi)部分享，也不知道最后自己究竟講了些什么，完全是無厘頭的瞎比比，技術(shù)不達標可能就是這樣的現(xiàn)狀吧！

如果本文對您有啟發(fā)，歡迎評論區(qū)探討，也感謝各位在評論區(qū)多多指教！

偶然翻到去年2月份內(nèi)部分享的 PPT ，主要是關(guān)于內(nèi)部推廣 React Native，當(dāng)時自我感覺良好，現(xiàn)在看來簡直就像小丑的表演，為了不遺忘這段表演，特地回顧一下并記錄下來，也希望各位多多指教！

自我介紹

大家好，我是來自互聯(lián)網(wǎng)應(yīng)用產(chǎn)品部的前端開發(fā)，今天給大家分享的主題是 『從0到1構(gòu)建"跨平臺"應(yīng)用』。國際慣例，首先先自我介紹一下，我叫胡琦，江湖 人稱“Copy攻城獅”，百度"Copy攻城獅"或者谷歌“胡琦”應(yīng)該都能找到我。我的經(jīng)歷 和經(jīng)驗都很簡單，精通JavaScript、Java、Python、PHP各種語言的“Hello World”寫法，熟練掌握“CV”技能，因此被稱為“Copy攻城獅”。雖然做了快4年的前端，依舊也只懂皮毛，基本沒有形成自己的技術(shù)體系，真·前端打雜，還懇請各位大佬多多指教，當(dāng)然我也會爭取早日擺脫CV大法，實現(xiàn)技術(shù)積累質(zhì)的飛躍。

Github: https://github.com/hu-qi

公眾號: 胡琦

前端"跨平臺"發(fā)展史

"跨平臺"我特意加了引號；提到跨平臺，可能1000個程序員會有1000種看法。有人認為“跨平臺”指支持多種操作系統(tǒng)的軟件，如MYSQL、Apache；也有人認為”跨平臺”指可在不同操作系統(tǒng)上進行軟件開發(fā)的編程語言，如Java。我今天提到的“跨平臺”僅僅是我對前端開發(fā)過程中的“跨平臺”的認識，隨著大前端技術(shù)的突飛猛進，jQuery成為了萬千前端開發(fā)調(diào)侃的最佳對象，因此，我對前端“跨平臺”發(fā)展史的研究也將jQuery作為時間軸標志。前jQuery時期，主要是跨瀏覽器，因為微軟沒有遵循ECMA-262（JavaScript規(guī)范文檔）與W3C（HTML與CSS的規(guī)范文檔）另起爐灶，導(dǎo)致前端兼容問題的出現(xiàn)，典型的相信早期前端面試都會問到的CSS Hack，屬性級Hack（如IE6能識別下劃線“”和星號“”，IE7能識別星號“”，但不能識別下劃線” ”，而firefox兩個都不能認識）、選擇符級Hack（比如IE6能識別html .class{}，IE7能識別+html .class{}或者*:first-child+html .class{}）、IE條件注釋Hack等等。jQuery時期面臨的”跨平臺”問題依舊是瀏覽器兼容問題，只不過更偏向于DOM兼容，前期也很多解讀jQuery源碼的教程，很大一部分會提到一些兼容谷歌、火狐、IE不同版本的實現(xiàn)。后jQuery時期，隨著HTML5的發(fā)展和移動web的流行，”跨平臺”開始要解決PC端和移動web端的兼容問題，Bootstrap.js、響應(yīng)式布局、REM布局解決方案遍地開花。到今天，三大前端框架Angular.js、Vue.js、React，前端開發(fā)開始涉及到Android、IOS、PC桌面應(yīng)用等，前端“跨平臺”迎來了新的機遇和挑戰(zhàn)。未來，大前端技術(shù)涵蓋JavaScript、小程序，甚至Flutter，前端“跨平臺”將會延伸到智慧屏、智能手表等等。

技術(shù)選型脫離實際業(yè)務(wù)需求場景，談技術(shù)選型都是耍流氓！現(xiàn)在我們的需求是什么？構(gòu)建“跨平臺”應(yīng)用！就我們現(xiàn)在的項目而言，前期的需求就很明確—開發(fā)某應(yīng)用的Android和IOS版本， 鑒于團隊之前在歷史項目上的積累，以及對現(xiàn)有移動端跨平臺方案的調(diào)研分析和實踐，我們選用React Native作為應(yīng)用一期的開發(fā)框架。

google的flutter、facebook的react native；阿里的weex；京東的Taro；ionic早期依賴AngularJS, 滴滴的卡梅隆、騰訊的hippy ……，百花齊放。當(dāng)時列出表格對各技術(shù)進行了分析對比，前端技術(shù)選型是個很痛苦的過程，選擇實在是太多了，另外如果不考慮團隊現(xiàn)有技術(shù)儲備的話google的Flutter也是絕佳的選擇。話又說回來，沒有哪一種技術(shù)是一勞永逸的，只有適合自己業(yè)務(wù)場景的才是最合適的。

前面的技術(shù)選型對比主要來源于各大平臺的主流判斷，還包括github上的一些信息反饋。總得來說是一些理論上的觀點和其他大公司的一些實踐認知。 而我們在理論的基礎(chǔ)上，還需要去初步驗證技術(shù)選型。最好的方法是從“HelloWorld”開始。屬于JavaScript陣營的框架，基本離不開對Node.js的依賴，package.json是標配；基于其他語言的跨平臺框架也會有類似的包管理文件。另外，關(guān)于開發(fā)環(huán)境的安裝，這里就不一一贅述，既然是跨平臺開發(fā)最起碼就需要Android、IOS或者Web開發(fā)環(huán)境，選擇不同的開發(fā)框架，可能還會要求安裝額外的環(huán)境之類的。對于環(huán)境的搭建，我想說一定要有耐心，遇到問題不要灰心，基本上我們踩到的坑或多或少別人也踩過，這里建議大家勤動手多記錄，一是鞏固自己掌握的，二是方便后來人及時脫坑。另外，翻墻工具應(yīng)該算是開發(fā)必備，雖然絕大多數(shù)依賴都有國內(nèi)鏡像，但是有些莫名其妙的bug在翻墻的環(huán)境下就不存在。 這里我分別安裝了flutter、React Native、Weex、Taro的腳手架工具，并初始化了’helloWorld’項目。

既然是“跨平臺”框架，從Helloworld的項目結(jié)構(gòu)中，或多或少能看出一些端倪。像flutter、React Native、Weex都直接有名字為android、ios的文件夾或文件；而Taro編譯成 原生應(yīng)用是需要先編譯成React Native代碼的。通過展開關(guān)鍵開發(fā)目錄，不難看出Flutter和React Native都需要開發(fā)者自動引入或配置路由，而Weex基于Vue.js,因為我初始化 項目是選用的vue-router，所以會存在路由文件；Taro腳手架初始化項目直接推薦使用了typeScript。看來學(xué)一波TypeScript勢在必行??！從HelloTaro目錄結(jié)構(gòu)中也能看出這個 框架初期的定位和微信小程序有著千絲萬縷的關(guān)系，更適合來做兼容多端小程序。一般來說，默認的項目結(jié)構(gòu)不足以支撐開發(fā)，正式開發(fā)之前我們要確定目錄結(jié)構(gòu)、編碼規(guī)范， 甚至項目組件化、工程化等等。

“四化”

這里“四化”只得是規(guī)范化、組件化、模塊化、工程化，是項目開發(fā)的必然結(jié)果，也是項目開發(fā)的必經(jīng)之路，未來還會向智能化的方向發(fā)展。當(dāng)然這些只是抽象的事物，需要具體的案例來闡述。按照Tencent Now直播前端工程化的實踐分享，我將“四化”分為三個階段，也是前端開發(fā)的三個層次。規(guī)范化是基礎(chǔ)，每個開發(fā)都有自己獨特的開發(fā)習(xí)慣，開發(fā)前期，我們經(jīng)過討論指定一份開發(fā)規(guī)范，包括命名規(guī)范、代碼規(guī)范等等，并且在開發(fā)實踐中不斷完善；規(guī)范化的指定和執(zhí)行抹平了開發(fā)過程中存在的各種差異；當(dāng)然實際上我們做得還不夠，代碼review這塊就沒有很好的堅持執(zhí)行下去。模塊化、組件化其實一開始的作用不會很明顯，但隨著業(yè)務(wù)的拓展，模塊化、組件化的優(yōu)勢就會凸顯出來。至于工程化，我覺得是當(dāng)前項目的敗筆，我們項目中的工程化程度遠遠不足，也直接導(dǎo)致了“發(fā)串生成包”的“事故”,這也恰恰說明了工程化的重要性。

從0開始的話，我建議大家先要站在工程化的高度來布局整個項目架構(gòu)。當(dāng)然，如果有了沉淀，我們只需將過去成熟的方案制作成CLI腳手架甚至是鏡像，后面開發(fā)只需拉取之前的工程化項目，直接從1開始開發(fā)。首先我們要有規(guī)范，規(guī)范怎么定？可以學(xué)習(xí)借鑒開源項目，比如Taro，官方文檔中就推薦了開發(fā)規(guī)范，從工程化的角度，我們至少要引用一種代碼掃碼工具，如Lint，通過配置文件將我們制定的規(guī)范應(yīng)用到項目中；甚至還可以通過一些配置來統(tǒng)一代碼開發(fā)工具，如EditorConfig等；其次模塊化，組件化這部分，如果我們沒有自己的沉淀可以直接借助第三方開源的成熟方案，比如引用第三方UI庫加以定制化，模塊化、組件化具體體現(xiàn)在代碼結(jié)構(gòu)、項目目錄結(jié)構(gòu)。最后適當(dāng)加些自動化測試、自動部署、實時監(jiān)測等，使得前端項目工程化。理想化的前端工程化，是我只要安裝一個腳手架，通過運行腳手架中定義的某些命令就能生成直接可用的項目，再開發(fā)的時候只需注重業(yè)務(wù)。比如攜程之前開源的CRN，甚至修改了React Native底層，做了性能優(yōu)化，內(nèi)部再實現(xiàn)了豐富的命令可以在初始化項目的時候?qū)⑴涮椎腢I、測試、打包部署等工具集成進來，比如之前接觸到的粵省事腳手架 weshop，包括現(xiàn)在那些開源的框架比如Taro、Hipy等等，基本上都或多或少實現(xiàn)了工程化。那接下來，我們也實現(xiàn)一個簡單的腳手架，初始化時直接拉取某個項目代碼。

一個簡單的模板拉取小工具 - cliclicli

實現(xiàn)的功能簡單到不能再簡單，就是從git上拉取項目；卻是前端工程化不可或缺的一環(huán)，就像前面提到的，我們有了沉淀，將成果托管在我們的git私服和npm私服上，通過拉取整個項目快速運用到新的項目中； 如果更完善的話，我們沉淀的成果隨著項目的累積可以不斷的優(yōu)化、提煉。核心代碼就是拉取項目寫入本地。之前接觸的粵省事就是這種開發(fā)方式，工具非常完善，一行命令就把之前積累的一些工程化成果呈現(xiàn) 出來，一行代碼不用寫就能跑起一個完整的小程序。類比一下，同樣，現(xiàn)在我們只執(zhí)行幾行命令，一個clicli視頻APP就出具雛形。當(dāng)然，前端工程化是需要大家共同積累的，也不僅僅局限于前端。講到現(xiàn)在，不知道 大家對我所講的會不會有什么意見。是不是都以為我會講怎么擼代碼？我不知道負責(zé)web和管理端的前端同事以及其他后端同事有沒有去了解過APP端的項目代碼，我認為大家不要拘泥于某一個框架或者某一種語言， 其實項目工程化對我們都提出了新的挑戰(zhàn)。就比如，前端開發(fā)也有必要了解shell、熟悉Node.js,盡管是一個個的小細節(jié)，需要我們大量的經(jīng)驗積累！

我在拉取模板的時候遇到了點點差錯—git clone速度慢，一般來說如果是內(nèi)網(wǎng)gitlab和npm的話是不存在這個問題的。解決方案是修改host文件，添加到git一些域名解析并刷DNS。另外還犯了個常識性的錯誤，開發(fā)目錄不能有中文路徑！通過目錄結(jié)構(gòu)我們可以看出這是一個簡單的業(yè)務(wù)實現(xiàn)，component下放的是頁面（也可認為是業(yè)務(wù)模塊）；wdiget下面放的是組件，如果有了解過flutter，那一定對wdiget不陌生。因為頁面簡單，沒有進行路由拆分，也沒有對網(wǎng)絡(luò)請求層做詳細封裝，但二次封裝了播放器、Icon。

如果模板項目中工程化程度比較高的話，那我們基本可以直接得到一個最小可用的應(yīng)用，包括測試、打包、發(fā)布、部署等，基本都以一行命令或者自動完成。

后記

現(xiàn)在回顧之前的內(nèi)部分享，也不知道最后自己究竟講了些什么，完全是無厘頭的瞎比比，技術(shù)不達標可能就是這樣的現(xiàn)狀吧！

如果本文對您有啟發(fā)，歡迎評論區(qū)探討，也感謝各位在評論區(qū)多多指教！

JavaScript React 移動APP

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。