對于微信端來說，其實使用ionic是一個比較大的前端框架。

有更多比較輕量化的前端框架可以選擇。

但是使用ionic有一個明顯的優點就是，能夠做到一端開發，三端同步上線。

這個梗說了好多遍了，但確實是這樣子的，ios和安卓都能跑了，為什么在公司的微信公眾號，還要再重新開發呢。

這就是我一開始研究這個解決方案的初衷。

其實在這個方向的研究目的并不是要在性能上達到一個很好的高度，而是在首頁打開速度上要取得明顯的時間優勢。

最開始使用requestjs把所有的文件壓縮打包成一個文件，這個方案在項目還很小或者說還不是很大的時候，

將多文件小文件壓縮成少文件較大文件，確實較少了網絡下載請求的時間同時也變相的提速了開始應用的時間。

但是當項目中加入了微信授權，這個過程會增加3秒左右的進入首頁的時間。

然后當項目越做越大，被壓縮后的文件越來越大，使得網絡下載時間增加，

從點擊鏈接，進入頁面，開始下載文件，下載完成，進行微信授權，授權完成頁面跳轉回來，再加載緩存文件（可能還重新下載），最后啟動項目，進入首頁。

這樣一個過程，像我們公司項目比較大的時候，在安卓端（以下說的時間基本上都是指在安卓手機上的時間，在ios上，只要不是網絡問題，都挺快的）需要24-37秒鐘。

當然這個24秒還包含了在首頁加載太多的業務的關系。反正我剛接手的時候是這個時間。

一開始我的嘗試優化的方案是把微信授權的文件和主體的文件分離，首先下載一個小文件，進行微信授權，授權完畢，回調回來再下載大文件。（這個過程是同事實現的。）

調整首頁的業務，和產品協商有哪些業務可以從首頁中移到別的頁面去。

最后重構了業務邏輯代碼，把跟首頁無關的業務封裝到獨立的服務里面。（我接手的時候很多全局通用的服務都使用$rootscope實現，這里也需要提醒大家一下）

這樣一套調整優化之后，同一個測試設備上，從點擊鏈接到進去首頁的時間是8-10秒。

最后甚至去掉了微信授權，先讓用戶進入首頁，再需要用戶信息的時候再進行授權，時間還是5-10秒

有了明顯的優化。

但是微信3、5、8原則，不知道大家有沒有聽過這個原則，就是說頁面打開時間在3秒5秒8秒的時候分別對應了一定的跳出率，雖然說跳出率這種東西不能完全的認為就是這個問題引起的，但不可否認的是有一定的影響因素在里面，主要是營運指標，就拿這個說事，那就不得不改了。

在經過了一階段的重構代碼，之后，并不能顯著的加快啟動速度。

因此我決定放棄重構，項目重做。

這次重做涉及的項目還比較多，web端，pc官網，獨立活動地址，還有sdk等等項目都要考慮在內。

不止要滿足現在的指標，還要滿足在公司發展的道路上，web端不再是能被提到臺面上的短板。

整體的前端架構設計基本上完成了，這個有需要的話，后面也會分享給大家。

首先我新建了一個ionic的tab類型的項目，放到微信中，在同一個設備上，從點擊鏈接到進入首頁的時間是3秒鐘。

ionic在安卓設備的微信端真的不是很優，空白項目也要3秒鐘，那我們加了這么多圖片這么多請求和業務，8秒看起來也挺好了。

我是這么想的，既然小項目的啟動時間會更快，那為什么不把大項目拆成若干個小項目呢？

這里我就考慮了按需加載，這個我在之前的教程中就已經有提到了，在ionic入門教程第四課-使用$controllerProvider按需加載controller

這里我說的比較簡單，也只是按需加載了controller文件，只是為了作為一個技術上的演示而已。

里面還提到了requestjs技術，這里先不提。我們純粹的來看看按需加載。

先說說簡要的思路，就是在開啟項目的時候，只加載首頁的相關文件，然后啟動項目，再切換界面的時候再去下載新的界面。

把所有的文件細分，獨立壓縮，減小下載的流量。

這里需要處理幾個問題，或者說是技術難點，也行。。。

1、所有的文件要支持按需加載

2、文件相關性怎么實現

3、文件獨立壓縮

決解方案：

1、所有的文件要支持按需加載

app.controller = $controllerProvider.register; app.directive = $compileProvider.directive; app.filter = $filterProvider.register; app.factory = $provide.factory; app.service = $provide.service; app.constant = $provide.constant; app.value = $provide.value; 2、文件相關性怎么實現

走配置表的形式

3、文件獨立壓縮

使用grunt（使用gulp好像也行，還沒去研究）

注：app.controller = $controllerProvider.register這個東西我們在第四個中有提到，其他的東西都更這個差不多，都是框架自帶的懶加載的決解方案。 方案和思路說的差不多了，接下來看看怎么實現吧。我這里新建了一個tab類型的ionic項目，來作為演示。 關于項目名字，大家別太在意，我新建的時候隨便敲的，要說我騷氣，也行。 首先我們要把新建項目里面的controllers和services文件，里面的內容分離，之前我在第三課中講過了使用requirejs分離controller文件和server文件，這里我們不適用requirejs。 首先我們先在app.js里面定義懶加載服務。這樣我們就可以全局的只用它們，而不再需要再在單文件里面引用注入服務。 請仔細看圖。圖中說明的很清楚了。注意在1標注的位置要把angular.module()返回的對象存起來，在2標注的位置需要使用這個對象。 然后拆分controllers文件和services文件，首先新建一個文件夾controller，里面新建一個文件AccountCtrl.js 然后在controllers中把AccountCtrl的內容復制出來 修改頭部 這里也需要注意標注2這里使用的app.controller其實是使用了$controllerProvider.register，這里直接使用$controllerProvider.register也可以，但是要保證存在$controllerProvider這個服務。所以我在app.js里面定義了。 嗯這個分離的過程很簡單，我故意提出來說，其實細心的朋友應該能夠發現，我在拆分這些文件的時候，并沒有關注過這里面實現的業務，只是把文件復制過來修改了頭部。也就是說，不管你的項目之前是用什么方式開發的，要使用我提供的這個方案，修改起來也很容易，而且不容易出錯。 同樣的拆分其他的控制器，將controllers文件拆分成 同樣的方法拆分服務，需要注意的是服務使用的不是app.controller，而是app.factory 到此完成了第一個問題，文件拆分，并讓它們符合懶加載的規范。 接下來處理第二個問題，配置表。 首先我們新建一個文件config.js放在那都行。 使用$provide.constant來定義了一個靜態變量，在1圖中我們已經說過了需要導入這個’JS_REQUIRES‘ 這里我還多做了一個優化，把業務相關聯的文件按照界面寫成分組，這樣在代碼中就不用把太多的精力放在文件關聯上。 所有的關聯都在這個配置表里面實現 就是把我們第四課中提到的這個文件地址寫到配置里面，這樣子在代碼中就只需要關注這個幾面關聯的模塊，而不是模塊的所有文件。 這也算是一種簡化的模塊化。 上圖是第四課中的寫法，我們這里使用類似但不相同的寫法。第四課中是使用require和$q的組合實現的， 這里我們使用的是oclazyload和$q的組合實現。 首先在路由中的定義類似。這里提供了兩種方案，一種只關聯少量文件的，可以寫上所有的文件，第二種關聯文件較多的時候，寫上關聯的模塊名稱。 上面那個地方如果是兩個文件的話可以寫成loadSequence('ChatsCtrl','ChatsService')。 暫不支持模塊和文件混合的方式。需要的朋友可以自己修改一下loadSequence方法，判斷如果寫的key在模塊中匹配不到就去匹配單文件。 到此本次方案基本上都實現了，在瀏覽器中運行查看。 首次加載的時候只加載需要的文件，切換頁面再加載其他文件，表現與預期設想相同。 用這個方案在我們公司的項目中做過測試。在文件壓縮之后，在同一個測試設備上，從點擊鏈接到進入首頁，首次加載時間為3-5秒，再次加載時間為1-2秒。 而且還有一個明顯的好處，不管后續項目的復雜度提升多少，都不會嚴重的影響這個時間。 上圖中還有一個需要關注的地方，就是html文件并不是按需加載的。這個可能是我接下來需要要研究的內容。 還有就是單文件壓縮，配置表管理會變得非常的繁瑣。可以考慮用requirejs把這些小模塊按照獨立的小模塊做一個個單獨的打包。 這些東西都是這個方案可以繼續前進的方向。希望高手能跟我一起完善它們。 至于第三點獨立打包，是使用了grunt的grunt-contrib-uglify插件，用法很容易的，大家百度一下就好。有不懂得話，我后續單獨出一個將這個單獨打包的教程。 由于篇幅問題，我這里就不詳細說明了。 看到好多的博客文章的結尾都會放上兩個支付的二維碼，還寫著博主很辛苦請博主喝杯咖啡。我也好想丟兩個給大家掃一掃，但是我又覺得這錢太少了，沒什么興趣。嗯？有需要合作的可以小窗聯系我。培訓質詢什么的，你懂的。當然找我質詢其實是免費的。我在想要是回答收費，那我可以辭職回家了。哈哈 項目Demo地址：http://pan.baidu.com/s/1i4Qmkz7如果你還有什么其他的問題,可以通過以下方式找到我新浪微博:小虎Oni 微信公眾號:ionic__
有其他問題的可以關注一下公眾號提問(右側雙下劃線)：ionic__還是那句公眾號暫時沒人維護。

轉載于:https://www.cnblogs.com/xiaohuoni/p/7642295.html

總結

以上是生活随笔為你收集整理的ionic入门教程第十六课-在微信中使用ionic的解决方案（按需加载加强版）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。