资讯专栏INFORMATION COLUMN

非全屏 Weex 页面开发中的 Android 适配

gxyz / 964人阅读

摘要:代码中的高度和宽度的单位均为,然而,在手机屏幕上显示的高宽却不一定与代码指定的相同。原因是框架在底层做了针对不同屏幕的适配工作,具体计算公式为实际高宽代码高宽屏幕宽度。

weex代码中的高度和宽度的单位均为px,然而,在手机屏幕上显示的高宽却不一定与代码指定的相同。原因是weex框架在底层做了针对不同屏幕的适配工作,具体计算公式为 实际高宽 = 代码高宽 * (屏幕宽度 / 750)。

举个例子,假设代码中是这么写的:

那么,在一款屏幕分辨率为1920*1280的Android手机上,此时的计算过程为:
height: 100 * (1080 / 750) = 144;
width: 200 * (1080 / 750) = 288。

如果我们开发的weex页面是全屏幕的,那么这个高宽的转换过程对我们而言是透明的,无需做额外的工作。然而一旦有一个业务场景,weex容器并非是全屏幕的,而是需要从外部传入weex容器的高度,那么,就不得不考虑这个转换的过程。

举一个我在开发weex弹窗时的例子。该weex弹窗的样式如下:

可以看到,如果不考虑多屏幕适配,顶栏和底栏都是一个固定值,那么只需要用总容器高度 - 两个定高组件就可以了。那么需要解决的第一个问题,就是如何获取外部容器的高度。由于weex可以通过$getConfig().env.deviceHeight$getConfig().env.deviceWidth的形式来获取手机屏幕的高度,因而,很自然地就想到,是否能在安卓中以屏幕的3/5的比例,约定容器高度,然后在weex代码中,同样通过3/5来计算容器高度。这样就避免了去写 Native Module 和 Method。

然而,这样的思路是不可行的。因为Android Native的总高度,事实上是可供显示的全屏高度,而不一定是物理屏幕的高度,因为有状态栏,虚拟按键栏,Smartbar等等安卓碎片化引入的额外显示元素,实际全屏高度很有可能小于物理屏幕高度。所以,仍然需要开发和注册Native Module,以获取外部容器高度。

再来看上文的计算公式:总容器高度 - 两个定高 = scroller高度。因为多屏幕适配的原因,上面的公式是不可行的,需要改为:

外部传入的总容器高度 - 两个定高组件的高度字面量 * 转换比例 = scroller实际高度

也就是说:外部传入的总容器高度 / 转换比例 - 两个定高组件的高度字面量 = scroller实际高度 / 转换比例 = scroller的字面量高度。

所以,最终的业务代码如下所示:

        ready:function() {
            ...
            // 引入外部注册的 Native Module;Android 和 iOS 各有其实现
            var AppInfo = require("@weex-module/MSOAFoundation");
            if (this.$getConfig().env.platform != "iOS") {
              // 适配 Android
              this.mainExtra = "mainExtraAndroid";
              AppInfo.getContainerHeight(function(params) {
                ratio = this.$getConfig().env.deviceWidth / 750;
                this.scrollerHeight = params.height / ratio - 200;
              }.bind(this));
            } else {
              // 适配 iPhone 4S
              if (this.$getConfig().env.deviceHeight < 1000) {
                this.scrollerHeight = 700;
              }
            }
            ...
        }

这个坑非常的隐蔽,本质是因为:weex 默默做了A参考系转换到B参考系的过程,然而一旦我们自力更生,试图从B参考系获得一个测量得到的高度,用在A参考系,而没意识到这个隐蔽的转换过程的时候,就会陷入到一台机子上调好了,另一台又跪了的尴尬局面。而且,这种情况在Android上远较iOS要来的严重。因为iOS上,除了4S以外,5,5s,6,6p,6s,6sp,屏幕尺寸均为同一长宽比。因此,在一台上调整好后,可无缝等比例放大到其他机型上。然而在Android上,毋论碎片化的屏幕尺寸,光status bar,navigation bar,smartbar等等虚拟的占用实际显示区域的各类bar,就足够让weex的默认适配喝一壶的。因此,weex这种隐蔽适配的处理方式,在Android生态上是否真的合理方便,尚待商榷。

====================================

如果您觉得我的文章对您有所启迪,请点击文末的推荐按钮,您的鼓励将会成为我坚持写作的莫大激励。 by DesGemini

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/80602.html

相关文章

  • 加推Weex实践之路(上)

    摘要:我们参考小程序的设计思路进行了优化升级,为每一个需要特有化配置的页面添加一个格式的配置文件,配置文件包括导航栏的配置页面级别的配置跳转的配置等,将配置工程化标准化。设置导航栏按钮包含按钮样式的数组通过完成按钮事件的回调。一、背景1.为什么是Weex在公司快速发展的大环境下,App的更新迭代高速、高频,技术团队平均两周便可诞生一款中型App,但App团队只有6个人(iOS 、Android各3...

    shuibo 评论0 收藏0
  • 提升Android手机主要视频应用全屏播放的观看体验

    摘要:为了给用户带来多媒体方面的体验福利,一刻也不能停,现在要提升主要视频应用全屏播放的观看体验。 为了给用户带来多媒体方面的体验福利,一刻也不能停,现在要提升主要视频应用全屏播放的观看体验。 提升主要视频应用全屏播放的观看体验老板撂下一句话后拂袖而去,剩下的自己体会。经过人工智能的大脑快速处理,提取了几个比较关键的技术点。 1.视频应用,如何判断到视频应用在工作? 2.全屏播放,如何判断视...

    raise_yang 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<