这段学习随笔的核心是React Native，一个让我既爱又恨的跨端技术。我花了不少时间从零基础开始折腾，踩过无数坑，也收获了很多经验。这里分享的，是最适合入门同学的完整路线和实操记录，从环境搭建到核心概念，再到真实项目中的关键细节。如果你正准备接触跨端开发，或者对RN感兴趣但不知道从哪下手，这篇文章能帮你少走弯路。
1. 内容整体设计与思路拆解
1.1 为什么跨端技术里选了React Native
说实话，跨端方案这些年冒出来不少，各有各的拥趸。最开始我没直接选RN，而是先看了WebView套壳和PWA这类方案。套壳方案优势是成本极低，一套Web代码改改就能上架，短期内确实省事。但深入一想，这玩意儿性能和原生体验差着一截，复杂交互和流畅动画基本就是奢望。PWA在当时生态还不够完善，尤其是在国内浏览器环境下，推广阻力不小，所以没多久就放弃了。
接着认真对比了RN、Flutter和原生双端开发。原生双端开发最大的问题是成本：一套业务逻辑得写两遍，iOS一套，Android一套，还得维护两套技术栈的团队，对小团队来说负担极重。Flutter的渲染机制确实精妙，UI一致性好得惊人，但它用的是Dart语言，这让我有点犹豫。Dart的社区生态和人才储备远不如JavaScript。JavaScript毕竟是Web世界的通用语言，身边随便一个前端同事上手RN几乎不需要额外学语言。团队的现有技能储备、招聘成本、社区生态成熟度，这些综合考量下来，RN就成了首选。
RN绑定的React框架本身就是我一直在用的，前端开发那套组件化思维可以直接迁移。对于从Web转移动端的开发者来说，RN的学习曲线比原生平缓太多。
1.2 入门学习的整体路径规划
盲目的“啃文档”是大忌。我给自己定的路线分四步走：第一步，熟悉JavaScript和React基础，这一步我因为原本就会React所以过得很快，但我强烈建议没有React经验的朋友先花一两周把组件、状态、事件处理、副作用这些概念弄清楚，否则直接进入RN会一头雾水。第二步，搭环境跑通官方示例，理解RN项目的目录结构和基本运行流程。第三步，逐个拆解RN核心组件，掌握View、Text、ScrollView、FlatList这些高频组件，配合Flexbox布局写出常见页面。第四步，动手做一个小项目，把导航、网络请求、状态管理这些综合起来用一遍，只有真刀真枪做过项目，知识才算是自己的。
这条路径在入门后验证下来非常有效，牢牢抓住“复用已有前端经验”这个点，同时又明确RN不是Web，不能什么都用Web的思维写。
1.3 学习笔记的定位与目标人群
这篇随笔不是正式文档，也不是编程教程，它更接近我个人折腾过程中的一份现场记录和踩坑清单。适合的人群主要是三类：第一类是正在从Web前端转跨端开发的工程师，处处可以对照Web的写法来理解；第二类是初步了解React Native但还没系统做过项目的同学；第三类是已经在用RN但遇到一些卡点想看看别人怎么解决的人。无论你是哪一类，我都建议边读边动手，我做的几个Demo都是可以直接复制运行的，你把它改成自己的练习就行。
2. 核心概念拆解与实操要点
2.1 组件是构建一切的基石
RN里万物皆组件，你页面上看到的任何元素，归根到底都是组件。React开发里组件就两种，函数组件和Class组件。现在官方强烈推荐函数组件加Hooks，很多开源库也逐渐默认只支持函数组件了。但入门阶段，Class组件也得看得懂，因为老项目里太常见了。我学习时反复练习一个简单思路：组件接收外部传入的props，再配合内部自己的state，就构成了一个动态UI的最小单元。
举个例子，一个简单的欢迎页。你要显示一行文字“你好，RN”，再放一个按钮，点击后文字变成“欢迎来到跨端世界”。用函数组件的写法非常简短：
import React, { useState } from 'react'; import { View, Text, Button } from 'react-native'; const WelcomeScreen = () => { const [message, setMessage] = useState('你好，RN'); const handlePress = () => { setMessage('欢迎来到跨端世界'); }; return ( <View> <Text>{message}</Text> <Button title="点击我" onPress={handlePress} /> </View> ); }; export default WelcomeScreen;这里有个初学者容易犯的错误：直接修改state变量，比如message = 'xxx'，结果页面死活不更新。记住，React必须通过setMessage这样的设置函数来更新状态，UI才会重新渲染。这是React数据流动的核心逻辑，一定要刻在脑子里。
2.2 Flexbox布局是页面排版的灵魂
RN的布局模型用的是Flexbox，这跟传统CSS不太一样，但如果你熟悉Web的Flex布局，那几乎是零成本迁移。唯一要留意的是默认方向不同，Web里flex-direction默认是row，RN里默认是column，这个区别我一开始不知道，导致第一个练习页面的子元素全竖着排列，折腾半天才发现。
Flexbox的核心就三样东西：父容器的flexDirection决定主轴方向，justifyContent决定主轴方向上的子元素分布方式，alignItems决定交叉轴方向的对齐方式。配合这几个属性，复杂的页面布局基本都能搞定。
来看一个实际例子。一个典型的表单页，上面一个输入框，下面一个登录按钮。要求输入框占满整行，按钮固定在底部。实现方式是在外层容器用View充当容器的角色，内层再放一个输入框的容器。
<View style={{ flex: 1 }}> <View style={{ flex: 1, justifyContent: 'center', padding: 16 }}> <TextInput placeholder="请输入账号" style={styles.input} /> </View> <View style={{ padding: 16 }}> <Button title="登录" onPress={() => {}} /> </View> </View>flex: 1是RN布局中用得最多的一个值，意思是让这个容器尽可能地撑满剩余空间，上层是输入区域占主要高度，下层按钮区域则自然固定在底部。这里的思路和原生iOS用约束、Android用布局文件的思路不完全一样，但表达的都是“分区域、定比例”的效果，一旦理解了flex的伸缩含义，大部分页面排布都能做出来。
2.3 样式系统与Web CSS的差异
RN的样式系统和Web CSS很像，但有一定的简化与差异。首先，所有样式名都是驼峰命名法，比如background-color要写成backgroundColor，font-size写成fontSize。第一次写RN样式时我从Web直接复制过来，结果App直接报错，才知道这个细节。
其次，RN不支持CSS的层叠概念，样式不会被上一层继承。不像Web里给body设置font-size，所有后代元素自动继承。RN里如果你不显式给Text组件设置字号，它就会使用默认字号。我在做第一个列表页时，想在某个容器上统一设文字颜色，结果发现所有子文本“不听话”，这就是继承机制不同造成的。解决办法就是每个文本组件都显式设置样式，或者封装一个统一风格的文本组件。
块级概念也不同。Web里有display: block和行内元素之分，RN里所有组件默认都是块级，位置和尺寸由Flex布局控制。不过，在文本内部想要混合不同样式的片段，RN提供了Text组件的嵌套能力，一个Text里可以再包一个Text，内层样式只会影响内层文字，这有点像是把CSS的行内元素塞进了同一个文本流里面，心智上限制了想象空间就不会出错。
2.4 环境变量与项目配置
RN项目根目录下有几个配置文件。app.json是应用的基础配置，包含应用名和显示名；package.json是Node项目的依赖清单；index.js是入口文件，注册了根组件。这里有个容易被忽略的字段：app.json里面的name对应的是原生工程里应用的模块名称，一旦项目创建后想改它的值，需要同步改原生代码，很麻烦，所以项目命名时要想清楚。
如果是通过react-native init创建的项目，工程目录里还包括android/和ios/两个原生目录。你不一定需要懂原生开发，但必须知道它们的存在。有些问题，比如某些原生模块编译失败，归根到底要落到这两个目录里去处理。
3. 实操过程与核心环节实现
3.1 开发环境搭建实录
这篇随笔里环境搭建的篇幅最长，因为是我踩坑最多的地方。如果你只用Windows，避开一个“鬼门关”：Android SDK和模拟器的安装配置，处理不好会导致项目永远无法编译。我用的是老套路：安装Android Studio，通过它的SDK Manager安装所需的平台工具和模拟器镜像。
RN和原生Android开发的分工是：你用RN写界面和逻辑，最终打包成.apk文件的过程由Android构建体系完成。所以第一个卡点往往是Java环境变量没配好，或者SDK路径对不上。建议新手首先确认两个命令能正常执行：
java -version adb --version如果这两条命令任一失败，直接去配置环境变量，别急着建RN项目。这是所有后续工作的地基。
iOS端只能在macOS上开发，核心是Xcode和CocoaPods。安装过程不复杂，但需要注意版本匹配问题。RN每个版本对Xcode版本有最低要求，太老或太新的Xcode都可能出现编译错误。CocoaPods是iOS依赖管理工具，负责管理RN原生部分的依赖包，安装时可能会因为网络问题失败，多试几次，或者用国内镜像源。实话说，环境搭好后那种顺畅感是很爽的，但搭的过程真的能把人的耐心磨掉一半。
3.2 创建并运行第一个项目
环境就绪后，创建项目非常快。命令如下：
npx react-native init RNDemonpx会临时下载最新版本的RN脚手架，并执行初始化。执行完毕后进入项目目录。注意这时还不能直接点“运行”按钮，得先启动一个Metro服务。Metro是RN的打包工具，它把你的JavaScript代码实时编译打包，然后下发到模拟器或真机上。每次启动App前，默认都要先跑这个服务。
cd RNDemo npm start另开一个终端运行：
npm run android这里要叮嘱一句：开发阶段App用的是Metro提供的实时打包，如果你改了代码想看到页面刷新，得让App保持连接Metro。连接断了App会显示红屏错误界面，提示无法连接到开发服务器，这时重新启动Metro，再在App界面里摇一摇（模拟器快捷键Ctrl+M），选择Reload，基本就能恢复。
如果是真机调试，建议手机和电脑连同一个Wi-Fi，并通过adb reverse tcp:8081 tcp:8081把手机的8081端口转发到电脑上，否则真机识别不到Metro。我在这上面反复被折腾，后来形成习惯就是：每换一台设备调试，第一时间执行一遍adb reverse。
3.3 核心组件的参透笔记
官方文档里组件特别多，但实际项目中反复用到的就那么几个，逐个讲讲使用要点。
View是最基础的容器组件，相当于Web里的div，负责布局和样式。几乎每个页面最外层都是一个View。Text用来展示文本，注意嵌套规则：Text里面直接放字符串没问题，但如果想逐字设置不同颜色或字号，要么用多个Text嵌套，要么用数组分开渲染。TextInput是文本输入框，这是表单类页面的主角，它的常见属性包括placeholder（占位文字）、value和onChangeText（值变化回调）。有一点很反直觉：它不像Web输入框一样自带边框，默认是透明背景，你得自己给TextInput加样式才能看到输入框轮廓。
ScrollView是滚动容器。如果一个页面内容超过一屏，必须用ScrollView包裹才能滑动。但ScrollView存在性能问题，它会把所有子元素一次性全部渲染。做长列表时，官方建议用FlatList替代，FlatList只渲染可见区域附近的数据，滑动时才动态加载其他项，这对性能和内存使用是质的提升。
FlatList的用法和Web里的虚拟列表类似，核心属性就是data数组和renderItem函数。示例代码如下：
<FlatList data={data} keyExtractor={(item) => item.id} renderItem={({ item }) => <Text>{item.title}</Text>} />keyExtractor非常重要，它告诉React哪一项是唯一标识，是列表高效更新的关键，缺少它默认会用索引值当key，遇到列表变化时极容易产生UI渲染错乱，不要省。
3.4 路由与页面导航
“跨页面”是移动端应用绕不开的需求。一是Tab底部导航，用户需要切换不同模块；二是Stack堆栈导航，跳转到详情页后返回上一页。RN官方推荐的是react-navigation，而不是RN内置的Navigator组件（这个已经废弃了）。
安装方式很简单：
npm install @react-navigation/native npm install @react-navigation/native-stack npm install react-native-screens react-native-safe-area-context配置思路是：创建导航容器里面放页面栈，每个页面作为一个Screen。更多具体代码不细写了，官方文档的指南写得很清楚。我只提醒几个容易踩的坑：第一，别忘了安装screens和safe-area-context这两个依赖库，否则运行时会直接报错；第二，iOS设备顶部状态栏和底部Home指示器会影响页面布局，要在设计页面时留出安全区域，否则内容会被刘海遮挡；第三，导航传递参数给详情页时，注意参数类型是基础类型和可序列化对象，不要传函数或特殊对象，否则会造成内存异常。
3.5 网络请求与数据渲染
移动应用不联网基本没法用，数据交互大多走HTTP接口。RN提供了内置的fetch，也可以安装axios，两者核心用法差别不大。我更习惯用fetch写个简单的封装，因为不引入第三方依赖，代码直白。
一个常见的列表页请求逻辑是这样的：进入页面后请求接口拿到列表数据，然后更新到组件的state里，再交给FlatList渲染。这里有一个初学者特别容易犯的错误：在组件里发请求后直接setState，结果组件都卸载了才返回数据，导致警告“在已卸载的组件上调用setState”。解决方案是在useEffect的清理函数里取消请求，或者用一个isActive标记位来防止更新。
useEffect(() => { let isActive = true; fetch('https://api.example.com/list') .then((res) => res.json()) .then((data) => { if (isActive) setList(data); }) .catch((err) => console.log(err)); return () => { isActive = false; }; }, []);这种细节如果不在真实项目中踩坑，很难意识到。现在很多团队也会用React Query这类请求库，把缓存、状态同步这些事封装好，但入门阶段还是建议从最原始的fetch一步步理解链路。
3.6 状态管理的取舍
React的状态管理方案非常多：Context、Redux、Zustand、MobX等等。入门阶段我不建议一上来就引入Redux，因为样板代码太多，概念多，容易劝退。个人建议是先用Context把全局状态管起来。Context是React官方提供的状态共享方案，适合中大型应用里但频率不高的全局数据，比如用户登录信息和主题配置。
但项目一复杂，Context的更新会导致所有依赖它的组件全部重新渲染，即使某个组件只关心其中一小段数据，依然无法精确控制。这时候再用Zustand这类轻量级状态库会舒服很多。它的API极简，只要记住create函数和useStore挂钩子，完成全局状态管理。我入门阶段体验过这三种方案后，最终的总结是：刚开始练手别管状态管理，把数据放在组件内state里，多写几个页面后再回来体会状态管理不迟，否则容易陷入库选型的泥潭而忽略了核心内容。
4. 常见问题与排查技巧实录
4.1 红屏错误与排查三板斧
RN里“红屏”就像Web里的控制台报错一样，属于开发阶段可见的严重错误提示。千万不要怕红屏，有时候反而是帮大忙的，因为错误信息写得比较明确。处理红屏我有三个固定动作，屡试不爽。
首先看错误信息最顶部，“Invariant Violation”或者相对明确的英文提示，用翻译工具翻译完基本能定位问题方向。其次，看Stack Trace里有没有自己的业务代码，你写的代码通常在某一两层，下面的框架栈不是重点。最后，尝试清理缓存重启：
npm start -- --reset-cache cd android && ./gradlew clean如果上面三招都不行，那就把错误关键搜关键词复制去搜索引擎找对应问题，基本都能找到答案。不用记一整屏错误，关键是识别出错误类型和涉及哪个模块。
4.2 网络请求失败最全症状对照表
网络请求是学习RN时最具迷惑性的部分，通常不是因为代码逻辑错，而是环境问题。下面是我总结的常见现象和解决办法：
| 症状 | 可能原因 | 排查顺序 |
|---|---|---|
| 接口返回超时 | 手机访问不了电脑的局域网 | 确认同一Wi-Fi，试adb reverse |
| 请求返回403或跨域错误 | 后端接口未设置允许跨域 | 连原生App没有同源策略限制，基本的CORS也应支持，找到服务端配置 |
| 请求能发出去但收不到数据 | 接口地址配的是localhost | 真机上不能配localhost，要用电脑的局域网IP |
| 提示SSL错误 | HTTPS证书不信任 | 本地开发可安装自签名证书，或临时关闭SSL验证 |
这里面最典型的是把接口地址写成localhost，模拟器还能通，真机就完全不通。真机访问电脑必须使用电脑的局域网IP，比如http://192.168.1.5:3000/api/list，模拟器上用http://10.0.2.2:3000这个特殊地址访问电脑的localhost。
4.3 Metro bundler卡死与缓存清除方案
Metro在开发时非常吃资源，出现“卡死”、“越跑越慢”的现象不要惊讶，因为它是全量打包的。一般我对付卡死的方法是：关掉Metro进程，然后执行npm start -- --reset-cache重新开启。
有时候改Android原生代码不会热更新，得先重新构建原生层，然后再打开Metro。换句话说，Metro只处理JS层的代码变化，如果动了android/目录里的原生配置，就必须重新npm run android，这一步在开发后期遇到“改了什么没反应”的问题时要优先想到。
4.4 Android构建失败与依赖冲突
构建失败通常报一种错误：“SDK Build Tools版本找不到”或“NDK版本不匹配”。这个问题根源于RN、Android Gradle插件、Android Studio三方之间的版本配合关系。解决思路是先看项目里android/build.gradle文件配置的版本号，确认与本地Android Studio中自动安装的版本一致。如果不一致，要么改配置文件降级，要么在Android Studio里补装缺失的SDK版本。
依赖冲突则多发生在react-native及原生第三方库之间。它们内部依赖的原生代码经常版本不统一，Gradle在构建时会报“Duplicate class”错误。处理方案一般有两种，一是升级所有库到兼容版本，二是在android/app/build.gradle里增加packagingOptions排除冲突。这些内容对纯前端转过来的人确实不友好，但别怕，很多问题搜索引擎里都有成熟答案。
4.5 真机调试的常见坑位
真机调试比模拟器更容易出问题。一是Wi-Fi环境限制，真机必须和电脑同一局域网，这个前提不满足，Metro连接就会失败。二是公司网络或公用网络可能禁用了端口，比如8081被防火墙拦截，这时需要换端口启动Metro：npm start -- --port 8082。三是某些国产手机系统默认禁止后台adb权限，导致adb reverse不生效，需要在开发者选项里打开“USB调试（安全设置）”之类的开关。
给我的个人建议是：如果真机调试问题反复不定，先回模拟器调试，别在环境问题上浪费时间。环境不顺非常影响心情，练手阶段优先保证学习节奏。
5. 真实项目实战复盘：一个综合Demo的完整过程
5.1 项目需求描述与拆分
入门学习光看不练等于没学，我给自己定了一个练手项目：做一个待办事项清单应用，要求有成套流程：启动页、待办事项列表、添加新待办、删除待办、标记完成。数据不用接口，先存在本地。
拆解下来，需要用到的基础能力包括：两个页面（列表页和添加页）间的导航、文本输入和按钮交互、列表渲染、状态管理、本地存储。这个项目麻雀虽小，五脏俱全，能把你学到的RN核心模块全部串联起来。
5.2 目录结构与代码组织
项目虽然小，但目录不能乱。我按照团队项目的样子来组织，能提前熟悉真实项目规范：
src/ components/ # 可复用组件 screens/ # 页面级组件 utils/ # 工具函数 storage/ # 本地存储封装多敲几次目录名之后，你会逐渐形成“组件放组件、页面放页面、逻辑归逻辑”的全局意识。很多初学者把几百行代码全塞一个文件，到后面维护极其痛苦，项目越写越大就越难回头重构。
5.3 导航和页面跳转的现场记录
react-navigation配置好后，使用起来很方便。我在列表页上的操作逻辑是：点击右上角“添加”按钮，跳转到添加页；添加页填写完内容后，点击“保存”，再返回列表页，并把新数据传递过去。
这里学到的一个重要概念是页面间通信。在RN的世界里，页面跳转就是“参数传递+回传机制”。返回时携带数据的写法大致如下：
navigation.navigate('AddTodo'); // 添加页保存时 navigation.goBack();实际项目中更好的方式是利用状态管理库（如Zustand）来做数据共享，添加页写入状态后列表页自动刷新，这里先用参数传递练习基础。关于navigation这个特殊的prop，它是每个页面组件自动注入的，里面包含navigate、goBack、setParams等方法。如果页面是嵌套在Tab导航下，还得用navigation.navigate的时候注意层级关系，具体实践时多看官方文档。
5.4 本地持久化存储选型与实现
待办数据不能每次重启App就丢，这就用到了AsyncStorage这个库。它的用法类似Web的localStorage，异步读写键值对。
import AsyncStorage from '@react-native-async-storage/async-storage'; // 存储 await AsyncStorage.setItem('todos', JSON.stringify(todos)); // 读取 const data = await AsyncStorage.getItem('todos'); const todos = data ? JSON.parse(data) : [];关键点在于AsyncStorage只能存字符串，对象数据必须序列化成JSON后存。读取时再反序列化。这个过程逻辑简单，但要在App启动时载入一次数据，并且每次新增、删除后同步存储，避免数据丢失。
5.5 项目运行效果与经验总结
待办清单小应用最终效果虽然简陋，但完整跑通了“写页面、跳页面、存数据、刷新UI”的闭环。这种从零到一的感觉，比单纯看教程所获大得多。回想这一阶段，最大的收获是理解了“RN的JavaScript层和原生层的桥沟通模式”。JS代码运行在JavaScriptCore或Hermes引擎里，原生UI组件运行在原生渲染引擎里，两者通过Bridge通信。当你调用高德地图原生模块或相机功能时，实际上是在做一次跨桥调用，而跨桥通信是有性能开销的，所以RN官方现在也在推广更快的Fabric渲染架构，但入门阶段不必深究。
6. 学习过程中一些独到的经验与思考
6.1 “复用思维”与“打破复用思维”
从Web转到RN，最大的思维红利是组件化复用思维。你会不由自主地把页面拆成一个个小组件，每个组件只做一件事，组合出完整的页面。这在原生开发里也不是新鲜事，但React的表达方式确实更接近于状态驱动UI。
但另一方面，RN终究不是Web。不能用Web的绝对定位和盒模型来对待RN的一切。比如zIndex在Web里用得飞起，RN虽然支持，但层级关系有时更依赖于元素的渲染顺序和position属性。再比如，CSS的hover伪类在移动端不存在，你需要用Pressable组件的状态回调来模拟按压效果。要把自己切换到一个“新平台”的心智模式里，而不是把RN当Web的翻译器。
6.2 学习资源的选择标准
市面上的RN教程参差不齐，有几类资源值得优先看。官方文档永远是最权威的，虽然有的地方写得隐晦，但它的更新节奏和社区同步度最高。其次，GitHub上的一些热门开源项目，直接读源码，这比看任何二手教程都有效。再次，别只跟着视频敲代码，视频能帮你看懂流程，但容易让你陷入“眼睛会了手没会”的假学习。真正有效的学习模式是：看一段文档，立刻模仿写一个Demo，然后故意破坏它再修复它，这种破坏式练习会让你把知识的边界摸透。
6.3 建立自己的踩坑库
过程中一定要记录自己的问题。我有个惯例，每解决一个卡点就整理成一段“原因-现象-解法”的速记。这些速记积累多了，就成了个人的“避坑百科全书”。举个例子，我在做一个搜索功能接口时，发现请求一直返回500，排查半天才发现是后端接口的参数名改了，而前端还在用旧参数。类似的荒谬错误很多，记录下来就会提醒自己检查参数名和接口契约。
记录还有一个价值：未来带新人或者自己回看时，可以很快定位问题，不会像第一次碰到那样手足无措。这也是我写这篇随笔的初衷。
6.4 性能优化的初步意识
入门阶段可以不追求极致性能，但性能意识要早早建立。比如，能使用FlatList就不要用ScrollView渲染长列表；能使用memo包裹子组件就尽早习惯；网络请求要有防抖和取消机制；图片要设置宽高或使用占位符。这些意识在项目小的时候看不出差异，一旦数据量和交互复杂度上去了，再回头优化就是一场灾难。早早就按性能友好的方式写，能避免很多后续的痛。
6.5 部署与打包的注意事项
学完开发后有一个绕不开的重要环节：发布。RN应用打包分Android和iOS两个渠道。Android打包apk可以用cd android && ./gradlew assembleRelease，但JG签名文件（又叫keystore）是必须提前配置的。签名相当于应用的身份证，一旦确定，后续所有更新必须用同一签名，否则应用无法覆盖安装。iOS打包则要经过Xcode的Archive流程，配置Bundle ID、证书和描述文件。这个过程如果不实际跑一遍，永远不知道“签名”“描述文件”这些词在工程里意味着什么。
7. 最后的个人心得碎片
React Native这门技术，给我的最大感受是“把生态优势变成了开发效率”。它融合了前端的开发速度和原生的交互体验，对于团队来说是一笔很划算的账。但对个人学习而言，最挑战的不是语法和组件，而是“跨界”——你在Web世界建立的经验，在这里有效但又不完全有效，你必须同时掌握一套原生思维，才能在遇到底层问题时游刃有余。
如果你现在正准备入门，我给三条朴素建议：第一，选择一个简单的项目动手做，不要停留在看教程阶段；第二，环境问题多花点时间耐心解决，它决定了你的体验；第三，不懂的地方先记下来，过段时间再看，很多当时想不通的问题，后续自然而然就通了。
这个领域还在快速演进，新架构、新工具层出不穷。我打算后续再慢慢把动画和性能优化的内容整理出来，现在先把这些基础内容用文字沉淀一下。学习路上跟我一样的同路人，祝你们少踩一点坑，多写一点好代码。
