uniapp聊天页nvue开发踩坑记录

ㄏ、Forgetˊ

已于 2022-06-15 17:35:12 修改

阅读量2.2k

点赞数 6

分类专栏： # uni-app Vue 文章标签： vue uni-app 前端

于 2021-06-10 10:56:02 首次发布

本文链接：https://blog.csdn.net/weixin_43905402/article/details/117767402

版权

Vue 同时被 2 个专栏收录

17 篇文章 1 订阅

订阅专栏

uni-app

10 篇文章 1 订阅

订阅专栏

由于前段时间开发出来的vue版本的聊天页，性能、用户体验等方面十分不尽人意，故开启了新的征途，nvue版本聊天页的开发。

痛点一、进入页面保持在最底部

这次重构nvue版本的聊天页，使用了标新立异的渲染方式。众所周知，前端渲染页面都是由上而下渲染的，那么如果需要进入页面的时候，便保持在页面的最底部，就需要等待页面渲染完毕后跳转至最底部。这样的渲染方式就会导致在进入页面时，用户能很明显的感受到页面抖动了一下（可能多次）。
所以此次重构，博主选择将整个页面旋转180度，原本的最顶部，变成了页面的最底部，进入页面无需滚动到最底，用户视角里页面会固定在底部，且渲染消息是自下而上渲染。具体css代码如下：

/* 由于nvue中不支持全部的css，需要将这段样式写进对应dom元素的style上 */
direction: rtl;
transform: rotate(180deg);
-ms-transform: rotate(180deg);
-moz-transform: rotate(180deg);
-webkit-transform: rotate(180deg);
-o-transform: rotate(180deg);

痛点二、进入页面有长时间白屏

原先的vue版本聊天页，在进入页面时，会有长时间的白屏。后来博主将其中onLoad钩子中所做的大部分计算操作，转移到onReady中，白屏时间也优化了蛮多。
现在nvue版本的聊天页，使用uniapp原生的顶部导航栏，渲染速度快，不会出现白屏。具体配置在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"
	}
}

痛点三、弹出键盘，切换表情框页面闪动严重

在原先的vue版本聊天页中，弹出键盘，切换表情框会导致页面需重新计算弹出软键盘或表情框后页面的位置（保持用户在看的消息的位置）。
在对聊天页进行180度颠倒渲染后，弹出键盘、表情框的时候，就无需对其页面的位置去做重新计算了，但需要在弹出键盘、表情框的时候，撑高底部栏。比如写个计算属性computed：

<template>
	<!-- 滚动区域 -->
	<scroller>xxxx</scroller>

	<!-- 底部区域 -->
	<div :style="footerHeight"></div>
</template>
<script>
export default {
	computed: {
		footerHeight() {
			if (弹出键盘) {
				return `${键盘高度}rpx`;
			} else if (弹出表情框) {
				return '450rpx';
			} else {
				return '0';
			}
		}
	}
}
</script>

痛点四、消息富文本渲染

作为一个聊天软件，@人、自定义表情（图片）、普通文本、链接都是需要去做个性化的自定义。在原本的vue版本聊天页中，这些事情均交由uParse去处理。
转为nvue开发后，uParse不兼容，以博主亲身体验尝试来讲，只有rich-text组件和mp-html插件能使用上。但是！这两个东西都有它的问题，rich-text组件，在ios端设置其内部节点的样式会不生效，已报BUG；而mp-html插件，首先渲染采用的webview，比weex渲染慢，其次就是iOS端使用该插件，无法加载本地图片（表情）。
所以博主最后放弃了这两个选项，改为planC，自己写富文本消息解析，通过大致计算文本的宽度，将文本表情链接等拆分成一块块元素拼接成一条消息。

痛点五、各种兼容细节

使用textarea不能使用auto-height属性，在iOS端会导致textarea无法滚动。
使用textarea不能使用v-model，尽管绑定v-model在nvue版本的iOS端不会出现吞字的问题，但是在Android端会出现无法长按删除的问题，所以只能使用value。
textarea组件的blur事件中没有cursor（光标位置）参数。
nvue中无法使用main.js中挂载的全局变量，需要在页面内再次单独引入。
nvue页面中能直接使用vuex，但是页面内引用的js文件中，无法访问vuex（访问的state为初始值）。若需要在其内引用的js中也使用vuex，则需要在nvue页面中，将其$store传进js文件中。
官方推荐nvue中长列表使用list组件，但是list组件在iOS端下拉加载历史消息的时候，存在卡顿的现象，故博主推荐的是使用scroller组件，其配置项跟list一致。
在iOS端和Android端长按textarea，是不同的表现，iOS端会弹出键盘，而Android端不会弹出键盘，而是弹出上下文菜单。
使用dom.scrollToElement这个API，设置其offset值在iOS端和Android端的表现不一致。
下拉加载更多功能在iOS端需要做限制操作，两次加载更多触发的时间差最好不小于1.5s，因为iOS端滚动有回弹的效果。