写在后面
在我从事 React Native(以下简称 RN)开发的两年工作中,本人与团队成员时常会遇到一些令人纳闷的屏幕适配问题,如:全屏 mask 款式无奈笼罩整个屏幕、1 像素边框有时无奈显示、非凡机型布局错乱等。另外,局部成员对 RN 获取屏幕参数的 API——Dimensions.get('window')
与 Dimensions.get('screen')
最终返回的值代表的意义也存在纳闷。
其实 RN 的适配比较简单,我将在此文中论述适配原理,提出适配计划,并针对局部非凡问题一一解释其起因,原则上能笼罩所有机型的适配。若有脱漏与不当之处,欢送指出,独特交换。
往期精彩 RN 文章举荐:
-【从源码剖析】可能是全网最实用的 React Native 异样解决方案【倡议珍藏】
适宜浏览群体
- 有肯定 RN 开发教训,理解 RN js 模块如何与原生模块通信;
- 有 RN 适配教训,懂了,但没齐全懂的那种;
- 想理解 RN 适配;
为什么须要适配
保障界面在不同的设施屏幕上都能按设计图成果展现,对立用户视觉与操作体验
常见适配名词论述
如果你从网上去搜屏幕适配,你搜到的博文中肯定都会有以下一大堆名词及其解释
- 适配:不同屏幕下,元素显示成果统一
- 屏幕尺寸:指的是屏幕对角线的长度
- px(单位): px 理论是 pixel(像素)的缩写,依据 维基百科的解释,它是图像显示的根本单元,既不是一个确定的物理量,也不是一个点或者小方块,而是一个抽象概念。所以在议论像素时肯定要分明它的上下文!
- 分辨率:是指宽度上和高度上最多能显示的物理像素点个数
- 设施物理像素:指设施能管制显示的最小物理单位,意指显示器上一个个的点。从屏幕在工厂生产出的那天起,它下面设施像素点就固定不变了,和屏幕尺寸大小无关
- 设施独立像素(设施逻辑像素):计算机坐标零碎中得一个点,这个点代表一个能够由程序应用的虚构像素(比方: css 像素),这个点是没有固定大小的,越小越清晰,而后由相干零碎转换为物理像素
- CSS 像素:css px 和物理像素的对应关系, 与 viewport 的缩放无关 scale = 1/dpr 时 1px 对应一个 物理像素
- DPI:打印设施印刷点密度。每 inch 多少个点
- PPI:设施物理像素密度。每 inch 多少个物理像素
- DPR:设施像素比 = 设施物理像素 / 设施独立像素(CSS 像素)
看完这些名词后大多数人的感觉:懂了,但没齐全懂 \~
咱们先遗记这些名词概念,只记住以下 4 个概念:
- 适配:不同屏幕下,元素显示成果统一
- 设施独立像素 = 设施逻辑像素 =CSS 像素
- DPR:设施像素比 = 设施物理像素 / 设施独立像素(CSS 像素)
- 设计图与编码中的尺寸都是 CSS 像素
OK,上面,正菜开始!客官们请跟我这边来。
RN 的尺寸单位
要做 RN 适配得先明确 RN 款式的尺寸单位。
在 RN 的官网有明确标注:
All dimensions in React Native are unitless, and represent density-independent pixels.
React Native 中的尺寸都是无单位的,示意的是与设施像素密度无关的逻辑像素点。
为什么是无单位的逻辑像素点呢?
因为 RN 是个跨平台的框架,在 IOS 上通常以逻辑像素单位 pt 形容尺寸,在 Android 上通常以逻辑像素单位 dp 形容尺寸,RN 选哪个都不好,既然大家意思雷同,罗唆不带单位,在哪个平台渲染就默认用哪个单位。
RN 提供给开发者的就是曾经通过 DPR(设施像素比)转换过的逻辑像素尺寸,开发者无需再关怀因为设施 DPR 不同引起的尺寸数值计算问题
在有些博文中,会提到 RN 曾经做好了适配,其实指的就是这个意思。
适配计划
留神:本文示例与形容中设计图尺寸规范都为 375X667(iPhone6/7/8)
对于 RN 适配,我总结为以下 口诀:
一理念,一像素,一比例;
部分盒子全副按比例;
遇到整页布局垂直方向弹一弹;
安卓须要解决状态栏。
一理念
适配就是不同屏幕下,元素显示成果统一的理念
怎么了解呢?
举个栗子:
假如有一个元素在 375X667 的设计图上标注为 375X44,即宽度占满整个屏幕,高度 44px。如果咱们做好了 RN 的屏幕适配,那么:
在 iPhone 6/7/8(375X667)机型与 iPhone X(375X812)机型上,此元素渲染后果会占满屏幕 宽度 ;
在 iPhone 6/7/8 Plus(414X736)机型上, 此元素渲染后果也应占满屏幕 宽度;
打个现实生活中的比如:
联合国依据恩格尔系数的大小,对世界各国的生存程度有一个划分规范,即一个国家均匀家庭恩格尔系数大于 60% 为贫困;50%-60% 为饥寒;40%-50% 为小康;30%-40% 属于绝对富裕;20%-30% 为富足;20% 以下为极其富裕。
假如要实现小康生活,不论你是哪个国家的人民,发达国家也好,发展中国家也好,家庭的恩格尔系数都必须达到 40%-50%。
这里,国家就能够了解为手机屏幕、生存程度就了解为元素渲染成果。
至于上述的一些名词,如:物理像素,像素比等,你能够了解为国家的货币以及货币汇率。毕竟,程序设计源自生存。
那么,正在搬砖的你,小康了吗~?
一像素
RN style 中所有的尺寸,包含但不限于 width、height、margin、padding、top、left、bottom、right、fontSize、lineHeight、transform 等都是 逻辑像素(web 玩家能够了解为 css 像素)
h3: {
color: '#4A4A4A',
fontSize: 13,
lineHeight: 20,// 逻辑像素
marginLeft: 25,
marginRight: 25,
},
一比例
设施逻辑像素宽度比例
为了更好的视觉与用户操作体验,目前风行的挪动端适配计划,在大小上都是进行宽度适配,在布局上垂直方向自在排列。这样做的益处是:保障在页面上元素大小都是按设计图进行等比例缩放,内容恰好只能铺满屏幕宽度;垂直方向上内容如果超出屏幕,能够通过手指上滑下拉查看页面更多内容。
当然,如果你想走非凡路子,设计成高度适配,程度方向滑动也是能够的。
回到下面“一理念”的例子,在 iPhone 6/7/8 Plus(414X736)机型上,渲染一个设计图 375 尺寸元素的话,很容易计算出,咱们理论要设置的宽度应为:375 * 414/375 = 414。
这里的 414/375
就是 设施逻辑像素宽度比例
公式: WLR = 设施宽度逻辑像素 / 设计图宽度
WLR(width logic rate 缩写),散装英语,哈哈。
在这里,设施的宽度逻辑像素我倡议用Dimensions.get('window').width
获取,具体原因,前面会进行解释。[Q1]
那么,在指标设施上要设置的尺寸计算公式就是: size = 设置图上元素 size * WLR
小学四则运算,非常简单!
其实所有的适配都是围绕一个 比例 在做,如 web 端缩放、rem 适配、postcss plugin 等,小道万千,必由之路!
部分盒子全副按比例
为了不便了解,这里的“盒子”意思等同于 web 中的“盒模型”。
部分盒子全副按比例。意思就是 RN 页面中的元素大小、地位、内外边距等波及尺寸的中央,全副按上述一比例中的尺寸计算公式进行计算。如下图所示:
这样渲染进去的成果,会最大限度的保留设计图的大小与布局设计成果。
为什么说是最大限度,这里先留做一个问题,后文中解释。[Q2]
到这里,可能有老手同学会问:为什么在垂直方向上不必设施高度逻辑像素比例进行计算?
因为 设施高度逻辑像素 / 设计图高度
不肯定会等于 设施宽度逻辑像素 / 设计图宽度
,会引起盒子拉伸。
比方,当初依照设计图在 iPhone X(375X812)上渲染一个 100X100px 的正方形盒子,宽度逻辑像素比例是 1,高度逻辑像素比例是 812/667≈1.22,如果宽度与高度别离按后面的 2 个比例计算,那么最终盒模型的 size 会变成:
view1: {
width: 100,
height: 122,
},
好嘛,好好的一个正方形被拉伸成长方形了!
这显然是要不得的。
讲到这里,RN 适配其实曾经实现 70% 了,对,就是玩乘除法~
遇到整页布局垂直方向弹一弹
何为整页布局?
内容刚好铺满整页,没有溢出屏幕外。
这里的弹一弹,指的是 flex 布局。在 RN 中,默认都是 flex 布局,并且方向是 column,从上往下布局。
为啥要弹一弹呢?
咱们先来看挪动端页面布局常见的整页上中下分区布局设计,以 TCL IOT 单品旧版 UI 设计为例:
依照设计,在 iPhone 6/7/ 8 机型 (375X667) 上恰好铺满整页,在 iPhone 6/7/ 8 机型 plus(414X736)机型上根据上述的适配办法,其实也是近似铺满的,因为 414/375≈736/667
。然而,在 iPhone X(375X812)机型上,如果依照设计图从上往下布局,会呈现底下空出一截的状况:
此时有两种解决办法:
- 底部 - 操控菜单栏区域应用相对定位
bottom:0
固定在底部,最顶部 - 状态栏 + 标题栏是固定在顶部的,不须要解决,而后计算并用相对定位微调顶部 - 设施信息展示区,中部 - 设施状态区的地位,使它们恰好平分多进去的空白空间,让页面看起来更加协调; -
顶部 - 设施信息展示区,中部 - 设施状态区,底部 - 操控菜单栏区域应用父容器包裹,利用 RN flex 弹性布局的个性,设置
justifyContent:'space-between'
使得这 3 个区域垂直方向高低两端对齐,两头区域高低平分多进去的空白区域。
第 1 种,每个设施都须要去计算空白区域大小,再去微调元素地位,非常麻烦。
我举荐第 2 种,编码上更加简略。这就是 “弹一弹”
有同学会放心第 2 种形式会导致两头区域垂直方向上跨度十分大,页面看起来不协调。然而在理论中,设施屏幕高度逻辑像素很少会有比 667 大十分多的,多出的空白区域比拟小,UI 成果还是能够的,目前咱们上线的 N 款产品中也都是应用的这种形式,请释怀食用。
到此为止,如果依照以往 web 端的适配教训,RN 适配应该曾经实现了,然而,还是有坑的。
安卓须要解决状态栏
RN 尽管是跨平台的,然而在 ios 与 Android 上渲染成果却不一样。最显著的就是状态栏了。如下图所示:
Android 在不设置 StatusBar
的 translucent
属性为 true
时,是从状态栏下方开始绘制的。这与咱们的适配指标不吻合,因为在咱们的设计图中,整页的布局设计是笼罩了状态栏的。所以,倡议将 Android 的状态栏 translucent
属性设为true
,整个页面交给咱们开发者本人去布局。
<StatusBar translucent={true} />
如果你曾经看到这里,祝贺你,同学,把握 RN 的适配了,能够应答 90% 以上的场景。
然而还有一些奇奇怪怪的场景以及一些 API 你可能不太了解,这蕴含在剩下的 10% 适配场景中或在其中帮忙你了解与调试,没关系,我上面持续论述。有些会波及到源码,如果你有趣味,能够持续跟我看上来。
上面的内容十分十分多,然而对我集体而言,这部分才是我此次分享,想带给大家的最重要的局部。
一些奇奇怪怪又有意思的货色
这部分内容十分多,请酌情浏览
1. Dimensions
API
Dimensions
是 RN 提供的一个获取 设施 尺寸信息的 API。咱们能够用它来获取屏幕的宽高,这是做适配的 外围 API。
它提供了两种获取形式:
const {windowWidth,windowHeight} = Dimensions.get('window');
const {screenWidth,screenHeight} = Dimensions.get('screen');
官网文档上并没有阐明这两种获取形式的后果的含意与区别是什么。在理论开发中,这两种形式获取的后果有时雷同,有时又有差别,让局部同学感到困惑:我到底该应用哪一个才是正确的?
我举荐你始终应用 Dimensions.get('window')
。只有通过它获取的后果,才是咱们真正能够操控绘制的区域。
首先,明确这两种形式获取的后果的含意:
Dimensions.get('window')
——获取视口参数 width、height、scale、fontScale-
Dimensions.get('screen')
——获取屏幕参数 width、height、scale、fontScale
其中,在设施屏幕同状态的默认状况下 screen 的 width、height 永远是≥window 的 width、height,因为,window 获取的参数会排除掉状态栏高度(translucent 为 false 时)以及底部虚构菜单栏高度。 当此安卓机设置了状态栏translucent
为true
并且没有开启虚构菜单栏时,Dimensions.get('window')
就会与Dimensions.get('screen')
获取的 width、height 统一,否则就不同。这就是本段开始时有时雷同,有时又有差别的问题的答案。
这并非靠猜测或空穴来风,间接源码安顿上:
因作者设施无限,本文源码仅从 Android 平台剖析,ios 的源码,有 ios 教训的同学能够依照思路自行查阅。
筹备:依照官网文档新建一个 Demo RN 工程。为了稳定性,咱们应用后面的一个 RN 版本 0.62.0。命令如下:npx react-native init Demo --version 0.62.0
step1. 先找到 RN 的该 API 的 js 文件。node_modules\react-native\Libraries\Utilities\Dimensions.js
/**
* Copyright (c) Facebook, Inc. and its affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*
* @format
* @flow
*/
'use strict';
import EventEmitter from '../vendor/emitter/EventEmitter';
import RCTDeviceEventEmitter from '../EventEmitter/RCTDeviceEventEmitter';
import NativeDeviceInfo, {
type DisplayMetrics,
type DimensionsPayload,
} from './NativeDeviceInfo';
import invariant from 'invariant';
type DimensionsValue = {
window?: DisplayMetrics,
screen?: DisplayMetrics,
...
};
const eventEmitter = new EventEmitter();
let dimensionsInitialized = false;
let dimensions: DimensionsValue;
class Dimensions {
/**
* NOTE: `useWindowDimensions` is the preffered API for React components.
*
* Initial dimensions are set before `runApplication` is called so they should
* be available before any other require's are run, but may be updated later.
*
* Note: Although dimensions are available immediately, they may change (e.g
* due to device rotation) so any rendering logic or styles that depend on
* these constants should try to call this function on every render, rather
* than caching the value (for example, using inline styles rather than
* setting a value in a `StyleSheet`).
*
* Example: `const {height, width} = Dimensions.get('window');`
*
* @param {string} dim Name of dimension as defined when calling `set`.
* @returns {Object?} Value for the dimension.
*/
static get(dim: string): Object {invariant(dimensions[dim], 'No dimension set for key' + dim);
return dimensions[dim];
}
/**
* This should only be called from native code by sending the
* didUpdateDimensions event.
*
* @param {object} dims Simple string-keyed object of dimensions to set
*/
static set(dims: $ReadOnly<{[key: string]: any, ...}>): void {
// We calculate the window dimensions in JS so that we don't encounter loss of
// precision in transferring the dimensions (which could be non-integers) over
// the bridge.
let {screen, window} = dims;
const {windowPhysicalPixels} = dims;
if (windowPhysicalPixels) {
window = {
width: windowPhysicalPixels.width / windowPhysicalPixels.scale,
height: windowPhysicalPixels.height / windowPhysicalPixels.scale,
scale: windowPhysicalPixels.scale,
fontScale: windowPhysicalPixels.fontScale,
};
}
const {screenPhysicalPixels} = dims;
if (screenPhysicalPixels) {
screen = {
width: screenPhysicalPixels.width / screenPhysicalPixels.scale,
height: screenPhysicalPixels.height / screenPhysicalPixels.scale,
scale: screenPhysicalPixels.scale,
fontScale: screenPhysicalPixels.fontScale,
};
} else if (screen == null) {screen = window;}
dimensions = {window, screen};
if (dimensionsInitialized) {
// Don't fire'change' the first time the dimensions are set.
eventEmitter.emit('change', dimensions);
} else {dimensionsInitialized = true;}
}
/**
* Add an event handler. Supported events:
*
* - `change`: Fires when a property within the `Dimensions` object changes. The argument
* to the event handler is an object with `window` and `screen` properties whose values
* are the same as the return values of `Dimensions.get('window')` and
* `Dimensions.get('screen')`, respectively.
*/
static addEventListener(type: 'change', handler: Function) {
invariant(
type === 'change',
'Trying to subscribe to unknown event:"%s"',
type,
);
eventEmitter.addListener(type, handler);
}
/**
* Remove an event handler.
*/
static removeEventListener(type: 'change', handler: Function) {
invariant(
type === 'change',
'Trying to remove listener for unknown event:"%s"',
type,
);
eventEmitter.removeListener(type, handler);
}
}
let initialDims: ?$ReadOnly<{[key: string]: any, ...}> =
global.nativeExtensions &&
global.nativeExtensions.DeviceInfo &&
global.nativeExtensions.DeviceInfo.Dimensions;
if (!initialDims) {
// Subscribe before calling getConstants to make sure we don't miss any updates in between.
RCTDeviceEventEmitter.addListener(
'didUpdateDimensions',
(update: DimensionsPayload) => {Dimensions.set(update);
},
);
// Can't use NativeDeviceInfo in ComponentScript because it does not support NativeModules,
// but has nativeExtensions instead.
initialDims = NativeDeviceInfo.getConstants().Dimensions;}
Dimensions.set(initialDims);
module.exports = Dimensions;
这个 Dimensions.js 模块初始化了 Dimensions 参数信息,咱们的 Dimensions.get()办法就是获取的其中的信息。并且,该模块指出了信息的起源:
//...
initialDims = NativeDeviceInfo.getConstants().Dimensions;
//...
Dimensions.set(initialDims);
let {screen, window} = dims
const {windowPhysicalPixels} = dims
const {screenPhysicalPixels} = dims
//...
dimensions = {window, screen};
数据起源是来自原生模块中的 DeviceInfo module。
好嘛,咱们间接去找安卓源码,看看它提供的是啥玩意儿。
step2: 从 node_modules\react-native\android\com\facebook\react\react-native\0.62.0\react-native-0.62.0-sources.jar 中取到安卓源码 jar 包。
下载下来,保留到本地。
step3: 应用工具 java decompiler 反编译 react-native-0.62.0-sources.jar
:
能够看到,有很多 package。咱们直奔 com.facebook.react.modules
,这个模块是原生为 RN jsc 提供的绝大部分 API 的中央。
step4: 关上 com.facebook.react.modules.deviceinfo.DeviceInfoModule.java
:
看图中红色方框标记的中央,就是在上述 js 中模块中
initialDims = NativeDeviceInfo.getConstants().Dimensions;
设施的初始尺寸信息来源于此。
step5: 关上 DisplayMetricsHolder.java
, 找到 getDisplayMetricsMap()
办法:
怎么样,windowPhysicalPixels
& screenPhysicalPixels
是不是很相熟? 而它们的属性字段 width
、height
、scale
、fontScale
、densityDpi
等是不是常常用过一部分?没错,你在开始的 Dimensions.js
中见过它们:
严格来说,Dimensions.js
还漏了个densityDpi
(设施像素密度)没有解构进去~
ok,那咱们看它们最开始的数据起源:
result.put("windowPhysicalPixels", getPhysicalPixelsMap(sWindowDisplayMetrics, fontScale));
result.put("screenPhysicalPixels", getPhysicalPixelsMap(sScreenDisplayMetrics, fontScale));
别离来自:sWindowDisplayMetrics
、sScreenDisplayMetrics
。
其中,sWindowDisplayMetrics
通过
DisplayMetrics displayMetrics = context.getResources().getDisplayMetrics();
DisplayMetricsHolder.setWindowDisplayMetrics(displayMetrics);
设置;sScreenDisplayMetrics
通过
DisplayMetrics screenDisplayMetrics = new DisplayMetrics();
screenDisplayMetrics.setTo(displayMetrics);
WindowManager wm = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
Assertions.assertNotNull(wm, "WindowManager is null!");
Display display = wm.getDefaultDisplay();
// Get the real display metrics if we are using API level 17 or higher.
// The real metrics include system decor elements (e.g. soft menu bar).
//
// See:
// http://developer.android.com/reference/android/view/Display.html#getRealMetrics(android.util.DisplayMetrics)
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1) {display.getRealMetrics(screenDisplayMetrics);
} else {
// For 14 <= API level <= 16, we need to invoke getRawHeight and getRawWidth to get the real
// dimensions.
// Since react-native only supports API level 16+ we don't have to worry about other cases.
//
// Reflection exceptions are rethrown at runtime.
//
// See:
// http://stackoverflow.com/questions/14341041/how-to-get-real-screen-height-and-width/23861333#23861333
try {Method mGetRawH = Display.class.getMethod("getRawHeight");
Method mGetRawW = Display.class.getMethod("getRawWidth");
screenDisplayMetrics.widthPixels = (Integer) mGetRawW.invoke(display);
screenDisplayMetrics.heightPixels = (Integer) mGetRawH.invoke(display);
} catch (InvocationTargetException | IllegalAccessException | NoSuchMethodException e) {throw new RuntimeException("Error getting real dimensions for API level < 17", e);
}
}
DisplayMetricsHolder.setScreenDisplayMetrics(screenDisplayMetrics);
设置。
在安卓中 context.getResources().getDisplayMetrics();
只会获取可绘制区域尺寸信息,默认会去除顶部状态栏以及底部虚构菜单栏;而设置 screenDisplayMetrics 时,尽管有去辨别版本,但最终都是获取的整个屏幕的物理分辨率。
因而,能够真正有理有据的解释结尾的状况了。并且完完全全从 js 层到原生层讲述了Dimensions
API,好吧,讲这一个就啰里啰嗦的了,各位看官明确了吗?
全屏 mask 款式无奈笼罩整个屏幕
这个问题呈现在局部老旧安卓机上,大略在 2016~2018 年左右的中低端机型,光荣机型居多。这类手机自带底部虚构菜单栏,并且在应用时能够主动 / 手动暗藏。
问题情境:
当弹出一个带 mask 的自定义 Modal 时,如果设置了 mask 高度是 Dimensions.get(‘window’).height,在暗藏底部虚构菜单栏后,底部会空出一截无奈被 mask 遮罩。
问题起因:
暗藏菜单栏后,页面可绘制区域高度曾经产生了变动,而目前所渲染的视图还是上一次未暗藏菜单栏状态下的。
解决方案:
监听屏幕状态变动,这一点官网其实曾经特地指出了 (https://www.react-native.cn/d…
应用 Dimensions.addEventListener()
监听并设置 mask 高度,重点是要扭转 state,通过 state 驱动视图更新。
当然,也要记得移除事件监听Dimensions.removeEventListener()
1 像素边框有时无奈显示
RN 的 1 像素边框,通常是指:StyleSheet.hairlineWidth
它是一个常量,渲染成果会合乎以后平台最细的规范。
然而,在列表子项中设置时,常常会有局部列表子项失落这根线,而且诡异的是,同一根线,有些手机显示失常,有些手机不显示,甚至有些机型上线条会比拟“胖”。
老规矩,源码搬一搬:
在 node_modules\react-native\Libraries\StyleSheet\StyleSheet.js 中能够找到:
let hairlineWidth: number = PixelRatio.roundToNearestPixel(0.4);
if (hairlineWidth === 0) {hairlineWidth = 1 / PixelRatio.get();
}
而后在 node_modules\react-native\Libraries\Utilities\PixelRatio.js 中找到:
/**
* Rounds a layout size (dp) to the nearest layout size that corresponds to
* an integer number of pixels. For example, on a device with a PixelRatio
* of 3, `PixelRatio.roundToNearestPixel(8.4) = 8.33`, which corresponds to
* exactly (8.33 * 3) = 25 pixels.
*/
static roundToNearestPixel(layoutSize: number): number {const ratio = PixelRatio.get();
return Math.round(layoutSize * ratio) / ratio;
}
这原理就是渲染一条 0.4 逻辑像素左右的线,值不肯定是 0.4,要依据 roundToNearestPixel
换算成最能占据整数个物理像素的一个值,与设施 DPR 无关,也是上述 Dimensions
中的 scale
属性值。最差的状况就是在 DPR 小于 1.25 时,等于 1 / PixelRatio.get()
。
依照下面的规定计算,再怎么样,总归还是应该会显示的。然而,这里咱们要先引入 2 个概念——像素网格对齐 以及JavaScript number 精度:
咱们在设置逻辑像素时能够任意指定精度,然而设施渲染时,理论是按一个一个的物理像素显示的,物理像素永远整个的。为了能保障在任意精度的状况也能正确显示,RN 渲染时会做像素网格对齐;
JavaScript 没有真正意义上的整数。它的数字类型是基于 IEEE 754 规范实现的,采纳的 64 位二进制的“双精度”格局。数值之间会存在一个 “机器精度” 误差,通常是Math.pow(2,-52)
.
概念说完,咱们来看例子:
假如当初有个 DPR=1.5 的安卓机,在页面高低渲染 2 个 height = StyleSheet.hairlineWidth
的 View, 依照下面计算规定,此时 height = StyleSheet.hairlineWidth≈0.66666667
, 现实状况占据 1px 物理像素。但理论状况可能是:
因为 js 数字精度问题,Math.round(0.4 * 1.5) / 1.5
再乘 1.5
不肯定等于 1
,有可能是大于 1,有可能是小于 1,当然,也可能等于 1。
感觉困惑吗?
给你看一道常见面试题咯:0.1+0.2 === 0.3 // false
怎么样?明确了吗?哈哈
而物理像素是整个的,大于 1 时,会占据 2 个物理像素,小于 1 时可能占据 1 个也可能不占据,等于 1 时,失常显示。这就是像素网格对齐,导致设置 StyleSheet.hairlineWidth 显示呈现了 3 种状况:
- 显示比预期要粗;
- 显示失常;
- 不显示;
解决办法:
大部分状况下,StyleSheet.hairlineWidth
其实都是体现良好的。如果呈现这个问题,你能够试试选用一个 0.4~1
的一个值去设置尺寸:
wrapper:{
height:.8,
backgroundColor:'#333'
}
而后查看渲染成果,选一个最适宜的。
总结
在本文中,我首先介绍了 RN 适配的计划,并总结了一个适配口诀送给大家。如果你了解了这个口诀,就根本把握了 RN 适配;
而后,从源码的角度,带大家寻根究底讲述了适配外围 API——Dimensions
的含意以及其值的起源;最初,解释了“全屏 mask 无奈笼罩整个屏幕”以及“1 像素边框有时无奈显示”的景象或问题。
心愿你看完本文有所播种!
如果你感觉不错,欢送点赞与珍藏并举荐给身边的敌人,感谢您的激励与认可!
有任何问题也欢送留言或者私信我
原创不易,转载需获得自己批准。
FQA
- 刘海屏、异形屏怎么适配?
举荐开启“沉迷式”绘制。ios 默认开启,Android 须要设置<StatusBar translucent={true} />
。而后依据刘海、异形屏理论状况设置顶部状态栏 + 标题栏的高度。 - iPad 等大屏平板电脑怎么适配?
须要看理论业务。如果需要只需放弃跟手机端统一,那么能够间接用我的这套计划。如果还要求横屏竖屏适配,那么你须要应用Dimensions.addEventListener()
监听并设置此时 RN 视口参数,计算比例时,都以监听到的值为规范,再做适配。 - 为什么说适配是最大限度还原设计?(注释中的 [Q2])
在“1 像素边框有时无奈显示”的章节中,我提到了像素网格对齐以及 js 数字精度问题。在做适配时,咱们最终设置的值都是依据比例进行计算的,这个计算结果会有精度误差,再加上像素网格对齐,在渲染后,存在某些非凡状况,例如在某一块区域内间断渲染大量的小元素节点时,会导致与设计图存在轻微区别。