Android開(kāi)發(fā)者入門(mén)React Native指南
正考虑从Android转到React Native吗?希望这份指南能帮助你从Android转到学习React Native开发。别担心,我不会告诉任何人你正在“尝试另一边”的,你的秘密我会帮你保密!😉
你的学习经历从 Android 转向 React Native 主要取决于你现有的 Android 开发背景。如果你之前从事的是基于传统 View/XML 的开发,那么与那些拥有 Jetpack Compose 经验的人来说,你的学习曲线会有所不同。如果你已经熟悉 Compose 的声明式 UI 模型,那你真是太幸运了 ☺️,你会发现 React Native 的组件驱动方法中也有类似的概念。然而,如果你一直在处理 XML 布局和指令式的 View 操作,那么这种思维上的转变可能更为显著。
无论你从哪里开始,我们将看看一些主要的概念及其差异。在开始之前,让我们先澄清你React Native学习之路的一些前提条件:
-
学习 JavaScript - 虽然我不会深入讨论 JavaScript 与 Java/Kotlin 的区别,但掌握 JavaScript 很重要,因为 React Native 默认使用的是 TypeScript。请先学好 JavaScript,打好基础。
- 了解 React 基础 - React Native 是基于 React 开发的,所以你需要掌握 React 的基础知识,因为它们的核心概念是一样的。因此,本文中提到 React 的部分也适用于 React Native。
当使用React构建用户界面时,你遵循的思维方式与Android开发不同。在使用React时,你首先将UI拆分为一个个称为组件的部分。然后,你将为每个组件描述不同的外观状态。最后,将这些组件连接起来,使数据能够在它们之间流动。
在 Android 中,你的架构方法会根据你选择的用户界面框架来定。这里有一个简单的对比:
最基本的思想转变是,React 并不像 Android 那样有相同的组件隔离性。Android 应用程序围绕四个主要组件和意图设计:
- 活动:用户交互的入口,代表一个具有UI的单独屏幕
- 服务:在后台运行的组件,用于执行长时间运行的任务
- 广播接收器:响应系统范围内的广播消息的组件
- 内容提供者:管理应用程序间共享数据的组件
- 意图:用于激活活动、服务和广播接收器的异步消息
在 React 应用中,大部分功能集中在 UI 组件和它们的状态管理上,而后台操作则是通过不同的方式来处理的。
如果我们松散地构建一下我们的心理模型,
让我们来看看一个典型的 React 应用的组成,并看看它是如何用常用的构建模块来构建的。
在 React Native 中,你通过组件及其交互来构建应用程序,这意味着它没有固定的结构。相反,它让你决定如何最合适的组织组件和数据流。这也意味着你需要有意地组织你的代码。
一个典型的 React Native 项目结构可能像这样。
my-app/
├── android/ # Android 原生项目文件
├── ios/ # iOS 原生项目文件
├── node_modules/ # NPM 依赖包(类似于 Gradle 依赖)
├── src/ # 您的 JavaScript/TypeScript 代码(类似于 Android 中的 app/src/main)
│ ├── components/ # 可复用 UI 组件
│ ├── screens/ # 页面组件
│ ├── navigation/ # 导航配置
│ ├── services/ # API 调用及业务逻辑
│ ├── hooks/ # 自定义 Hooks
│ ├── context/ # React 上下文
│ ├── utils/ # 辅助函数(类似于 res 目录中的资源)
│ └── assets/ # 图片、字体等资源(类似于 res 目录)
├── App.js # 根组件(类似于 Android 中的 Activity 类)
├── index.js # 入口文件(类似于 Android 中的 MainActivity)
├── package.json # NPM 配置(相当于 build.gradle)
├── metro.config.js # Metro 打包器配置(类似于 Gradle 配置文件)
├── babel.config.js # Babel 转译器配置文件
└── tsconfig.json # TypeScript 配置文件
切换到全屏 切换回正常模式
现在我们已经理解了Android和React Native之间的基本架构概念,并且了解了一个典型的项目结构,让我们在心里想一下React Native应用程序的核心组成部分。
UI: 组件、布局和样式组件的心理模型
在 Android 中,传统的 UI 构建块是 Views 和 ViewGroup,而 Jetpack Compose 中则使用 Composable 函数。在 React Native 中,一切都以组件形式存在。
传统的 Android 开发需要你手动操控 UI。React Native 则不同,你只需要描述界面应该是什么样子。
布局设计
React Native 使用 Flexbox 布局,这与 Android 传统上使用的 XML 布局系统有所不同。
- 布局容器:不用
LinearLayout
、RelativeLayout
或ConstraintLayout
,而是使用带有 flex 属性的 View 组件。 - 单位:没有 dp 或 sp,React Native 使用不受平台限制的单位,这些单位会根据设备设置自动缩放。
- 定位:使用
justifyContent
和alignItems
属性,而不是 Android 中的 gravity 属性。
样式
React Native 提供了一个类似于 CSS 的样式系统,这会让 Android 开发者感到既熟悉又陌生,因为它结合了网页 CSS 和原生移动开发的概念,因此。
вместо XML 风格的资源文件或类似的 Compose 的 modifier 系统,React Native 使用 JavaScript 对象来定义样式。你可以直接将这些样式内联应用到组件上,或者通过 StyleSheet API 应用这些样式。
import { View, Text, StyleSheet } from "react-native";
function StyleExample() {
return (
<View style={styles.容器}>
<Text
style={{
fontSize: 16,
color: "blue",
}}
>
内联样式示例
</Text>
</View>
);
}
const styles = StyleSheet.create({
容器: {
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 中的所有尺寸都是无单位的,表示密度无关的像素(dp)。
- 不需要像在 Android 中那样的单独样式文件和资源限定符
- 没有直接等同于 Android 主题系统的功能支持:主题通常通过 Context 来实现
类似于在架构上的不同,你的状态管理方法会根据你来自传统的 Android 还是 Jetpack Compose 而有所不同。
(点击图片查看架构差异)
核心组件 - Props、Hooks 以及 Context
Props :Props(属性的缩写)是从父组件传递给子组件的不可变的数据。由于它们是不可变的,这有助于让组件更易于复用。
在Android的世界里,这些组件类似于以下:
- 传递给 Fragment 的参数或数据
- 传递给 Activity 的 Intent 额外信息或参数
- 传递给构造器的参数
钩子:React 提供的钩子,让开发者在组件中来使用 React 的功能。
背景:上下文(Context)提供了一种方式,在组件树中传递数据,而无需在每一层手动传递属性。这使得数据可以在组件树中轻松传递。
核心理念
状态作为唯一真实来源
不要考虑如何更新UI,而是思考在给定状态下,UI应该是什么样子。UI是状态的反映,反之不成立。
组件作为纯函数
在相同的 props/state 下,组件应该总是一致地渲染。副作用,应通过 useEffect 分开处理。
不可变更新
我们不直接修改视图,而是创建一个新的状态来描述更新的内容。
组件的生命周期管理
在传统的Android系统中,你需要通过一组生命周期回调函数来管理活动在整个生命周期中的状态,而React Native则使用一个更简单的挂载和卸载生命周期模型,该模型通过组件级别的useEffect钩子来实现。下面是比较:
在传统的 Android 中,导航主要通过 Intent 系统和 Activity 栈进行管理,而在 Jetpack Compose 中,则主要使用 Navigation 组件。React Native 的导航与 Android 有以下几个不同点:
- 没有内置系统:与 Android 的核心 Intent 和 Activity 系统不同,React Native 没有内置的导航框架。相反,你需要选择一个第三方库,其中 React Navigation 是最流行的解决方案。
- 基于组件:导航是通过组件而不是系统意图来实现的。
- 基于堆栈的模型:类似于 Android 的后退堆栈,但用 JavaScript 实现的。导航路径和过渡都是用 JavaScript 定义的。
虽然Android和React Native之间的导航基本概念虽然相似,但实现方式却有所不同,可以这样理解如下:
// 类似于 Android 的 Intent
function HomeScreen({ navigation }) {
return (
<Button
title="前往详情"
onPress={() => {
// 代替 startActivity() 和 Intent
navigation.navigate('Details', {
itemId: 86,
title: '产品详情',
});
}}
/>
);
}
// 获取路由参数(类似于 Intent extras)
function DetailsScreen({ route }) {
const { itemId, title } = route.params;
return (
<View>
<Text>{title} 的详细信息</Text>
<Text>项目 ID: {itemId}</Text>
</View>
);
}
全屏 退出全屏
业务流程(即业务逻辑)当你从 Android 转换到 React Native 的时候,你会注意到 UI 和业务逻辑之间的关系发生了很大的变化。
做 Android 开发工作
- UI和业务逻辑代码通常被视为同等重要
- 架构模式如MVVM、MVP或MVC明确地将表现层与业务逻辑分离
- 后端代码(仓库、服务、管理器)通常与UI代码同样重要
- UI常常被简单地看作是“视图”,用于渲染数据
React Native 开发
- UI组件与业务逻辑更加紧密地结合在一起
- 组件同时执行展示和逻辑行为
- 架构更加倾向于“UI先行”,逻辑服务于UI展示
- Hooks将UI和逻辑的关注点在同一组件内融合
在 React Native 中,你可能会从 UI 开始,然后添加它所需的逻辑,而不是首先设计后端服务。这种从 UI 驱动的方法源于 React 的组件架构,其中组件是主要的构建块。随着项目的复杂性增加,你仍然可能会将纯粹的业务逻辑提取到自定义钩子、上下文或服务中,如上文示例项目结构所示。随着你在 React Native 的旅程中不断前行,你可能会逐渐形成自己平衡这些方面的方式。
虽然 React Native 改变了你构建 UI 和业务逻辑的方式,但后端服务(API 客户端、数据解析和状态同步)在概念上仍然与 Android 类似,不过,你的后端服务能够同时支持 Android 和 React Native 应用。在 React Native 中,你会遇到以下库:
- Fetch 或 axios 用于调用 API
- AsyncStorage 用于数据存储和持久化
- 原生模块 用于平台相关 API 和功能支持
关键的区别不在于你需要哪种后端服务,而在于这些服务如何与你的组件结构进行集成。通常你会创建自定义钩子来封装数据获取和状态管理的过程,然后可以直接在组件中调用这些钩子。
继续学习更多希望本指南能帮助你将 React Native 与一些熟悉的 Android 开发概念联系起来,但请记住,这种联想只是开始。虽然这些比较可以作为理解 React 与 Android 不同之处的一个起点,但它们不能代替更深入的学习和实践。为了继续你的 React Native 学习之路,这里有一些宝贵的资源:
- React Native 官方文档
- React Native 实用指南,在 Udemy 上可以找到
- Expo - 一个叫 React Native 的框架
希望在那边见到你😉
共同學(xué)習(xí),寫(xiě)下你的評(píng)論
評(píng)論加載中...
作者其他優(yōu)質(zhì)文章