由于前段時(shí)間開發(fā)出來的vue版本的聊天頁，性能、用戶體驗(yàn)等方面十分不盡人意，故開啟了新的征途，nvue版本聊天頁的開發(fā)。

痛點(diǎn)一、進(jìn)入頁面保持在最底部

這次重構(gòu)nvue版本的聊天頁，使用了標(biāo)新立異的渲染方式。眾所周知，前端渲染頁面都是由上而下渲染的，那么如果需要進(jìn)入頁面的時(shí)候，便保持在頁面的最底部，就需要等待頁面渲染完畢后跳轉(zhuǎn)至最底部。這樣的渲染方式就會(huì)導(dǎo)致在進(jìn)入頁面時(shí)，用戶能很明顯的感受到頁面抖動(dòng)了一下（可能多次）。
所以此次重構(gòu)，博主選擇將整個(gè)頁面旋轉(zhuǎn)180度，原本的最頂部，變成了頁面的最底部，進(jìn)入頁面無需滾動(dòng)到最底，用戶視角里頁面會(huì)固定在底部，且渲染消息是自下而上渲染。具體css代碼如下：

/* 由于nvue中不支持全部的css，需要將這段樣式寫進(jìn)對(duì)應(yīng)dom元素的style上 */ direction: rtl; transform: rotate(180deg); -ms-transform: rotate(180deg); -moz-transform: rotate(180deg); -webkit-transform: rotate(180deg); -o-transform: rotate(180deg);

痛點(diǎn)二、進(jìn)入頁面有長(zhǎng)時(shí)間白屏

原先的vue版本聊天頁，在進(jìn)入頁面時(shí)，會(huì)有長(zhǎng)時(shí)間的白屏。后來博主將其中onLoad鉤子中所做的大部分計(jì)算操作，轉(zhuǎn)移到onReady中，白屏?xí)r間也優(yōu)化了蠻多。
現(xiàn)在nvue版本的聊天頁，使用uniapp原生的頂部導(dǎo)航欄，渲染速度快，不會(huì)出現(xiàn)白屏。具體配置在pages.json中。

{"path": "pages/xxx/xxx","style": {"titleNView": {"autoBackButton":false,"buttons": [{"float":"left","fontSize": "46rpx",// iconfont自定義按鈕寫法"fontSrc": "/style/iconfont/iconfont.ttf","text": "\ue61d"},{"float":"right","fontSize": "46rpx","fontSrc": "/style/iconfont/iconfont.ttf","text": "\ue68d"}]},"transparentTitle": "none","navigationBarTextStyle": "xxxx","navigationBarTitleText": "xxxx","navigationBarBackgroundColor": "xxxx"} }

痛點(diǎn)三、彈出鍵盤，切換表情框頁面閃動(dòng)嚴(yán)重

在原先的vue版本聊天頁中，彈出鍵盤，切換表情框會(huì)導(dǎo)致頁面需重新計(jì)算彈出軟鍵盤或表情框后頁面的位置（保持用戶在看的消息的位置）。
在對(duì)聊天頁進(jìn)行180度顛倒渲染后，彈出鍵盤、表情框的時(shí)候，就無需對(duì)其頁面的位置去做重新計(jì)算了，但需要在彈出鍵盤、表情框的時(shí)候，撐高底部欄。比如寫個(gè)計(jì)算屬性computed：

<template><!-- 滾動(dòng)區(qū)域 --><scroller>xxxx</scroller><!-- 底部區(qū)域 --><div :style="footerHeight"></div> </template> <script> export default {computed: {footerHeight() {if (彈出鍵盤) {return `${鍵盤高度}rpx`;} else if (彈出表情框) {return '450rpx';} else {return '0';}}} } </script>

痛點(diǎn)四、消息富文本渲染

作為一個(gè)聊天軟件，@人、自定義表情（圖片）、普通文本、鏈接都是需要去做個(gè)性化的自定義。在原本的vue版本聊天頁中，這些事情均交由uParse去處理。
轉(zhuǎn)為nvue開發(fā)后，uParse不兼容，以博主親身體驗(yàn)嘗試來講，只有rich-text組件和mp-html插件能使用上。但是！這兩個(gè)東西都有它的問題，rich-text組件，在ios端設(shè)置其內(nèi)部節(jié)點(diǎn)的樣式會(huì)不生效，已報(bào)BUG；而mp-html插件，首先渲染采用的webview，比weex渲染慢，其次就是iOS端使用該插件，無法加載本地圖片（表情）。
所以博主最后放棄了這兩個(gè)選項(xiàng)，改為planC，自己寫富文本消息解析，通過大致計(jì)算文本的寬度，將文本表情鏈接等拆分成一塊塊元素拼接成一條消息。

痛點(diǎn)五、各種兼容細(xì)節(jié)

使用textarea不能使用auto-height屬性，在iOS端會(huì)導(dǎo)致textarea無法滾動(dòng)。

使用textarea不能使用v-model，盡管綁定v-model在nvue版本的iOS端不會(huì)出現(xiàn)吞字的問題，但是在Android端會(huì)出現(xiàn)無法長(zhǎng)按刪除的問題，所以只能使用value。

textarea組件的blur事件中沒有cursor（光標(biāo)位置）參數(shù)。

nvue中無法使用main.js中掛載的全局變量，需要在頁面內(nèi)再次單獨(dú)引入。

nvue頁面中能直接使用vuex，但是頁面內(nèi)引用的js文件中，無法訪問vuex（訪問的state為初始值）。若需要在其內(nèi)引用的js中也使用vuex，則需要在nvue頁面中，將其$store傳進(jìn)js文件中。

官方推薦nvue中長(zhǎng)列表使用list組件，但是list組件在iOS端下拉加載歷史消息的時(shí)候，存在卡頓的現(xiàn)象，故博主推薦的是使用scroller組件，其配置項(xiàng)跟list一致。

在iOS端和Android端長(zhǎng)按textarea，是不同的表現(xiàn)，iOS端會(huì)彈出鍵盤，而Android端不會(huì)彈出鍵盤，而是彈出上下文菜單。

使用dom.scrollToElement這個(gè)API，設(shè)置其offset值在iOS端和Android端的表現(xiàn)不一致。

下拉加載更多功能在iOS端需要做限制操作，兩次加載更多觸發(fā)的時(shí)間差最好不小于1.5s，因?yàn)閕OS端滾動(dòng)有回彈的效果。

總結(jié)

其實(shí)還有很多細(xì)節(jié)點(diǎn)的問題，比如樣式問題等沒有羅列出來。繼續(xù)加油，keep learning…

總結(jié)

以上是生活随笔為你收集整理的uniapp聊天页nvue开发踩坑记录的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。