摘要：代碼中的高度和寬度的單位均為，然而，在手機(jī)屏幕上顯示的高寬卻不一定與代碼指定的相同。原因是框架在底層做了針對(duì)不同屏幕的適配工作，具體計(jì)算公式為實(shí)際高寬代碼高寬屏幕寬度。

weex代碼中的高度和寬度的單位均為px，然而，在手機(jī)屏幕上顯示的高寬卻不一定與代碼指定的相同。原因是weex框架在底層做了針對(duì)不同屏幕的適配工作，具體計(jì)算公式為 實(shí)際高寬 = 代碼高寬 * (屏幕寬度 / 750)。

舉個(gè)例子，假設(shè)代碼中是這么寫(xiě)的：

那么，在一款屏幕分辨率為1920*1280的Android手機(jī)上，此時(shí)的計(jì)算過(guò)程為：
height: 100 * (1080 / 750) = 144；
width: 200 * (1080 / 750) = 288。

如果我們開(kāi)發(fā)的weex頁(yè)面是全屏幕的，那么這個(gè)高寬的轉(zhuǎn)換過(guò)程對(duì)我們而言是透明的，無(wú)需做額外的工作。然而一旦有一個(gè)業(yè)務(wù)場(chǎng)景，weex容器并非是全屏幕的，而是需要從外部傳入weex容器的高度，那么，就不得不考慮這個(gè)轉(zhuǎn)換的過(guò)程。

舉一個(gè)我在開(kāi)發(fā)weex彈窗時(shí)的例子。該weex彈窗的樣式如下：

可以看到，如果不考慮多屏幕適配，頂欄和底欄都是一個(gè)固定值，那么只需要用總?cè)萜鞲叨?- 兩個(gè)定高組件就可以了。那么需要解決的第一個(gè)問(wèn)題，就是如何獲取外部容器的高度。由于weex可以通過(guò)$getConfig().env.deviceHeight和$getConfig().env.deviceWidth的形式來(lái)獲取手機(jī)屏幕的高度，因而，很自然地就想到，是否能在安卓中以屏幕的3/5的比例，約定容器高度，然后在weex代碼中，同樣通過(guò)3/5來(lái)計(jì)算容器高度。這樣就避免了去寫(xiě) Native Module 和 Method。

然而，這樣的思路是不可行的。因?yàn)锳ndroid Native的總高度，事實(shí)上是可供顯示的全屏高度，而不一定是物理屏幕的高度，因?yàn)橛袪顟B(tài)欄，虛擬按鍵欄，Smartbar等等安卓碎片化引入的額外顯示元素，實(shí)際全屏高度很有可能小于物理屏幕高度。所以，仍然需要開(kāi)發(fā)和注冊(cè)Native Module，以獲取外部容器高度。

再來(lái)看上文的計(jì)算公式：總?cè)萜鞲叨?- 兩個(gè)定高 = scroller高度。因?yàn)槎嗥聊贿m配的原因，上面的公式是不可行的，需要改為：

外部傳入的總?cè)萜鞲叨?- 兩個(gè)定高組件的高度字面量 * 轉(zhuǎn)換比例 = scroller實(shí)際高度

也就是說(shuō)：外部傳入的總?cè)萜鞲叨?/ 轉(zhuǎn)換比例 - 兩個(gè)定高組件的高度字面量 = scroller實(shí)際高度 / 轉(zhuǎn)換比例 = scroller的字面量高度。

所以，最終的業(yè)務(wù)代碼如下所示：

        ready:function() {
            ...
            // 引入外部注冊(cè)的 Native Module；Android 和 iOS 各有其實(shí)現(xiàn)
            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;
              }
            }
            ...
        }

這個(gè)坑非常的隱蔽，本質(zhì)是因?yàn)椋簑eex 默默做了A參考系轉(zhuǎn)換到B參考系的過(guò)程，然而一旦我們自力更生，試圖從B參考系獲得一個(gè)測(cè)量得到的高度，用在A參考系，而沒(méi)意識(shí)到這個(gè)隱蔽的轉(zhuǎn)換過(guò)程的時(shí)候，就會(huì)陷入到一臺(tái)機(jī)子上調(diào)好了，另一臺(tái)又跪了的尷尬局面。而且，這種情況在Android上遠(yuǎn)較iOS要來(lái)的嚴(yán)重。因?yàn)閕OS上，除了4S以外，5，5s，6，6p，6s，6sp，屏幕尺寸均為同一長(zhǎng)寬比。因此，在一臺(tái)上調(diào)整好后，可無(wú)縫等比例放大到其他機(jī)型上。然而在Android上，毋論碎片化的屏幕尺寸，光status bar，navigation bar，smartbar等等虛擬的占用實(shí)際顯示區(qū)域的各類(lèi)bar，就足夠讓weex的默認(rèn)適配喝一壺的。因此，weex這種隱蔽適配的處理方式，在Android生態(tài)上是否真的合理方便，尚待商榷。

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

如果您覺(jué)得我的文章對(duì)您有所啟迪，請(qǐng)點(diǎn)擊文末的推薦按鈕，您的鼓勵(lì)將會(huì)成為我堅(jiān)持寫(xiě)作的莫大激勵(lì)。 by DesGemini