前言##
前端的SPA使用已经有一段日子了，好处是显而易见的，体验感犹如APP中一样如丝般畅滑，嗯，理想状态下~
SPA毕竟需要的资源的比传统开发需要的多，原本JS不像JAVA，有那么高的执行效率，还有以及他为人诟病的DOM，PC,IOS还好，但在安卓下就呵呵哒了。
可以感受一下
心情Ionic-安卓
所以，需要优化下SPA的性能问题，其他像什么SEO的问题不展开讲。
简介##
当然了，在性能问题上，业界也做出了许多尝试，React Canvas 用Canvas替代了Dom渲染View，或是isomorphism，减轻渲染负担巴拉巴拉的。
但是回过头来，再看一下，js之上，还有个webview，原来都是依赖于客户机中的浏览器，所以没有将关注点转移到这里。还是大有文章可作的，正如cross-walk一样，改善效果还不赖，前提是你无视安装包大了几十M。。。
所以，本文将介绍的方案目标是让他既有SPA的优点，又能避免SPA性能问题。
因为涉及到原生层，所以只适用于APP开发，好处是其他层的方案可同时实施互不冲突
如何模拟SPA##
SPA特性都有啥，谁说对了，就给他~
1.统一的状态管理入口
2.转场无闪屏
--第一点
好处 ： 开发爽，节省流量,不需要总是从网络层存储获取数据......好处一堆，不展开讲。。
----传统----
而在传统页面开发中，没有统一状态入口，转场的时候需要保留数据在input，才能还原现场，但也做不到管理全状态 : (
----SPA----
有了SPA后么，哼哼~但SPA实现存储数据不是没有代价的，大量的数据造成的资源消耗也不小哦。
----原生----
在原生中有没办法更好的实现个特性呢？很容易想到利用Localstorage，Sqlite啥的去存储，既然在原生层，直接使用了Sqlite。
但是因为总要频繁的parse json甚至性能会更差，GG~
友军：别这么快打出GG还没到15分钟呢！要知道现在数据可是在原生层，他同时带来了另外一个特性，无视多Webview+998,（：这特性这有个鸡毛用啊!!!）,莫急，再来看看第二点。
--第二点
好处 ： 假装自己是APP可以多要点钱 （大雾）
----传统----
传统开发 无法实现，蟹蟹。
----SPA----
原理其实跟TAB组件没差，多点状态管理而已。嗯，假装自己是APP后，转场可轻松了，也就是安卓下按个几百下没反映而已，
----原生----
涉及到View渲染，原生层好像帮不上忙呀，在线等，急。
拨打一发场外求出电话，来看看React Native，Mui都做了些什么~什么，Webview当标签！
App Bar，Footer Bar是用单个Webview写，内容再来一个Webview，利用原生做动画，完美转场，这波不亏。
但这种方案他有点小毛病，如果你这没有头尾部不是没什么用啦？
人有多大胆，地有多大产，Webview既然能当Tag，那直接当Page也可以呀。(本身就是)。
等等，多WebView？当当当，无视Webview选手入场，我们只需要在转场的时候把数据同步到sqlite，到新页面再拉取下来，因为只有一次parse，原生存储这时反而成了优点了，interesting~
方案：WebView模拟转场动画，一级路由为Page，二级路由为Tag，原生数据存储
优化点：转场动画更流畅
多页面带来的性能问题##
嗯。。用Chrome打开30个网页试试
Webview过多
1.后台Webview很多
2.可以看到二级路由的数量占据了大部分
3.多次跳转相同页面会多次创建
4.远离历史栈的WebView，用户很可能是达不到的
解决
1.隐藏后台Webview，类似display:none
2.砍掉这二级部分，只保留模拟一级路由的部分。
3.给个Page_ID，复用该Webview
4.重写历史栈， 设置最大值
具体实施
要实现以上方案要解决的问题也不少：
1.即使是Java写display:none也会有坑的。。比如刚出来你会发现图片特别不清晰，当然这里的职责是原生的~
2.要对一二级路由做特殊处理，光这复杂度就不低，首先你得了解改写路由框架，Angular，Vue，React等等不同框架的路由还不太一样（除非你不用前端路由 ）
3.4要结合起来看，他是一个整体的流程：
复用~很有意思，如果是history.go(-1)，很简单，从历史中找到之前的对应的Page_ID，无脑复用（因为页面附带的Status不需要改变）。但如果是新闻详情呢？那样复用前还得填充Status。。。换种思路，可以把跳转这样抽象：
(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 ，比如说你不能页面后退的时候还填充了空的Status，导致Sroll又回到顶部了，显得很蠢~
Save，Flush操作上类Flux(Redux，Vux)，会简单很多。
``
b,c步骤 一旦有了类Flux和前端路由，b,c步骤就很清晰了，只要注意达到最大值的时候，RouteManager要先加载替换掉历史最远处对应的Page-Webview（第4点）
结论：改写后的RouteManager负责跳转创建替换Webview(1级路由)或是Html(2级路由)，StatusManager 负责渲染数据
结尾##
在项目中使用过一次，效果有是有，但相对于成本来说，还是差强人意（应该不是这意思，想不到词了:>）。
毕竟就为了一个一级路由的转场动画，要写辣么多东西~
具有侵入性，还只能再APP中用，方案也不成熟，有好些没考虑到的点，比如加载第三方页面的处理等等。。。
下篇文章我还是在其他层面做尝试吧。。
