q***@163.com
q***@163.com
  • 发布:2020-01-15 11:05
  • 更新:2020-07-04 06:58
  • 阅读:3715

【报Bug】uni-app app性能问题

分类:uni-app

用uni-app写了个小应用,发现两个tabbar页面切换时卡顿特别严重,我以为是渲染问题,经过我多次的排查才发现原来并不是。
然后自己写了个测试项目进行测试,测试项目由两个页面组成,并且将两个页面都添加为tabbar,页面1的代码如下

onShow() {  
            this.test()  
        },  
        methods: {  
            test(){  
                console.log("开始执行test")  
                var start = new Date().valueOf()  
                var arr = []  
                for(var i=0;i<100000;i++){  
                    var arrIn = []  
                    for (var j=0;j<1000;j++) {  
                        arrIn.push(j)  
                    }  
                    arr.push(arr)  
                }  
                var end = new Date().valueOf()  
                console.log("执行完毕,耗时:"+(end-start)+"毫秒")  
            }  
        }

页面2 为新建页面

本次测试发现两个问题:
1、app的js执行速度非常非常非常慢,将项目运行到我的手机(华为 mate 20),test方法平均耗时为5000毫秒左右
2、在app中必须执行完onShow中的代码后页面才会显示(也就是打印完 执行完毕,耗时:xxx毫秒 之后才会显示页面)

然后我又将代码运行到小程序和浏览器(这两个基本没啥区别)
耗时都是500毫秒左右,比app快了10倍!!!而且两个页面直接切换无任何卡顿!!! 我的天呐!为啥app更加垃圾?

我以为,可能是js执行速度较快所以两个页面切换无卡顿,然后我将j<1000改为j<10000,发现app直接卡死了,顿时一口老血卡住了喉咙,尼玛。。。这么坑爹!
我又分别运行到小程序和浏览器(这两个都没啥区别)
两个页面切换还是无任何卡顿,而且切换后才会执行onShow中的代码(打印 开始执行test),然后test的执行耗时平均5000毫秒左右
为啥都是5000毫秒,小程序和浏览器都能先切换再执行onShow中的代码,而app却是先执行onShow中的代码再显示页面?

然后我觉得我应该可以挣扎一下,把onshow中执行的代码放到setTimeout,发现从页面2切换到页面1也是瞬间切换,
我以为没问题了,然而。。。。变成了从页面1切出卡顿了,也就是如果要从页面1切出必须要页面1中的js全部执行完毕(包括onload和onshow)才能切换到其他的tabbar页面(其它普通页面没测试过),沃日勒,坑啊啊啊啊!

     跪求官方的产品经理能提一下这个问题(app问题)  
     1、js执行速度慢  
     2、页面先执行完js才会切入(显示本页面)和切出(显示别的页面)  

测试项目已上传到附件!

2020-01-15 11:05 负责人:无 分享
已邀请:

最佳回复

DCloud_App_Array

DCloud_App_Array

DCloud_UNI_GSQ

DCloud_UNI_GSQ

收到,将会排查和改善。
另外你运行到小程序和浏览器使用的什么设备测试的?浏览器是什么浏览器?能否提供一下你原来反馈tab切换慢的测试工程(不是示例代码那个)

  • q***@163.com (作者)

    测试项目代码在附件中,浏览器是hbuilderx的内嵌浏览器,小程序是微信开发者工具测试的,每次tab切换(假设从A切换到B)都需要 A中正在执行的js执行完毕 + B中js执行完毕才会完成一次切换,而浏览器和微信小程序则是直接切换,不需要等js执行完毕

    2020-01-16 08:48

DCloud_heavensoft

DCloud_heavensoft

  1. 关于第一个js运行慢的问题:
    uni-app的app端,iOS和Android,用的都是jscore。iOS的jscore是iOS自带的,Android是复用了weex的jscore。
    而微信小程序,iOS用的是jscore,Android用的是v8。
    v8和jscore,运行js的性能各有优劣。你这段代码,在Android下由于jscore和v8的差异,执行速度确实不同。iOS是一样的,因为都跑在一个jscore下。
    weex的jscore的问题, 已经督促他们优化。

  2. 然后切换页面和js运行抢资源的问题:
    你用的是vue的tab页面,为防止白屏,框架自动有一个50毫秒的延时渲染。
    如果你的耗时js先开始运行,会卡住js进程,进而导致这个50毫秒被进一步延迟。界面上感觉就是卡很久才切换了tab。
    有2种解决方案:

    • 使用nvue。nvue没有延时操作。会直接切tab,然后在新页面里自己加一个waiting等待之类的
    • 进一步延迟复杂js开始启动的时期,别让它影响窗体切换

同时注意还是要优化js算法,避免高耗时的运算放在本地。
高耗时的运算,1、优化算法;2、交给服务器、3. 交给原生插件。这几种方法都可以使用

更新:见最佳回复,从HBuilderX2.8起,Android已经提供了新的js引擎

  • q***@163.com (作者)

    延时复杂js开始启动的时期会导致另一个问题,切入很快,但是切入后如果延时的js正在执行时,立即切换到别的tab会导致卡顿,这个问题非常严重,难道DCloud不准备自己做一个uni-app的壳子吗?毕竟现在用uni-app的人越来越多了,一直用weex的不好吧?本来weex就是有各种问题

    2020-01-16 08:54

  • q***@163.com (作者)

    我将测试的两个页面都改为nvue的,问题同样存在,跟vue没区别,都是需要等待js执行完毕

    2020-01-16 09:06

  • q***@163.com (作者)

    经过进一步的测试,发现只有微信小程序不需要等待js执行完毕即可完成页面的切换,而app和H5都需要等待所有在执行的js执行完毕才能进行页面的切换(包括app.vue中的js),然而H5的js执行速度比app快了10倍不止,所以没什么感觉,强烈要求dcloud官方出一个自己使用V8引擎的app壳子!!weex真的坑!

    2020-01-16 10:03

  • 龙雨溪

    回复 q***@163.com: 你是说电脑比手机快10倍?我的电脑能比手机快100倍。。。

    2020-01-16 10:59

  • q***@163.com (作者)

    回复 龙雨溪: 我用手机浏览器测过,tab秒切,主要就是app的js执行太慢,而且我的电脑用的公司的,配置一般般

    2020-01-16 11:18

  • q***@163.com (作者)

    已经做了各种优化了,速度提高了一点,但是还是解决不了根本问题,js执行太慢!!因为onshow必须要执行一些js代码,而且当setTimeout回调开始执行的时候切换同样会卡顿

    2020-01-16 11:22

  • 二柱子

    回复 q***@163.com: weex的确坑,听说鸿蒙会内置新的js引擎

    2020-01-16 11:47

  • DCloud_heavensoft

    回复 q***@163.com: tab切换的问题,不是weex的问题。是因为微信的tab切换,是原生直接处理的,中间不走js的路由管理,自然不会受js影响。如果按微信的做法做,自由度就受了影响,目前很多路由拦截的前端插件都用不了的。大家的问题官方已经知道了,官方会给出合理方案的。目前的建议,就是客户端尽量避免高耗时的js运算

    2020-01-16 17:25

  • DCloud_heavensoft

    回复 DCloud_heavensoft: 高耗时的运算,1、优化算法;2、交给服务器、3. 交给原生插件。这几种方法都可以使用

    2020-01-16 17:35

  • DCloud_heavensoft

    回复 q***@163.com: 更新:见最佳回复,已经提供了新的js引擎

    2020-07-04 06:57

uViewUI

uViewUI - 【www.uviewui.com】uView UI,是uniapp生态最优秀的UI框架,全面的组件和便捷的工具会让您信手拈来,如鱼得水

JS执行慢,还要等weex修复,感情你们对weex是拿来主义的啊,还以为你们是对某一个weex版本持续改进的呢,看来weex全面兼容uniapp是无望的了,也不指望需求墙的第三点增加nvue的css写法的需求能实现了,因为你们等weex增加这个功能,nvue才会有……

  • 深海智行

    据我所知,能做到的才写到需求墙上,做不到的(比如用集成fluter)是上不去的。不过你有没有想过为什么weex团队不增加css写法支持,是能力不够么?

    2020-01-16 11:11

  • 二柱子

    回复 深海智行: weex和fluter都不行的,应该基于鸿蒙

    2020-01-16 11:45

  • DCloud_heavensoft

    回复 二柱子: 放到需求墙上的,都是可以做的,但优先级期待开发者给出意见。DCloud已经改进了weex很多问题,比如圆角性能、比如高斯模糊。增加css写法也知道怎么做。jscore的问题,要不要改,能不能改,是需要和weex团队讨论的。jscore引擎是Apple团队研发的,你只看到这段js慢,但它在其他js方便又有自己的优势。

    2020-01-16 17:22

  • DCloud_heavensoft

    更新:见最佳回复,已经提供了新的js引擎

    2020-07-04 06:57

该问题目前已经被锁定, 无法添加新回复