您好,登錄后才能下訂單哦!
今天小編給大家分享一下如何制作唱吧小程序的相關知識點,內容詳細,邏輯清晰,相信大部分人都還太了解這方面的知識,所以分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后有所收獲,下面我們一起來了解一下吧。
大家都說小程序體驗好,即開即用,和普通Webview渲染的H5相比頁面啟動速度、流暢度等方面好很多,這個問題我認為需要從幾個方面考慮,首先,拋開產品業務層面的設計和優化,就是小程序底層框架的設計和實現方面的特點。
當我們新建或打開一個小程序項目(以唱吧比賽小程序為例),即可看到如下圖的項目結構。
小程序入口文件為app.js, 全局樣式文件為app.wxss,全局配置文件為app.json, 每個頁面中再分視圖wxml,wxss和邏輯js、文件配置json等,從這里我們可以看出,整個小程序的上層框架,也就是大體分為視圖層和邏輯層兩個部分。
小程序采用的MINA框架,View層主要用來渲染頁面結構,App Service層用來邏輯處理、數據請求、接口調用,它們在兩個線程里運行,整個小程序是只有一個App Service的,并且整個小程序的生命周期內它是常駐內存的。View層主要使用WebView渲染,而App Service邏輯層是使用JSCore運行。
通信方面,View和AppService是雙線程通信的,主要通過系統層的JSBridage進行通信,AppService把數據變化通知到View,表現方法也就是setData方法,觸發View頁面更新,View把觸發的事件通知到AppService進行業務處理。
這里要說的是,小程序是沒有DOM結構的,那么視圖層的渲染是如何做到的呢,就是運行環境中會把pages中的WXML的節點樹結構,轉化為JS的對象,進行渲染,這也是小程序體驗優于普通分享頁面的一大原因,省去了很多關于瀏覽器DOM的操作,由JS運行環境之間進行渲染解析。
那么話說回來,基于良好的框架,這次在搭建唱吧小程序底層的時候,我們其實做了哪些事情呢。
首先,我們并沒有進行純Native層的搭建和改造,而是對上述提到的API層的一次的封裝,尤其是在關于網絡請求的改造和小程序啟動的登錄流程方面,我們前端團隊嘗試去做一些分層和優化。
網絡請求方面
首先網絡請求優化方面,微信提供的請求接口基本長這樣:
wx.request({ url: 'test.php', //僅為示例,并非真實的接口地址 data: { x: '' , y: '' }, header: { 'content-type': 'application/json' // 默認值 }, success: function(res) { console.log(res.data) }})
是不是感覺和之前的某種請求模式很像,沒錯,就是古老的$.ajax,這時候我們又想起了ajax的回調地獄,如果頁面的請求很多,請求的順序還有限定,瞬間又是各種嵌套,可以說是要從請求到懵逼了。
所以為了解決回調地獄和同時優化請求代碼邏輯,我們在封裝wx.request的同時,我們在小程序開發中,引入了async/await語法糖,用到了來自facebook的regenerator模塊(詳情請戳:https://github.com/facebook/regenerator),async、await函數經babel編譯后,再用regenerator-runtime模塊用于提供功能實現,這一方面也得力于小程序支持ES6語法的編譯。
實現過程中,單獨用一個公共方法封裝,返回wx.request的promise
//wechat.js const request = (url,options) => { return new Promise((resolve, reject) => { wx.request({ url: url, method: options.method, data: Object.assign({}, options.data), header: options.header, success: resolve, fail: reject }) })}
之后在我們的上層公共庫中,編寫與請求相關的處理邏輯。
// changba.js const regeneratorRuntime = require('./regenerator-runtime.js')const wechat = require('./wechat')const URI = 'xxx' const requestAPI = async (url,opt) => { const app = getApp() let options = Object.assign({data: {}},opt) if (/^\/api\/(.+)$/.test(url)) { url = URI + url; } if (!options.method) { options.method = 'POST'; } let header = { 'Content-Type': 'application/x-www-form-urlencoded' } options.header = options.header || header ; //除了login方法 其余接口都要加入sessionInfo也就是后端加密過的session_key if (!url.includes('/checkCode')) { options.data['sessionInfo'] = app.globalData.sessionkey; } let isTimeout = false; try { const ree = await wechat.checkSession(); } catch (error) { isTimeout = true; }; try { if (isTimeout) { let aaa = await login(app); } wx.showLoading({ title: '加載中' }); const res = await wechat.request(url,options) if (res && res.statusCode) { if (res.statusCode != 200) { if (wx.hideLoading) { wx.hideLoading() } wx.showModal({ content: wechat.errMsg(res.statusCode).message || '請求失敗,請重新嘗試', title: '提示', showCancel: false }) } else { if (res.data && res.data.code === 1) { if (wx.hideLoading) { wx.hideLoading() } return res.data } else { // xxx 其他情況業務邏輯處理 } } } } catch (error) { console.log('請求異常信息:' + error) if (wx.hideLoading) { wx.hideLoading() } wx.showModal({ content: '請求信息異常', title: '', showCancel: false }) }}
上述封裝過程中,所以除了考慮到請求超時、檢查用戶身份等操作,還可以加入session過期等相關其他的業務處理邏輯,這也是自己搭建請求的好處,針對自己的業務需求,進行匹配和改造。
然而在經歷這樣兩層封裝之后,在寫業務邏輯代碼的過程中,就可以一目了然的發送請求了,達到邏輯清晰且書寫自如,如果習慣了fetch以及axios的朋友應該都會比較喜歡這種方式。
async getdata() { let self = this; let cb_getdata = await app.changba.requestAPI('/api/xxx', { data: { id: self.data.id } }); if (cb_getdata && cb_getdata.code === 1) { // xxx } }
以上就是“如何制作唱吧小程序”這篇文章的所有內容,感謝各位的閱讀!相信大家閱讀完這篇文章都有很大的收獲,小編每天都會為大家更新不同的知識,如果還想學習更多的知識,請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。