uni-app关于uni.navigateTo的坑以及解决方案

原创  郑建华   2021-04-03   88人阅读  0 条评论

    我们在做的这个产品目前的结构是这样的,使用nvue编写的uni-app项目作为app端,使用vue编写的vue项目作为H5端。在app端一共有三个页面,分别为loading页面、setting页面、index页面。 一些基本的交互逻辑如下:

   一、app打开时,默认加载loading页面,此时判断是否存在服务端缓存地址和H5缓存地址(如果存在缓存就直接跳转页面)

    1、如果服务端缓存地址为空,直接跳转到setting页面。(因为没有地址就无法建立连接,无法监测设备状态)

    2、如果存在H5缓存地址,并且校验地址可以访问,就加载H5缓存地址,当页面加载完成后,APP收到来自H5的消息,就跳转到index页面,这个页面主要用来展示数据,其中嵌套webview,地址是H5缓存地址。(H5地址能够访问,就直接展示,避免服务停掉时直接跳转设置页面不友好)

        2.1、自动连接服务端,如果连不上就一直重连 (开启重连机制,当服务端启动时,能够及时恢复连接)

    3、如果H5缓存地址,不可访问,就跳转到setting页面,并且清空缓存。(地址不可访问,说明地址可能错误,需要跳转到设置页面重新设置)

    4、如果H5缓存地址为空,则直接请求服务端,等待服务端返回H5端地址

        4.1、如果服务端连接失败,则会跳转到setting页面,并且清空缓存(地址不可访问,说明地址可能错误,需要跳转到设置页面重新设置)

        4.2、如果服务端连接成功,则会返回H5地址,并且将其加入缓存中

                4.2.1、校验地址可以访问,加载H5地址,当页面加载完成后,APP收到来自H5的消息,就跳转到Index页面。

                4.2.2、校验地址不可访问,则跳转到setting页面,并且清空缓存(地址不可访问,说明地址可能错误,需要跳转到设置页面重新设置)

   二、当前在setting页面时,可以输入服务端地址(IP+Port),点击按钮时,会向服务端发起请求,由服务端返回一个H5端的地址(通过服务端返回H5端地址,再进行跳转页面)

    1、点击按钮时,就会缓存当前的服务端地址

    2、如果服务端连接失败,则会直接提示服务加载失败。

    3、如果服务端请求成功,会返回H5地址,并且将其加入缓存中

        3.1、校验地址可以访问,加载H5地址,当页面加载完成后,APP收到来自H5的消息,就跳转到Index页面。

        3.2、校验地址不可访问,则直接提示页面加载失败,并且清空缓存。

  三、当前在index页面时,可用点击设置按钮,会跳转到setting页面(可重新配置地址)

    1、点击设置,H5会向APP发送一条消息

    2、APP收到消息,判断消息类型,为APP页面跳转消息,则会执行页面跳转操作。

loading页面

image.png

setting页面

image.png

index页面

image.png

    那么接下来,就开始踩坑了。而在同一坑里掉下来去两次,当然是两种不同的现象,只是原理是相同的。先来讲一下现象:

现象一:

    在起初的模式中,只做了setting页面和index页面,setting页面默认给了一个加载图片。在setting页面的onLoad中,预载了index页面,而在index的onLoad方法中,预加载webview。再根据是缓存中的h5url判断是否将创建的webview添加到当前窗口。另外再根据一些逻辑进行反复横跳。目的是默认进入setting页面,如果缓存均有值,当页面加载完成后,在跳转到index页面,载图片起到一个过渡的作用。而如果加载失败,只是将加载图隐藏,显示具体的设置页面。而跳转的方式采用了uni.navigateTo方法。这种模式下,缓存值都存在时访问直接跳转是正常的,当没有缓存时,跳转到setting页面,再通过点击按钮跳转index页面,就会出现页面无限跳转,不停的在跳index页面。

    初步分析:怀疑过绑定了多个事件,导致事件重复触发,进行跳转;怀疑是预加载导致;等... 结果没有一项是正确的。

现象二:

    在现在的模式中,分为了三个页面,loading页面、setting页面、index页面,在loading页面中预加载setting页面和index页面。在loading页面做缓存的判断以及loading效果的展示,在setting页面做ip和端口的设置,跳转index页面。在index页面做webview的加载以及app与h5之间的相互通讯。这样设计之后就不存在反复横跳了,从loading要么进入到setting页面,要么进入到index页面。所以当时,同事改造完之后,这个问题解决了,我以为万事大吉了。直到后来做到点击设置跳回setting页面时,这第一步操作是成功了,正常返回了setting页面,但是再次点击注册设备时,页面一片空白。这里的所有跳转方式,均采用了uni.naviagteTo方法。

    初步分析:通过plus.webview.all()打印全部窗体,在不同时机打印,在前面所有步骤中均显示正常,而在跳转到setting页面后,再次点击设置时,窗体发生了变化,新增了一个窗口。并且窗体中的方法都没有了。所以问题出在跳转后。


全局分析:

    看到这里,细心的同学应该已经发现了端倪。在我前面所有的表述中,认为navigateTo方法为跳转页面。我们先来看看官网上是怎么讲的。保留当前页面,跳转到应用内的某个页面,使用uni.navigateBack方法可以返回到原页面。我是这样理解的,我以为保留当前页面的意思就是,当前页面不会销毁,然后跳转到应用内的一个页面。对比uni.redirectTo和uni.reLaunch方法,redirectTo是关闭当前页面,然后跳转。reLaunch方法是关闭全部页面,然后跳转,但是调用过preLoadPage方法的仅仅触发onHide生命周期。所以,我认为这里的跳转就是,这个应用内有很多个页面,在这些页面之间跳来跳去,仅仅只是是否关闭页面的区别,也就是说,我认为这个跳转就是平级页面之间的跳转,并且每个页面只会存在一个,但是实际上并不是这样的。

    仔细看navigateTo的描述,保留当前页面,跳转到应用内的某个页面。保留当前页面,就是当前页面不关闭,跳转到某个页面,就是以那个页面为模板创建一个新的页面。所以,这是一个叠加的关系,打开一个页面,放在前一个页面上面,展示的就是最上面的页面。根据描述,可以使用navigateBack返回到原页面,应该就是关掉最上面的页面,重新回到之前的页面。

    可以设想一下,如果一个页面中有两个按钮,一个触发navigateTo方法,设置跳转到与当前相同地址的页面,一个触发naviagateBack方法。点击五次navigateTo方法的按钮,你猜会发生什么呢?肯定是闪了五下,那如果再点击五次navigateBack方法的按钮又会怎么样呢?如果猜想的没错的话,应该是以当前页面为模板,重新创建了五个页面,每次创建都保留了之前的页面。再点击五次又会返回到第一个页面。

    所以,现象一,可以解释为,因为多次调用了navigateTo方法,创建了多个页面,每个页面都未被关闭,所以相同的方法就触发了多次,导致了一直刷新。现象二,可以解释为,收到APP收到消息后,新建了一个setting页面。不过这个setting页面,最开始的时候,在loading页面中进行了preLoadPage,根据以下图中说明,由于已经预加载过这个setting页面,且参数和url都相同,所以新的页面仅触发生命周期onShow,导致窗体的方法都不存在。

image.png

image.png

image.png

image.png

    解决方案:

    这里采用了一个取巧的办法,我们需要的不是创建一个新的页面,而是跳转回去之前创建好的页面,那什么方法能够做到呢?uni.switchTab方法的描述是,跳转到tabBar页面,并关闭其他所有非tabBar页面。另外需要注意的是,如果调用了preloadPage不会关闭,仅触发生命周期onHide。那我们只要这个三个页面都属于tabBar页面,然后采用uni.switchTab方法进行跳转。这样,由于setting页面和index页面调用过preLoadPage方法,仅会触发生命周期onHide,tabBar页面本身也不会关闭,那么就可以随意的反复横跳了。最后只需要将tabBar给隐藏掉,就可以完美解决问题了。将高度设置为了0.01px,直接设置为0px不生效。


image.png

image.png

本文地址:https://www.zjh336.cn/?id=2033
版权声明:本文为原创文章,版权归 郑建华 所有,欢迎分享本文,转载请保留出处!
NEXT:已经是最新一篇了

发表评论


表情

还没有留言,还不快点抢沙发?