Java 关键字之 native 详解

篇博客我们将介绍Java中的一个关键字——native。

native 关键字在 JDK 源码中很多类中都有，在 Object.java类中，其 getClass() 方法、hashCode()方法、clone() 方法等等都是用 native 关键字修饰的。

那么为什么要用 native 来修饰方法，这样做有什么用？

1、JNI：Java Native Interface

在介绍 native 之前，我们先了解什么是 JNI。

一般情况下，我们完全可以使用 Java 语言编写程序，但某些情况下，Java 可能会不满足应用程序的需求，或者是不能更好的满足需求，比如：

①、标准的 Java 类库不支持应用程序平台所需的平台相关功能。
②、我们已经用另一种语言编写了一个类库，如何用Java代码调用？
③、某些运行次数特别多的方法代码，为了加快性能，我们需要用更接近硬件的语言（比如汇编）编写。

上面这三种需求，其实说到底就是如何用 Java 代码调用不同语言编写的代码。那么 JNI 应运而生了。

从Java 1.1开始，Java Native Interface (JNI)标准就成为java平台的一部分，它允许Java代码和其他语言写的代码进行交互。JNI一开始是为了本地已编译语言，尤其是C和C++而设计的，但是它并不妨碍你使用其他语言，只要调用约定受支持就可以了。使用java与本地已编译的代码交互，通常会丧失平台可移植性。但是，有些情况下这样做是可以接受的，甚至是必须的，比如，使用一些旧的库，与硬件、操作系统进行交互，或者为了提高程序的性能。JNI标准至少保证本地代码能工作在任何Java 虚拟机实现下。　　

通过 JNI，我们就可以通过 Java 程序（代码）调用到操作系统相关的技术实现的库函数，从而与其他技术和系统交互，使用其他技术实现的系统的功能；同时其他技术和系统也可以通过 JNI 提供的相应原生接口开调用 Java 应用系统内部实现的功能。

在windows系统上，一般可执行的应用程序都是基于 native 的PE结构，windows上的 JVM也是基于native结构实现的。Java应用体系都是构建于 JVM 之上。　　

可能有人会问，Java不是跨平台的吗？如果用 JNI，那么程序不就将失去跨平台的优点?确实是这样的。

JNI 的缺点：

①、程序不再跨平台。要想跨平台，必须在不同的系统环境下重新编译本地语言部分。

②、程序不再是绝对安全的，本地代码的不当使用可能导致整个程序崩溃。一个通用规则是，你应该让本地方法集中在少数几个类当中。这样就降低了JAVA和C之间的耦合性。

目前来讲使用 JNI 的缺点相对于优点还是可以接受的，可能后面随着 Java 的技术发展，我们不在需要 JNI，但是目前 JDK 还是一直提供对 JNI 标准的支持。

2、用C语言编写程序本地方法

上面讲解了什么是 JNI，那么我们接下来就写个例子，如何用 Java 代码调用本地的 C 程序。

步骤如下：

①、编写带有 native 声明的方法的java类，生成.java文件；(注意这里出现了 native 声明的方法关键字）

②、使用 javac 命令编译所编写的java类，生成.class文件；

③、使用 javah -jni java类名生成扩展名为 h 的头文件，也即生成.h文件；

④、使用C/C++（或者其他编程想语言）实现本地方法，创建.h文件的实现，也就是创建.cpp文件实现.h文件中的方法；

⑤、将C/C++编写的文件生成动态连接库，生成dll文件；

下面我们通过一个 HelloWorld 程序的调用来完成这几个步骤。

注意：下面所有操作都是在所有操作都是在目录：D:\JNI 下进行的。

一、编写带有native声明的方法的java类

用 native 声明的方法表示告知 JVM 调用，该方法在外部定义，也就是我们会用 C 语言去实现。

System.loadLibrary("helloJNI");加载动态库，参数 helloJNI 是动态库的名字。我们可以这样理解：程序中的方法helloJNI() 在程序中没有实现，但是我们下面要调用这个方法，怎么办呢？我们就需要对这个方法进行初始化，所以用 static 代码块进行初始化。

这时候如果我们直接运行该程序，会报“A Java Exception has occurred”错误：　　

二、使用javac命令编译所编写的java类，生成.class文件

执行上述命令后，生成 HelloJNI.class 文件：

三、使用javah -jni java类名生成扩展名为 h 的头文件

执行上述命令后，在 D:/JNI 目录下多出了个 HelloJNI.h 文件：

四、使用C语言实现本地方法

如果不想安装visual studio的，我们需要在 windows平台安装 gcc。

注意安装版本的选择，根据系统是32位还是64位来选择。

安装完成之后注意配置环境变量，在 cmd 中输入 g++ -v，如果出现如下信息，则安装配置完成：　　

接着输入如下命令：

-m64表示生成dll库是64位的。后面的路径表示本机安装的JDK路径。生成之后多了一个helloJNI.dll 文件

最后运行 HelloJNI：输出 Hello JNI! 大功告成。　　

3、JNI调用C的流程图

4、native关键字

通过上面介绍了那么多JNI的知识，终于到介绍本篇文章的主角——native 关键字了。相信大家看完上面的介绍，应该也是知道什么是 native 了吧。

native 用来修饰方法，用 native 声明的方法表示告知 JVM 调用，该方法在外部定义，我们可以用任何语言去实现它。简单地讲，一个native Method就是一个 Java 调用非 Java 代码的接口。

native 语法：

①、修饰方法的位置必须在返回类型之前，和其余的方法控制符前后关系不受限制。

②、不能用 abstract 修饰，也没有方法体，也没有左右大括号。

③、返回值可以是任意类型

我们在日常编程中看到native修饰的方法，只需要知道这个方法的作用是什么，至于别的就不用管了，操作系统会给我们实现。

如若转载，请注明出处：开源字节 https://sourcebyte.vip/article/385.html

者｜Lukas Gisder-Dubé

译者｜谢丽

本文将分三部分分析 JavaScript 中的错误，首先我们将了解错误的一般情况，之后，我们将关注后端（Node.js + Express.js），最后，我们将重点看下如何处理 React.js 中的错误。选择这些框架，是因为它们是目前最流行的，但是，你应该也能够将这些新发现应用到其他框架中吧！

继上一篇文章 (https://link.medium.com/MO32x55aNR) 之后，我想谈谈错误。错误很好——我相信你以前听过这个说法。乍一看，我们害怕错误，因为错误往往会涉及到在公共场合受到伤害或羞辱。通过犯错误，我们实际上学会了如何不去做某事，以及下次如何做得更好。

显然，这是关于从现实生活的错误中学习。编程中的错误有点不同。它们为我们提供了很好的特征来改进我们的代码，并告诉用户什么地方出了问题（也可能是教他们如何修复它）。

GitHub(https://github.com/gisderdube/graceful-error-handling) 上提供了一个完整的样例项目。

JavaScript 错误和一般处理

throw new Error('something went wrong')?会在 JavaScript 中创建一个错误实例，并停止脚本的执行，除非你对错误做了一些处理。当你作为 JavaScript 开发者开启自己的职业生涯时，你自己很可能不会这样做，但是，你已经从其他库（或运行时）那里看到了，例如，类似“ReferenceError: fs 未定义”这样的错误。

Error 对象

Error 对象有两个内置属性供我们使用。第一个是消息，作为参数传递给 Error 构造函数，例如 new Error(“这是错误消息”)。你可以通过 message 属性访问消息：

const myError=new Error(‘请改进代码’)
console.log(myError.message) // 请改进代码

第二个是错误堆栈跟踪，这个属性非常重要。你可以通过 stack 属性访问它。错误堆栈将为你提供历史记录（调用堆栈），从中可以查看哪个文件导致了错误。堆栈的上部也包括消息，然后是实际的堆栈，从距离错误发生最近的点开始，一直到最外层“需要为错误负责”的文件：

Error: 请改进代码
 at Object.<anonymous> (/Users/gisderdube/Documents/_projects/hacking.nosync/error-handling/src/general.js:1:79)
 at Module._compile (internal/modules/cjs/loader.js:689:30)
 at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
 at Module.load (internal/modules/cjs/loader.js:599:32)
 at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
 at Function.Module._load (internal/modules/cjs/loader.js:530:3)
 at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)
 at startup (internal/bootstrap/node.js:266:19)
 at bootstrapNodeJSCore (internal/bootstrap/node.js:596:3)

抛出和处理错误

现在，Error 实例本身不会导致任何结果，例如，new Error('...') 不会做任何事情。当错误被抛出时，就会变得更有趣。然后，如前所述，脚本将停止执行，除非你在流程中以某种方式对它进行了处理。记住，是手动抛出错误，还是由库抛出错误，甚至由运行时本身（Node 或浏览器），都没有关系。让我们看看如何在不同的场景中处理这些错误。

try .... catch

这是最简单但经常被遗忘的错误处理方法——多亏 async / await，它的使用现在又多了起来。它可以用来捕获任何类型的同步错误，例如，如果我们不把 console.log(b) 放在一个 try … catch 块中，脚本会停止执行。

… finally

有时候，不管是否有错误，代码都需要执行。你可以使用第三个可选块 finally。通常，这与在 try…catch 语句后面加一行代码是一样的，但它有时很有用。

异步性——回调

异步性，这是在使用 JavaScript 时必须考虑的一个主题。当你有一个异步函数，并且该函数内部发生错误时，你的脚本将继续执行，因此，不会立即出现任何错误。当使用回调函数处理异步函数时（不推荐），你通常会在回调函数中收到两个参数，如下所示：

如果有错误，err 参数就等同于那个错误。如果没有，参数将是 undefined 或 null。要么在 if(err) 块中返回某项内容，要么将其他指令封装在 else 块中，这一点很重要，否则你可能会得到另一个错误，例如，result 可能未定义，而你试图访问 result.data，类似这样的情况。

异步性——Promises

处理异步性的更好方法是使用 Promises。在这一点上，除了代码可读性更强之外，我们还改进了错误处理。只要有一个 catch 块，我们就不再需要太关注具体的错误捕获。在链接 Promises 时，catch 块捕获会自 Promises 执行或上一个 catch 块以来的所有错误。注意，没有 catch 块的 Promises 不会终止脚本，但会给你一条可读性较差的消息，比如：

(node:7741) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: something went wrong
(node:7741) DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. */

因此，务必要在 Promises 中加入 catch 块。

回到 try … catch

随着 JavaScript 引入 async / await，我们回到了最初的错误处理方法，借助 try … catch … finally，错误处理变得非常简单。

因为这和我们处理“普通”同步错误的方法是一样的，所以如果需要的话，更容易使用作用域更大的 catch 语句。

服务器端错误的产生和处理

现在，我们已经有了处理错误的工具，让我们看下，我们在实际情况下能用它们做什么。后端错误的产生和处理是应用程序至关重要的组成部分。对于错误处理，有不同的方法。我将向你展示一个自定义 Error 构造函数和错误代码的方法，我们可以轻松地传递到前端或任何 API 消费者。构建后端的细节并不重要，基本思路不变。

我们将使用 Express.js 作为路由框架。让我们考虑下最有效的错误处理结构。我们希望：

一般错误处理，如某种回退，基本上只是说：“有错误，请再试一次或联系我们”。这并不是特别聪明，但至少通知用户，有地方错了——而不是无限加载或进行类似地处理。
特殊错误处理为用户提供详细信息，让用户了解有什么问题以及如何解决它，例如，有信息丢失，数据库中的条目已经存在等等。

构建一个自定义 Error 构造函数

我们将使用已有的 Error 构造函数并扩展它。继承在 JavaScript 中是一件危险的事情，但根据我的经验，在这种情况下，它非常有用。我们为什么需要它？我们仍然希望堆栈跟踪给我们一个很好的调试体验。扩展 JavaScript 原生 Error 构造函数可以让我们方便地获得堆栈跟踪。我们唯一要做的是添加代码（我们稍后可以通过错误代码访问）和要传递给前端的状态（http 状态代码）。

如何处理路由

在完成 Error 的自定义之后，我们需要设置路由结构。正如我指出的那样，我们想要一个单点真错误处理，就是说，对于每一个路由，我们要有相同的错误处理行为。在默认情况下，由于路由都是封装的，所以 Express 并不真正支持那种方式。

为了解决这个问题，我们可以实现一个路由处理程序，并把实际的路由逻辑定义为普通的函数。这样，如果路由功能（或任何内部函数）抛出一个错误，它将返回到路由处理程序，然后可以传给前端。当后端发生错误时，我们可以用以下格式传递一个响应给前端——比如一个 JSON API：

{
 error: 'SOME_ERROR_CODE',
 description: 'Something bad happened. Please try again or contact support.'
}

准备好不知所措。当我说下面的话时，我的学生总是生我的气：

如果你咋看之下并不是什么都懂，那没问题。只要使用一段时间，你就会发现为什么要那样。

顺便说一下，这可以称为自上而下的学习，我非常喜欢。

路由处理程序就是这个样子：

我希望你能读下代码中的注释，我认为那比我在这里解释更有意义。现在，让我们看下实际的路由文件是什么样子：

在这些例子中，我没有做任何有实际要求的事情，我只是假设不同的错误场景。例如，GET /city 在第 3 行结束，POST /city 在第 8 号结束等等。这也适用于查询参数，例如，GET /city?startsWith=R。本质上，你会有一个未处理的错误，前端会收到：

{
 error: 'GENERIC',
 description: 'Something went wrong. Please try again or contact support.'
}

或者你将手动抛出 CustomError，例如：

throw new CustomError('MY_CODE', 400, 'Error description')

上述代码会转换成：

{
 error: 'MY_CODE',
 description: 'Error description'
}

既然我们有了这个漂亮的后端设置，我们就不会再把错误日志泄漏到前端，而总是返回有用的信息，说明出现了什么问题。

确保你已经在 GitHub(https://github.com/gisderdube/graceful-error-handling) 上看过完整的库。你可以把它用在任何项目中，并根据自己的需要来修改它！

向用户显示错误

下一个也是最后一个步骤是管理前端的错误。这里，你要使用第一部分描述的工具处理由前端逻辑产生的错误。不过，后端的错误也要显示。首先，让我们看看如何显示错误。如前所述，我们将使用 React 进行演练。

把错误保存在 React 状态中

和其他数据一样，错误和错误消息会变化，因此，你想把它们放在组件状态中。在默认情况下，你想要在加载时重置错误，以便用户第一次看到页面时，不会看到错误。

接下来我们必须澄清的是不同错误类型及与其匹配的可视化表示。就像在后端一样，有 3 种类型：

全局错误，例如，其中一个常见的错误是来自后端，或者用户没有登录等。
来自后端的具体错误，例如，用户向后端发送登录凭证。后端答复密码不匹配。前端无法进行此项验证，所以这样的信息只能来自后端。
由前端导致的具体错误，例如，电子邮件输入验证失败。

2 和 3 非常类似，虽然源头不一样，但如果你愿意，就可以在同样的 state 中处理。我们将从代码中看下如何实现。

我将使用 React 的原生 state 实现，但是，你还可以使用类似 MobX 或 Redux 这样的状态管理系统。

全局错误

通常，我将把这些错误保存在最外层的有状态组件中，并渲染一个静态 UI 元素，这可能是屏幕顶部的一个红色横幅、模态或其他什么东西，设计实现由你决定。

让我们看下代码：

正如你看到的那样，Application.js 中的状态存在错误。我们也有方法可以重置并改变错误的值。我们把值和重置方法传递给 GlobalError 组件，在点击'x'时，该组件会显示错误并重置它。让我们看看 GlobalError 组件：

你可以看到，在第 5 行，如果没有错误，我们就不做任何渲染。这可以防止我们的页面上出现一个空的红框。当然，你可以改变这个组件的外观和行为。例如，你可以将“x”替换为 Timeout，几秒钟后重置错误状态。

现在，你已经准备好在任何地方使用全局错误状态了，只是从 Application.js 把 _setError 向下传递，而且，你可以设置全局错误，例如，当一个请求从后端返回了字段 error: 'GENERIC'。例如：

如果你比较懒，到这里就可以结束了。即使你有具体的错误，你总是可以改变全局错误状态，并把错误提示框显示在页面顶部。不过，我将向你展示如何处理和显示具体的错误。为什么？首先，这是关于错误处理的权威指南，所以我不能停在这里。其次，如果你只是把所有的错误都作为全局错误来显示，那么体验人员会疯掉。

处理具体的请求错误

和全局错误类似，我们也有位于其他组件内部的局部错误状态，过程相同：

有件事要记住，清除错误通常有一个不同的触发器。用' x '删除错误是没有意义的。关于这一点，在发出新请求时清除错误会更有意义。你还可以在用户进行更改时清除错误，例如当修改输入值时。

源于前端的错误

如前所述，这些错误可以使用与处理后端具体错误相同的方式（状态）进行处理。这次，我们将使用一个有输入字段的示例，只允许用户在实际提供以下输入时删除一个城市：

使用错误代码实现错误国际化

也许你一直想知道为什么我们有这些错误代码，例如 GENERIC ，我们只是显示从后端传递过来的错误描述。现在，随着你的应用越来越大，你就会希望征服新的市场，并在某个时候面临多种语言支持的问题。如果你到了这个时候，你就可以使用前面提到的错误代码使用用户的语言来显示恰当的描述。

我希望你对如何处理错误有了一些了解。忘掉 console.error(err)，它现在已经是过去时了。可以使用它进行调试，但它不应该出现在最终的产品构建中。为了防止这种情况，我建议你使用日志库，我过去一直使用 loglevel，我对它非常满意。

英文原文

https://levelup.gitconnected.com/the-definite-guide-to-handling-errors-gracefully-in-javascript-58424d9c60e6

者 | 魔笛
责编 | 郭芮

2015年3月，Facebook正式发布react-native，只支持iOS平台；2015年9月，Facebook发布了React Native for Android，让这一技术正式成为跨平台开发框架。

我们团队是在2016年中期开始接触并使用react-native, 起初团队有很多反对声，其中：

iOS平台严格的审核制度，还有后来的JSPatch风波，担心有热更新的能力的react-native也会被禁用，还好react-native是以js.bundle为资源加载的沙盒热更新；
React Native的性能能达到上限问题。

当时选择react-native的几个重要因素：

跨平台：这可能是最重要的原因了，可以节省人力；
基于React框架开发，组建化，响应式思路，调试方式可以缩短开发周期（在开发者熟练使用的情况下），也可以调整前端开发资源；
热更新：APP当时修复BUG基本都是重新发版，周期比较长，热更新是解决这一个痛点是最好的选择；
新技术调研，扩展技术栈。

移动框架学习套路

每次接触一个新技术、新框架我们总是一头雾水。其实是有套路的，有经验的程序员会说这就是思想，下面主要从移动开发这几个方面调研：

计算机语言工具
环境搭建
UI绘制
基本布局方式
基本tab + navigator的APP框架搭建
网络请求(http, https, 上传，下载等)
缓存, 本地存储
图片
平台特性处理：例如推送，支付等等iOS，安卓不同的平台代码如何处理
调试工具：好的调试工具不但可以事半功倍，还可以给开发者愉悦的心情开发
静态代码检查（这个对于解释型的JS语言很重要）
Unit Test
CI集成方式

以上几个方面都研究明白了，整个react-native生产链路就调研完成了。

技术栈

针对上面的过程总结一下技术栈。

需要的语言&框架

JavaScript - ECMAScript6：React Native是以JavaScript作为语言工具开发；
React : 起源于 Facebook 的内部项目, 因为该公司对市场上所有 JavaScript MVC 框架，都不满意，就决定自己写一套，用来架设 Instagram 的网站。做出来以后，发现这套东西很好用，在2013年5月开源. 由于 React 的设计思想极其独特，属于革命性创新，性能出众，代码逻辑却非常简单。所以，越来越多的人开始关注和使用，认为它可能是将来 Web 开发的主流工具。
简单直观、符合习惯的（idiomatic）方式去编程，让代码更容易被理解，从而易于维护和不断演进。这正是React的设计哲学；
flex 布局 : 布局方式；
redux : JS 状态容器，提供可预测化的状态管理, 实现view & state 分离，开发体验超爽，而且体小精悍（只有2K）；
immutable.js :“Pete Hunt: Shared mutable state is the root of all evil（共享的可变状态是万恶之源）”, 有人说 Immutable 可以给 React 应用带来数十倍的提升，也有人说 Immutable 的引入是近期 JavaScript 中伟大的发明, Facebook 工程师 Lee Byron 花费 3 年时间打造，与 React 同期出现；
Immutable 详解及 React 中实践（https://github.com/camsong/blog/issues/3）。

如何进行环境搭建

node.js RN的调试服务基于node服务器；
npm js包管理工具；
Yarn是Facebook提供的替代npm的工具，可以加速node模块的下载。React Native的命令行工具用于执行创建、初始化、更新项目、运行打包服务（packager）等任务；
react-native 环境搭建（https://facebook.github.io/react-native/docs/getting-started.html）。

如何进行UI绘制与布局

React Native 提供丰富的基础组件库，使用Flexbox布局规则。采用jsx更直观的表达用户界面结构。

import React, {Component} from 'react'
import {View, Text, Button, StyleSheet} from 'react-native'
export class Home extends Component {
 state={
 number: 0
 }
 _increase() {
 const { number }=this.state
 this.setState({number: number + 1})
 }
 _decrease() {
 const { number }=this.state
 this.setState({number: number - 1})
 }
 render() {
 const { number }=this.state
 return (
 <View style={styles.container}>
 <Text>Home</Text>
 <Button title="加" onPress={this._increase.bind(this)}/> 
 <Button title="减" onPress={this._decrease.bind(this)}/> 
 <Text>{number}</Text>
 </View>
 )
 }
}
let styles=StyleSheet.create({
 container: {
 flex: 1,
 backgroundColor: '#fff'
 }
})

上例绘制一个简单的页面, View是最基础的UI组件，并且支持Flexbox布局，Text是用于显示文本的组件，Button从命名上就可以明确是按钮组件，StyleSheet 提供了一种类似 CSS 样式表的抽象。

调试

调试是开发流程中最重要的事情，下面两个工具给RN开发带来了超爽的体验

RN 调试工具：react-native-debugger
https://github.com/jhen0409/react-native-debugger
redux 开发扩展插件：redux-devtools-extension
https://github.com/zalmoxisus/redux-devtools-extension

静态代码检查

JavaScript是解释型语言，编译过程只有词法分析和语法分析，并没有词法检查，eslint对于JS的意义格外重要：

避免隐藏错误；
代码统一规范，提高可读性。

代码质量的保证

redux unit test：对于actions & reduce校验不可少（https://redux.js.org/docs/recipes/WritingTests.html）；
Jest：很棒的BDD（https://facebook.github.io/jest/docs/en/tutorial-react-native.html，PS：每当发现一个工具特别好用的时候，发现都是Facebook开源的）；
fetch-mock：异步单测不可少（http://www.wheresrhys.co.uk/fetch-mock/）。

CI 可以用以下工具

travis-ci：GitHub最流行的CI工具之一（https://travis-ci.org/）；
circle-ci：react-native GitHub库使用的CI工具（https://circleci.com/）；
gitlab-ci：目前我司用的是gitlab ci（https://about.gitlab.com/features/gitlab-ci-cd/）。

转场

tab-navigator框架：流畅的转场动画对于App体验很重要；
react-navigation：RN社区今后主推的方案是一个单独的导航库react-navigation（https://reactnavigation.org/），它的使用十分简单。性能上在原生线程上的Animated动画库，因而性能表现十分流畅，此外其动画形式和手势都非常便于定制。

状态管理

view与状态分离：Redux由Flux演变而来，但受Elm的启发，避开了Flux的复杂性。不管你有没有使用过它们，只需几分钟就能上手Redux。
单向数据流：应用中所有的state都以一个对象树的形式储存在一个单一的store中。惟一改变state的办法是触发action，一个描述发生什么的对象。为了描述action如何改变state树，你需要编写reducers。

如何做网络请求

使用fetch（https://facebook.github.io/react-native/docs/network）；

fetch('https://mywebsite.com/endpoint/', {
 method: 'POST',
 headers: {
 Accept: 'application/json',
 'Content-Type': 'application/json',
 },
 body: JSON.stringify({
 firstParam: 'yourValue',
 secondParam: 'yourOtherValue',
 }),
});

react-native-fetch-blob：更好的数据传输工具（https://github.com/wkh237/react-native-fetch-blob）。

如何本地存储

AsyncStorage：使用起来非常简单的Key-Value Coding, 返回Promise；

import { AsyncStorage } from 'react-native'
let kLoginInfo='@login:info'
//存储
AsyncStorage.setItem(kLoginInfo, JSON.stringify(loginInfo))
//删除
AsyncStorage.removeItem(kLoginInfo)
//加载
AsyncStorage.getItem(kLoginInfo)

iOS内部是用一个json文件实现永久性存储， Android方面据官方了解是会尝试使用RocksDB，或退而选择 SQLite；
集成redux存储（https://github.com/rt2zz/redux-persist）；
也可尝试一下款平台数据库realm（https://realm.io/docs/javascript/latest/v）。

热更新

这是React Native的一个重要功能，苹果去年有过一次对热修复的严打，JSPatch惨遭扼杀，不过对于RN这样的沙盒热更新是可以的；
微软的hot-push是个不错的工具（https://github.com/Microsoft/react-native-code-push）；
有条件的单位可以自己建热修复服务，下载bundle包。

native组件开发

React Native可能还没有相应的模块封装，但是提供native组件开发能力。利用这种方式解决平台特性，支付、推送、Face ID都可以封装成native组件来解决：
iOS原生模块（https://reactnative.cn/docs/native-modules-ios）
iOS原生UI组件（https://reactnative.cn/docs/native-components-ios/）
安卓原生模块（https://reactnative.cn/docs/native-modules-android/）
安卓原生UI组件（https://reactnative.cn/docs/native-components-android/）
rnstart：是根据上面技术栈搭建的react native starter demo工程（https://github.com/jeremyzj/rnstarter）。

未来展望

论成熟度、稳定性，RN 比不上iOS和Android原生，也存在很多奇怪的BUG，习惯了OC、Java语言开发的对于JS缺少类型系统很失望，对于手动操作动画也依然无解，长列表性能问题无解、手势操作不够灵活、iOS podfile维护也不给力........等等问题。

很多单位采用模块化方案，让App有RN的能力，让业务交互简单的模块来用react-native开发。但是Facebook依然很努力地在改变，2018年对react-native有了一次大的重构，目的更轻量化并能更好地适应现有的原生应用，更符合JS的生态系统。

对于移动开发者而言，react-native只是开发箱中其中一种工具。丰富自己工具箱，才能有更宽的视野和更多的开发思路。

作者：魔笛，从事移动端开发7+年的经验，目前在某互联网金融公司作为iOS端leader工作。
声明：本文为作者投稿，版权归对方所有。

在线咨询

上一篇：Python模拟登录淘宝并获取所有订单，双十一你下了
下一篇：CDN防御解析（综合应对不同类型攻击，确保网站稳定）

您的项目需求

*请认真填写需求信息，我们会在24小时内与您取得联系。

整合营销服务商