## 路由及轉場解決方案
### 路由
這個不用講,和后端的路由原理一樣,即什么地址做什么(這里的做什么就比較復雜了,有做什么決定了怎么渲染頁面)。
* * * * *
### 轉場
我們的任何軟件都在有限的屏幕上運行,每一個功能界面都在這塊屏幕上展現,切換,我們可以把傳統的軟件(手機軟件、桌面軟件)每一個界面間的切換都看做是一個轉場,桌面軟件`Windows`軟件也是轉場,我們每天都在和它們打交道,這種場景我們再熟悉不過,以至于忽略他的東西,現在[web app](http://www.hmoore.net/xiak/quanduan/255922)中出現了,為了提供跟傳統app一樣的操作體驗,現代web應用也引入了這種傳統軟件中的概念 —— 轉場。
> 路由轉場也有叫路由動畫的
* * * * *
[路由及轉場解決方案](https://open-doc.dingtalk.com/docs/doc.htm?spm=a219a.7629140.0.0.YlP1Hp&treeId=177&articleId=104961&docType=1)
更新時間:2016/07/28 訪問次數:8217
SaltRouter 為釘釘微應用提供路由及轉場解決方案。
salt-router基于頁面預加載及轉場效果等原生能力,提供了一套簡明的路由api。
對于目前大部分h5應用,在頁面跳轉時,例如A頁面跳B頁面時,存在以下兩個問題:
* 跳轉到B頁面時,B頁面會有一段時間的白屏
* 跳轉過程生硬,沒有連貫的轉場體驗
salt-fetch通過提供預加載和轉場效果等能力,解決以上這兩個問題,優化微應用轉場體驗:
* 微應用可以根據自身業務,提前預加載下級頁面,在跳轉時便可加載準備好的頁面,避免白屏
* 提供了多種原生級別的轉場動畫效果,使轉場更加連貫,避免生硬的跳轉。

使用方式
~~~javascript
<script type="text/javascript" src="/xx/xx/salt-router.js"></script>
<script type="text/javascript">
window.salt.router.preload({}).then().catch();
</script>
~~~
### 其他
- [瀏覽器加載初探](http://www.hmoore.net/xiak/quanduan/245636)
>[danger] **注意:**測試是否為單頁最好在PC瀏覽器上面看,跳轉新的頁面時**加載狀態**會轉,但是在微信(PC/手機)或者一些手機瀏覽器上面,由于沒有“轉”的狀態,而是用**頁面頂部加載進度條**的表示加載狀態,在手機端即使沒有跳轉頁面(PC瀏覽器上沒看到“狀態轉”),某個單頁需要加載圖片等資源,那么加載進度條還是會有,所以手機上面看不出來到底是跳轉還是單頁。
* * * * *
### 前端路由思考
我們使用的應用都是通過顯示屏展示的,并與其交互的,而在屏幕上,使用應用時,隨著用戶交互,應用的形態都是從一種形態轉換為另一種形態,或者從一個頁面跳轉到另一個頁面上,這些特性,元素,構成了我們日常使用的應用。
這種頁面的形態,不同功能放在不同頁面,之間的切換,轉換,這些形成了一些其它的概念,路由,轉場等等,其實這些東西都是抽象的,包括頁面,什么是頁面呢,頁面就是我們用來描述顯示屏上顯示的那些東西。都是應用給我們的一種呈現。
兩個頁面的切換轉換怎么做呢,一般常見的,就是最粗暴的,A頁面隱藏,B頁面顯示,相互這樣,這兩個動作很快,所以看不出來什么問題,基本不會出現卡頓或者白屏之類的。事實上目前可以說99%的應用都是以這種形態切換頁面的,這里所說的應用不局限于web應用,也包括桌面應用,不管怎么樣,它們都是通過顯示屏顯示的。
而現在一些應用為了做的好看,體驗上更細膩,則在切換頁面上下了不少功夫,比如各種轉場特效,入場和出場特效(顯示屏就是舞臺,頁面就是角色),都是不一樣的,比如B要進場時,A出場淡出,往左傾斜翻轉,B淡入,從右邊傾斜翻轉過來。這樣頁面間切換就不會顯得生硬了,當然這也對硬件渲染要求也較高,現階段web的動畫效果沒有原生動畫流暢,這也是為什么很多人說路由轉場用原生實現好的原因。
而應用形態的轉換也和這差不多,只不過頁面覆蓋的范圍更大,可以這么說, **應用是由一個個頁面組成的,而頁面中又可以有很多個元素。** 當一個頁面元素太多,功能聚合過多,太復雜時,我們就會拆分為多個頁面,以減少頁面的復雜度,并讓功能,操作更合理。
這是在移動端和一些屏幕較小的設備上,應用都是一個頁面一個頁面的,頁面一般占整屏,但是在PC上就不是這樣的,PC上一般是以窗口的形式,比如資源管理器一個窗口,QQ一個窗口,酷狗一個窗口。因為屏幕比較大,所以可以同時放多個窗口一起工作,所以PC端效率比較高,可以做更復雜的操作,總之移動端手持設備和PC端各有優劣,各有自己的特點。
* * * * *
last update:2018-3-26 16:21:48
- 開始
- 微信小程序
- 獲取用戶信息
- 記錄
- HTML
- HTML5
- 文檔根節點
- 你真的了解script標簽嗎?
- 文檔結構
- 已經落后的技術
- form表單
- html實體
- CSS
- css優先級 & 設計模式
- 如何編寫高效的 CSS 選擇符
- 筆記
- 小計
- flex布局
- 細節體驗
- Flex
- Grid
- tailwindcss
- JavaScript
- javascript物語
- js函數定義
- js中的數組對象
- js的json解析
- js中數組的操作
- js事件冒泡
- js中的判斷
- js語句聲明會提前
- cookie操作
- 關于javascript你要知道的
- 關于innerHTML的試驗
- js引擎與GUI引擎是互斥的
- 如何安全的修改對象
- 當渲染引擎遇上強迫癥
- 不要使用連相等
- 修改數組-對象
- 算法-函數
- 事件探析
- 事件循環
- js事件循環中的上下文和作用域的經典問題
- Promise
- 最佳實踐
- 頁面遮罩加載效果
- 網站靜態文件之思考
- 圖片加載問題
- 路由及轉場解決方案
- web app
- 寫一個頁面路由轉場的管理工具
- 談編程
- 技術/思想的斗爭
- 前端技術選型分析
- 我想放點html模板代碼
- 開發自適應網頁
- 后臺前端項目的開發
- 網站PC版和移動版的模板方案
- 前后端分離
- 淘寶前后端分離
- 前后端分離的思考與實踐(一)
- 前后端分離的思考與實踐(二)
- 前后端分離的思考與實踐(三)
- 前后端分離的思考與實踐(四)
- 前后端分離的思考與實踐(五)
- 前后端分離的思考與實踐(六)
- 動畫
- 開發小技巧
- Axios
- 屏幕適配
- 理論基礎
- 思考
- flexible.js原理
- 實驗
- rem的坑,為什么要設置成百分比,為什么又是62.5%
- 為什么以一個標準適配的,其它寬度也能同等適配
- 自適應、響應式、彈性布局、屏幕適配
- 適配:都用百分比?
- 番外篇
- 給你看看0.5px長什么樣?
- 用事實證明viewport scale縮放不會改變rem元素的大小
- 為什么PC端頁面縮放不會影響rem元素
- 究竟以哪個為設備獨立像素
- PC到移動端初試
- 深入理解px
- 響應式之柵格系統
- 深入理解px(二)
- 一篇搞定移動端適配
- flex版柵格布局
- 其他
- 瀏覽器加載初探
- 警惕你的開發工具
- JS模塊化
- webpack
- 打包原理
- 異步加載
- gulp
- 命名規范
- 接口開發
- sea.js學習
- require.js學習
- react學習
- react筆記
- vue學習
- vue3
- 工具、技巧
- 臨時筆記
- 怎么維護好開源項目
- 待辦
- 對前端MVV*C框架的思考
- jquery問題
- 臨時
- 好文
- 節流防抖