写在后面

在我从事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} = dimsconst {windowPhysicalPixels} = dimsconst {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层到原生层讲述了DimensionsAPI，好吧，讲这一个就啰里啰嗦的了，各位看官明确了吗？

全屏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数字精度问题。在做适配时，咱们最终设置的值都是依据比例进行计算的，这个计算结果会有精度误差，再加上像素网格对齐，在渲染后，存在某些非凡状况，例如在某一块区域内间断渲染大量的小元素节点时，会导致与设计图存在轻微区别。