【uniapp实战笔记】基于nvue聊天页的开发踩坑记录

点击蓝字 关注我

由于前段时间开发出来的 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>exportdefault {
    computed: {
        footerHeight() {
            if (弹出键盘) {
                return`${键盘高度}rpx`;
            } elseif (弹出表情框) {
                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 端滚动有回弹的效果。