开发者控制台

Android开发者React Native指南

Anisha Malde Apr 23, 2025

React Native How to

正在考虑从Android转换为React Native？希望本指南可以帮助您转变思维，以Android背景为基础学习React Native开发。但是不要担心，谁也不会知道您在尝试“另一边”，我会为您保守秘密！😉

在从Android转换为React Native的过程中，您的学习体验将在很大程度上取决于已有Android开发背景。您本来进行的是基于“传统”视图/XML的Android开发，因此您的学习曲线将会不同于那些拥有Jetpack Compose经验的开发者。如果您对于Compose的声明式用户界面模式已经比较熟悉，那么您运气不错☺️，可以在React Native基于组件的方法中找到对应的概念。但是，如果您一直使用XML布局和命令式视图操作，那么思维转变可能会比较重要。

无论起点如何，我们都会了解一下有所不同的主要概念。在开始之前，我们先来阐明一些学习React Native的“前提条件”：

学习JavaScript - 虽然我不会详细介绍JavaScript与Java/Kotlin，但是对JavaScript的了解必不可少，因为React Native默认以TypeScript为目标。请务必先学习JavaScript，以便打下坚实的基础。
了解React基础知识 - React Native是基于React的，作为其核心概念的Reactive Native组件与React组件相同，所以您需要了解React基础知识。因此，本文提到React的所有内容都将应用于React Native。

React思维与Android思维的对比

使用React构建用户界面时，所遵循的思维模式不同于Android开发。在React中，首先需要将用户界面分解成称为组件的多个部分。然后，描述每个组件的不同视觉效果状态。最后，将多个组件联系在一起，让数据在这些组件中流动。

在Android中，架构方法取决于所选的用户界面框架。以下是简化的对比：

Amazon Appstore Android developer's guide to React Native blog image

最根本的思维转变在于React中不存在和Android相同的组件隔离。Android应用的结构以4个主要组件和意图为中心：

活动：用户交互的入口点，表示包含用户界面的单个屏幕
服务：在后台运行以执行长时间运行操作的组件
广播接收器：响应整个系统范围内广播公告的组件
内容提供方：管理共享应用数据的组件
意图：调用的异步消息，可激活活动、服务和广播接收器

在React应用中，大多数功能都以用户界面组件及其状态管理为中心，并通过不同的机制处理后台操作。

我们可以在思维模式中建立如下所示的松散对应关系：

我们来详细了解一下典型React应用的组成，看看该架构如何转换为常见应用构建块：

在React Native中，应用的结构以组件及其交互为中心，这意味着不存在规定的结构，而是由您来决定应用组件和数据流的最佳建构方式。这也意味着您需要有意识地做出关于如何组织代码的决策。

如下所示为典型的React Native项目结构：

my-app/
├── android/                # 原生Android项目文件 
├── ios/                    # 原生iOS项目文件
├── node_modules/           # NPM依赖项（等同于Gradle依赖项）
├── src/                    # 您的JavaScript/TypeScript代码（类似Android中的app/src/main）
│   ├── components/         # 可重复使用的用户界面组件
│   ├── screens/            # 屏幕组件 
│   ├── navigation/         # 导航配置
│   ├── services/           # API调用、业务逻辑
│   ├── hooks/              # 自定义挂钩
│   ├── context/            # React上下文定义
│   ├── utils/              # 辅助函数 
│   └── assets/             # 图像、字体等（类似res/directory）
├── App.js                  # 根目录组件（等同于Application类）
├── index.js                # 入口点（类似MainActivity）
├── package.json            # NPM配置（等同于build.gradle）
├── metro.config.js         # Metro Bundler配置（类似Gradle配置）
├── babel.config.js         # Babel转译器配置
└── tsconfig.json           # TypeScript配置

现在，我们已经理清了Android和React Native的基础架构概念之间的对应关系，并详细了解了典型的项目结构，接下来让我们在思维模式中建立React Native应用核心构建块的对应关系。

用户界面：组件、布局和样式

组件思维模式

在Android中，用户界面构建块为视图/视图组（传统开发）和可组合函数（Jetpack Compose）。在React Native中，一切都是组件。

传统Android开发是命令式的，需要手动操作用户界面。React Native是声明式的，需要描述用户界面的视觉效果。

布局

React Native使用Flexbox处理布局，该方法不同于Android的传统XML布局系统：

布局容器：使用具有flex属性的视图组件，而非LinearLayout、RelativeLayout或ConstraintLayout
单位：使用与平台无关、可根据设备设置自动扩缩的单位，而非dp或sp
定位：使用justifyContent和alignItems等属性，而非Android的gravity属性

样式

React Native提供了类似CSS的样式系统，会让Android开发者感到既熟悉又有所不同，因为它结合了Web CSS和原生移动端开发中的概念：

React Native使用JavaScript对象来处理样式，而非使用XML样式资源或Compose的修饰符系统。然后将这些样式应用于组件——可以直接应用于内联组件，也可使用StyleSheet API。

import { View, Text, StyleSheet } from "react-native";

function StyleExample() {
  return (
    // StyleSheet示例
    <View style={styles.container}>
      // 内联组件示例
      <Text
        style={{
          fontSize: 16,
          color: "blue",
        }}
      >
        内联样式示例
      </Text>
    </View>
  );
}

// StyleSheet定义
const styles = StyleSheet.create({
  container: {
    padding: 16,
  },
});

没有资源限定符：没有像Android的资源限定符那样用于处理不同屏幕尺寸/方向的内置系统
响应式设计：依靠百分比值、flex属性和Dimensions API，而非不同的布局文件
样式重置：默认不存在全局样式继承；每个组件都需要显式指定样式

// 在React Native中，以下方法无法正常工作：
<View style={{ color: 'red' }}>
  <Text>文本不会显示为红色</Text>
</View>

// 每个组件都需要显式指定样式：
<View style={{ backgroundColor: 'blue' }}>
  <Text style={{ color: 'red' }}>文本将显示为红色</Text>
</View>

密度调整：Android使用特定的密度桶（mdpi、hdpi等），而React Native采用抽象方法去掉了这些单位。 React Native中的所有尺寸都没有单位，表示与密度无关的像素。
没有XML资源：没有像Android那样的独立样式文件或资源限定符
没有内置主题/设计系统：没有直接等同于Android主题系统的组件；通常通过上下文管理主题

状态

和架构方面的差异类似，您采用的状态管理方法也会因您本来进行的是“传统”Android开发还是Jetpack Compose开发而异。

核心状态组件 - 属性、上下文和挂钩

属性：属性是从父组件传递到子组件的不可变数据。由于属性是不可变的，因此它们有助于实现组件的重复使用。

在Android领域，属性类似于：

传递到Fragment的实际参数
传递到活动的意图附加信息
传递到构造函数的参数

挂钩：React提供的一类函数，让开发者能够从组件钩入React功能。

上下文：上下文提供了一种通过组件树传递数据的方式，不必在每一级都手动向下传递属性。

核心状态概念

将状态作为单一事实来源

不要考虑如何更新用户界面，而是要考虑用户界面在给定状态下应有的视觉效果。要让用户界面反映状态，而不能本末倒置。

将组件作为纯函数
给定同一属性/状态，组件应始终以同一方式进行渲染。通过useEffect单独处理附带效应。

不可变的更新

不是在原有位置修改视图，而是创建新的状态来描述更新后的视图。

组件生命周期

在传统Android开发中，您需要使用一组生命周期回调在活动状态存在期间对其进行管理，而React Native会使用更简单的挂载/卸载生命周期模式，通过组件级别的useEffect挂钩“访问”活动状态。两者对比如下：

没有内置系统：不同于Android的核心意图和活动系统，React Native没有内置导航框架。取而代之的是，您需要选择第三方库，而React Navigation是最为广泛采用的解决方案。
基于组件：通过组件实现导航，而非通过系统级别的意图。
基于堆栈的模式：类似于Android的返回堆栈，但使用JavaScript来实现。导航路由和转换是使用JavaScript定义的，而非使用XML或系统调用。

虽然Android和React Native的基础导航概念仍然具有相似性，但实现方法有所不同，我们还可以在思维模式中建立如下所示的对应关系：

// Android意图同等方法
function HomeScreen({ navigation }) {
  return (
    <Button
      title="前往详情"
      onPress={() => {
        // 替代指定意图的startActivity()
        navigation.navigate('Details', {
          itemId: 86,
          title: '产品详情',
        });
      }}
    />
  );
}

// 访问路由参数（类似于意图附加信息）
function DetailsScreen({ route }) {
  const { itemId, title } = route.params;
  
  return (
    <View>
      <Text>{title}详情</Text>
      <Text>Item ID: {itemId}</Text>
    </View>
  );
}

业务逻辑

从Android转换为React Native时，在用户界面与业务逻辑之间的关系方面需要进行巨大的思维转变。

在Android开发中

用户界面和业务逻辑代码通常作为同等事项存在
MVVM、MVP或MVC等架构模式清晰地将表现与业务逻辑分离开来
后端代码（存储库、服务、管理器）往往给人以重要性不亚于用户界面代码的感觉
用户界面常常被视为渲染数据的“视图而已”

在React Native开发

用户界面组件和业务逻辑更紧密地整合在一起
组件既执行表现，也执行逻辑行为
该架构在更大程度上“将用户界面放在前面”，让逻辑服务于用户界面
挂钩在同一组件内将用户界面事项和逻辑事项融合

在React Native中，您很可能会首先设计用户界面，然后添加其所需的逻辑，而非首先设计后端服务。这种“用户界面驱动”的方法源自React基于组件的架构，该架构将组件作为主要构建块。随着项目变得越来越复杂，您可能仍会将纯业务逻辑提取到自定义挂钩、上下文或服务中，如上文中示例项目结构所示。随着React Native开发继续进行，您很可能会形成自己的风格来平衡这些事项。

虽然React Native更改了用户界面与业务逻辑之间关系的建构方式，但后端服务（API客户端、数据解析和状态同步）在概念上仍然与Android相似，而且后端服务可同时支持Android应用和React Native应用。在React Native中，通常使用以下库：

Fetch或axios用于API调用
AsyncStorage用户数据持久化
Native Modules用于平台API/功能

关键区别不在于所需的后端服务，而在于后端服务如何与组件结构集成。您往往会创建自定义挂钩来封装数据获取和状态管理，然后直接在组件中使用这些挂钩。

结论

希望本指南可以帮助您在思维模式中建立React Native与Android开发中一些常见概念的对应关系。但是请记住，在思维模式中建立这种对应关系仅仅是开端。以上对比可以作为起点来帮助您了解React与Android的区别，但不能取代更深入的学习和实践。要继续学习React Native，可以参考以下重要资源：