前言##
前端的SPA使用已經(jīng)有一段日子了程奠，好處是顯而易見(jiàn)的芋膘，體驗(yàn)感猶如APP中一樣如絲般暢滑，嗯衙四，理想狀態(tài)下~
SPA畢竟需要的資源的比傳統(tǒng)開發(fā)需要的多铃肯，原本JS不像JAVA，有那么高的執(zhí)行效率届搁，還有以及他為人詬病的DOM缘薛，PC,IOS還好窍育，但在安卓下就呵呵噠了卡睦。
可以感受一下
心情Ionic-安卓
所以，需要優(yōu)化下SPA的性能問(wèn)題漱抓，其他像什么SEO的問(wèn)題不展開講表锻。
簡(jiǎn)介##
當(dāng)然了，在性能問(wèn)題上乞娄，業(yè)界也做出了許多嘗試瞬逊，React Canvas 用Canvas替代了Dom渲染View，或是isomorphism仪或，減輕渲染負(fù)擔(dān)巴拉巴拉的确镊。
但是回過(guò)頭來(lái)，再看一下范删，js之上蕾域，還有個(gè)webview，原來(lái)都是依賴于客戶機(jī)中的瀏覽器到旦，所以沒(méi)有將關(guān)注點(diǎn)轉(zhuǎn)移到這里旨巷。還是大有文章可作的，正如cross-walk一樣添忘，改善效果還不賴采呐，前提是你無(wú)視安裝包大了幾十M。搁骑。斧吐。
所以又固，本文將介紹的方案目標(biāo)是讓他既有SPA的優(yōu)點(diǎn)，又能避免SPA性能問(wèn)題煤率。
因?yàn)樯婕暗皆鷮涌谟瑁灾贿m用于APP開發(fā)，好處是其他層的方案可同時(shí)實(shí)施互不沖突
如何模擬SPA##
SPA特性都有啥涕侈，誰(shuí)說(shuō)對(duì)了沪停，就給他~
1.統(tǒng)一的狀態(tài)管理入口
2.轉(zhuǎn)場(chǎng)無(wú)閃屏
--第一點(diǎn)
好處 ： 開發(fā)爽，節(jié)省流量,不需要總是從網(wǎng)絡(luò)層存儲(chǔ)獲取數(shù)據(jù)......好處一堆裳涛，不展開講木张。识啦。
----傳統(tǒng)----
而在傳統(tǒng)頁(yè)面開發(fā)中燕雁，沒(méi)有統(tǒng)一狀態(tài)入口控妻，轉(zhuǎn)場(chǎng)的時(shí)候需要保留數(shù)據(jù)在input摹恨，才能還原現(xiàn)場(chǎng)印衔，但也做不到管理全狀態(tài) : (
----SPA----
有了SPA后么闺属，哼哼~但SPA實(shí)現(xiàn)存儲(chǔ)數(shù)據(jù)不是沒(méi)有代價(jià)的晚碾，大量的數(shù)據(jù)造成的資源消耗也不小哦蜘犁。
----原生----
在原生中有沒(méi)辦法更好的實(shí)現(xiàn)個(gè)特性呢团赁？很容易想到利用Localstorage育拨，Sqlite啥的去存儲(chǔ)，既然在原生層欢摄，直接使用了Sqlite熬丧。
但是因?yàn)榭傄l繁的parse json甚至性能會(huì)更差，GG~
友軍：別這么快打出GG還沒(méi)到15分鐘呢怀挠！要知道現(xiàn)在數(shù)據(jù)可是在原生層析蝴，他同時(shí)帶來(lái)了另外一個(gè)特性，無(wú)視多Webview+998,（：這特性這有個(gè)雞毛用啊!!!）,莫急绿淋，再來(lái)看看第二點(diǎn)闷畸。
--第二點(diǎn)
好處 ： 假裝自己是APP可以多要點(diǎn)錢 （大霧）
----傳統(tǒng)----
傳統(tǒng)開發(fā) 無(wú)法實(shí)現(xiàn)，蟹蟹吞滞。
----SPA----
原理其實(shí)跟TAB組件沒(méi)差佑菩，多點(diǎn)狀態(tài)管理而已。嗯冯吓，假裝自己是APP后倘待，轉(zhuǎn)場(chǎng)可輕松了，也就是安卓下按個(gè)幾百下沒(méi)反映而已组贺，
----原生----
涉及到View渲染凸舵，原生層好像幫不上忙呀，在線等失尖，急啊奄。
撥打一發(fā)場(chǎng)外求出電話渐苏，來(lái)看看React Native，Mui都做了些什么~什么菇夸，Webview當(dāng)標(biāo)簽琼富！
App Bar，Footer Bar是用單個(gè)Webview寫庄新，內(nèi)容再來(lái)一個(gè)Webview鞠眉，利用原生做動(dòng)畫，完美轉(zhuǎn)場(chǎng)择诈，這波不虧械蹋。
但這種方案他有點(diǎn)小毛病，如果你這沒(méi)有頭尾部不是沒(méi)什么用啦羞芍？
人有多大膽哗戈，地有多大產(chǎn)，Webview既然能當(dāng)Tag荷科，那直接當(dāng)Page也可以呀唯咬。(本身就是)。
等等畏浆，多WebView胆胰？當(dāng)當(dāng)當(dāng)，無(wú)視Webview選手入場(chǎng)全度，我們只需要在轉(zhuǎn)場(chǎng)的時(shí)候把數(shù)據(jù)同步到sqlite煮剧，到新頁(yè)面再拉取下來(lái)，因?yàn)橹挥幸淮蝡arse将鸵，原生存儲(chǔ)這時(shí)反而成了優(yōu)點(diǎn)了，interesting~
方案：WebView模擬轉(zhuǎn)場(chǎng)動(dòng)畫佑颇，一級(jí)路由為Page顶掉，二級(jí)路由為Tag，原生數(shù)據(jù)存儲(chǔ)
優(yōu)化點(diǎn)：轉(zhuǎn)場(chǎng)動(dòng)畫更流暢
多頁(yè)面帶來(lái)的性能問(wèn)題##
嗯挑胸。痒筒。用Chrome打開30個(gè)網(wǎng)頁(yè)試試
Webview過(guò)多
1.后臺(tái)Webview很多
2.可以看到二級(jí)路由的數(shù)量占據(jù)了大部分
3.多次跳轉(zhuǎn)相同頁(yè)面會(huì)多次創(chuàng)建
4.遠(yuǎn)離歷史棧的WebView，用戶很可能是達(dá)不到的
解決
1.隱藏后臺(tái)Webview茬贵，類似display:none
2.砍掉這二級(jí)部分簿透，只保留模擬一級(jí)路由的部分。
3.給個(gè)Page_ID解藻，復(fù)用該Webview
4.重寫歷史棧老充， 設(shè)置最大值
具體實(shí)施
要實(shí)現(xiàn)以上方案要解決的問(wèn)題也不少：
1.即使是Java寫display:none也會(huì)有坑的。螟左。比如剛出來(lái)你會(huì)發(fā)現(xiàn)圖片特別不清晰啡浊，當(dāng)然這里的職責(zé)是原生的~
2.要對(duì)一二級(jí)路由做特殊處理觅够，光這復(fù)雜度就不低，首先你得了解改寫路由框架巷嚣，Angular喘先，Vue，React等等不同框架的路由還不太一樣（除非你不用前端路由 ）
3.4要結(jié)合起來(lái)看廷粒，他是一個(gè)整體的流程：
復(fù)用~很有意思窘拯，如果是history.go(-1)，很簡(jiǎn)單坝茎，從歷史中找到之前的對(duì)應(yīng)的Page_ID树枫，無(wú)腦復(fù)用（因?yàn)轫?yè)面附帶的Status不需要改變）。但如果是新聞詳情呢景东？那樣復(fù)用前還得填充Status砂轻。。斤吐。換種思路搔涝，可以把跳轉(zhuǎn)這樣抽象：
(a).Save prev-status To StatusManager
(b).Get next-webview from RouteManager
(c).Find next-page-status in the StatusManager
(d).Flush status to next-webview
a,d步驟的StatusManager ，比如說(shuō)你不能頁(yè)面后退的時(shí)候還填充了空的Status和措，導(dǎo)致Sroll又回到頂部了庄呈，顯得很蠢~
Save，F(xiàn)lush操作上類Flux(Redux派阱，Vux)诬留，會(huì)簡(jiǎn)單很多。
``
b,c步驟 一旦有了類Flux和前端路由贫母，b,c步驟就很清晰了文兑，只要注意達(dá)到最大值的時(shí)候，RouteManager要先加載替換掉歷史最遠(yuǎn)處對(duì)應(yīng)的Page-Webview（第4點(diǎn)）
結(jié)論：改寫后的RouteManager負(fù)責(zé)跳轉(zhuǎn)創(chuàng)建替換Webview(1級(jí)路由)或是Html(2級(jí)路由)腺劣，StatusManager 負(fù)責(zé)渲染數(shù)據(jù)
結(jié)尾##
在項(xiàng)目中使用過(guò)一次绿贞，效果有是有，但相對(duì)于成本來(lái)說(shuō)橘原，還是差強(qiáng)人意（應(yīng)該不是這意思籍铁，想不到詞了:>）。
畢竟就為了一個(gè)一級(jí)路由的轉(zhuǎn)場(chǎng)動(dòng)畫趾断，要寫辣么多東西~
具有侵入性拒名，還只能再APP中用，方案也不成熟芋酌，有好些沒(méi)考慮到的點(diǎn)增显，比如加載第三方頁(yè)面的處理等等。隔嫡。甸怕。
下篇文章我還是在其他層面做嘗試吧甘穿。。
