摘要：使用值來作路由。原生應用本身就是多頁的場景，頁面間狀態的隔離比共享更重要一些。使用開發的是原生應用，頁面棧的管理使用的也是原生的特性，沒有但是有模塊可以實現頁面的前進和后退等操作。

系列文章的目錄在 ? 這里

（由于 我比較懶 最近一段時間在忙其他事，系列文章拖了好久終于又更新了。。。）

什么是 vue-router ？

vue-router 官方文檔

vue-router 是針對 Vue.js 開發的前端路由工具，可以很方便的開發單頁應用。

單頁應用

單頁應用的概念其實很早就出現了，它是指在同一個頁面內包含了應用的所有功能，一個頁面就是一個應用，整個應用只有一個頁面，是在 Web 場景下提出的一種開發方式。單頁應用的特性在文末討論，這里先說用法。

怎么在 Weex 里引入 vue-router

vue-router 是以 Vue.js 插件的形式存在的，使用前必須要引入 Vue.js。因為 WeexSDK （>= 0.9.5）中已經包含了 Vue.js Runtime，所以不需要再引入一遍 Vue.js ，只需引入 vue-router 并注冊即可：

// import Vue from "vue"
import VueRouter from "vue-router"

Vue.use(VueRouter)

使用 vue-router 的例子 定義根視圖

通過在模板中添加 的方式定義路由出口，路由匹配到的組件將會替換這個標簽。

在模板中也可以包含其他標簽， 也可以是其他標簽的子標簽，和其他標簽的用法是一樣的；在 vue-router 的內部實現中，router-view 的實現就是一個普通的函數式組件。

配置路由規則

在向應用中注冊 router 之前，需要先創建路由實例，并且配置路由規則。

// router.js

import VueRouter from "vue-router"
import HomeView from "path/to/HomeView.vue"
import AboutView from "path/to/AboutView.vue"

Vue.use(VueRouter)

export default new VueRouter({
  routes: [
    { path: "/home",  component: HomeView  },
    { path: "/about", component: AboutView }
  ]
})

上述代碼中創建了 VueRouter 的實例，并且傳入了 routes 配置，當路徑是 home 時，頁面就會跳轉到 HomeView 組件，HomeView.vue 就會渲染到 App.vue 中 標簽的位置。同理，當路徑是 about 時，頁面就會跳轉到 AboutView 組件。

給應用注入路由功能

想要在應用中注入路由功能，還有給入口組件添加 router 屬性，使應用和路由建立聯系。

import App from "path/to/App.vue"
import router from "path/to/router.js"

App.el = "#root"
App.router = router

new Vue(App)

注意事項

前邊提到過，單頁應用是在 Web 場景下提出的一種開發方式，它的具體實現依賴了 Web 平臺的功能，如 Histroy API 和 URL Hash 等特性。然而 Weex 的運行環境不只是瀏覽器，通常是以移動端原生環境為主，這些特性在 Weex 中并不完全適用，參考《Weex 和 Web 平臺的差異》。

針對這些平臺差異，有以下兩點需要注意：

路由模式

在 vue-router 的配置項中，有一個 mode 參數可以用來指定 vue-router 的運行模式。

hash: 使用 URL hash 值來作路由。默認模式。

history: 依賴 HTML5 History API 和服務器配置。查看 HTML5 History 模式。

abstract: 支持所有 JavaScript 運行環境，如 Node.js 服務器端。

根據平臺差異可以看出，在 Weex 環境中只支持使用 abstract 模式。 不過，vue-router 自身會對環境做校驗，如果發現沒有瀏覽器的 API，vue-router 會自動強制進入 abstract 模式，所以 在使用 vue-router 時只要不寫 mode 配置即可，默認會在瀏覽器環境中使用 hash 模式，在移動端原生環境中使用 abstract 模式。 （當然，你也可以明確指定在所有情況下都使用 abstract 模式）

編程式導航

vue-router 支持使用 創建導航鏈接，不過在其中使用了基于 DOM 事件的一些特性，這些特性在 Weex 原生環境中并不能很好的工作。所以 在 Weex 中，你必須使用編程式導航來編寫頁面跳轉邏輯。 用法參考 Weex 官方文檔。

更多功能

除了上述最基本的特性以外，vue-router 還有很多很強大的功能，具體使用方法建議參考其官方文檔，這里不再贅述。

動態路由匹配

嵌套路由

編程式導航

重定向和別名

導航鉤子

過渡動效

實際項目中的 vue-router

在 weex-hackernews 項目中使用了 vue-router 做路由管理。

路由配置

其中表頭的五個一級菜單（Top 、New 、Show 、Ask 、Job），就對應了五個不同的路由路徑，也對應了五個列表組件。除此之外，還有列表頁、評論頁、用戶信息頁也都對應了多帶帶的路由路徑。具體配置在 src/router.js 中，如下所示：

export default new Router({
  routes: [
    { path: "/top", component: createStoriesView("top") },
    { path: "/new", component: createStoriesView("new") },
    { path: "/show", component: createStoriesView("show") },
    { path: "/ask", component: createStoriesView("ask") },
    { path: "/job", component: createStoriesView("job") },
    { path: "/article/:url(.*)?", component: ArticleView },
    { path: "/item/:id(d+)", component: CommentView },
    { path: "/user/:id", component: UserView },
    { path: "/", redirect: "/top" }
  ]
})

其中 article 、item 和 user 三個配置項中用到了動態路由匹配，把所有同類路由都映射到了同一個組件上，組件結構相同，但是參數是不同的（url 不同或者 id 不同）。

在最后還配置了路由重定向，將默認根路由 / 重定向到了 /top，默認加載“最熱”文章列表。

在應用中注冊路由

若要應用組件和路由之間建立聯系，需要給入口組件注入 router 屬性。代碼在 src/entry.js 中。

new Vue(Vue.util.extend({ router }, App))

router.push("/")

代碼在創建 Vue 實例前在 App 上添加了 router 屬性，使得應用組件中都能通過 this.$router 獲取到路由數據。在創建實例后，手動調用 router.push("/") 跳轉到根視圖。

同步 Vuex 和 vue-router 的狀態

使用 vuex-router-sync 可以很方便地同步 Vuex 和 vue-router 的狀態，這個步驟并不是必須的，但是可以簡化代碼的使用。實際代碼在 src/entry.js 中，如下所示：

sync(store, router)

代碼的效果就是注冊了 store.state.route 這個變量，使得在 Vuex 的 Store 中可以獲取到 route 對象，這在一些比較復雜的大型應用中可能會用到。

由于在根組件中已經注入了 router 屬性，在所有組件中也都可以通過 this.$router 獲取到當前的路由狀態。

Weex 適合寫單頁應用嗎 ？

以下是我個人的觀點，不代表任何人，也不代表 Weex。

不考慮技術細節，從實際應用的角度聊一下我對“單頁應用”的看法。

單頁應用也有不少的優勢和缺陷：

優勢：頁面無需刷新；可以實現更好的過渡效果；組件復用；狀態共享。

缺陷：初次加載白屏時間長；不利于 SEO；有大量全局狀態；技術方法相對復雜，有學習成本。

大部分特性都已經有共識，我也不再展開對比，這里著重討論一下在 移動端 和 Weex 平臺 中使用單頁應用的情況。

頁面間狀態的共享與隔離

單頁應用運行在同一個 javascript runtime 里，也就是說頁面的狀態都是共享的，環境變量也是相同的，這一點其實是有很多隱患。在移動應用中，單頁應用不僅耗費內存，也很容易發生內存泄露。

所有的 Weex 頁面，無論是基于 Vue 還是 Rax，都共用一個 Weex Runtime，其中的 js 引擎也只初始化一次，除非重新初始化 Weex SDK（應用重啟），所有頁面對環境的操作痕跡都將保留。在這種情景下，頁面間狀態的隔離就尤為重要，共享的全局狀態很可能會成為內存泄露的元兇。

換句話說，如果某個頁面創建了一個臨時的全局變量，但是在頁面退出后沒有清除，這個變量將一直保留在內存中；如果某個頁面在全局狀態上掛載了某個屬性，但是頁面退出后沒有斷開連接，這個屬性也會一直保留在全局狀態中。

原生應用本身就是多頁的場景，頁面間狀態的隔離比共享更重要一些。

資源加載和緩存

單頁應用要把所有頁面用到資源（至少是腳本）提前打包在一起，一次性全部發到客戶端，首次打開的網絡耗時會比較久，容易導致長時間白屏，很難遞進的加載資源，無法做到“先加載有用的”。如果有多個單頁應用都需要用到某些頁面或者某個組件，是很難復用的，也很難加緩存，難不成整個移動應用都寫成一個大“單頁”的嗎？ Web 上或許可以考慮，但是原生應用里十分不建議這樣做。應用都規模越大，這些缺陷就越明顯。

更何況現在 HTTP/2 逐漸普及，有了多路復用，把資源粒度劃分的細一些更有利于瀏覽器的加載。還有 prefetch 和 preload 這種特性可以提升資源加載的效率，Weex 也在考慮支持。瀏覽器也逐漸開始支持 ES6 module，可以直接通過