react native 开源了吗

2023-03-05 06:46:01html-css017

react native 开源了吗,第1张

React native充分利用了Facebook的现有轮子，是一个很优秀的集成作品，并且我相信这个团队对前端的了解很深刻，否则不可能让Native code「退居二线」。

对应到前端开发，整个系统结构是这样：

JSX vs HTML

CSS-layout vs css

ECMAScript 6 vs ECMAScript 5

React native View vs DOM

无需编译，我在第一次编译了ipa装好以后，就再也没更新过app，只要更新云端的js代码，reload一下，整个界面就全变了。

多数布局代码都是JSX，所有Native组件都是标签化的，这对于前端程序员来说，降低了不少学习成本，也大大减少了代码量。不信你可以看看JSX编译后的代码。

复用React系统，也减少了一定学习和开发成本，更重要的是利用了React里面的分层和diff机制。js层传给Native层的是一个diff后的json，然后由Native将这个数据映射成真正的布局视图。

css-layout也是点睛之笔，前端可以继续用熟悉的类css方式来编写布局，通过这个工具转换成constrain布局。

系统只有js-objc的单向调用，就是把原生UI组件的方法通过javascritcore或者webview（低版本iOS）映射到js中来，整个调用过程是异步的，这样的设计令React native可以让js运行在桌面chrome中，通过websocket连接Native code和桌面chrome，极大地方便了调试。对其中的机制Bang的一篇文章写得很详细，我就不拾人牙慧了：React Native通信机制详解 « bang’s blog 。但这样设计也会带来一些问题，后面说。

点按操作也被抽象成了一组组件（TouchableXXX），这种抽象方式是我在之前做类似工作中没有想到的。facebook还列出Native为什么和web「手感」不同的原因：实时的点按反馈和取消能力。React Native 这套相应机制设计得很完善，能像Native code那样控制整个点按操作的所有过程。

Debug相当方便！修改了js以后，通过内建的nodejs watcher编译成bundle，在模拟器里面按cmd+r就可以看到效果。而且按cmd+d，可以打开一个chrome窗口，所有的js都移到了chrome里面运行，所以什么断点单步打调用栈，都不在话下。

上面的既是特点也是优点，下面说说缺点，或者应该说：「仍然遗留的问题」，在我看来，这个方案已经超越了Hybird方案。

系统仍然（不得不）依赖原生组件暴露出来的组件和方法。举两个例子，ScrollView这个组件，在Native层是有大量事件的，scrollViewWillBeginDragging， scrollViewWillEndDragging，scrollViewDidEndDragging等等，这些事件在现有的版本都没有暴露，基本上做不了组件联动效果。另外，这个版本中有大量组件是iOS only的：ActivityIndicatorIOS、DatePickerIOS、NavigatorIOS、PickerIOS、SliderIOS、SwitchIOS、TabBarIOS、AlertIOS、AppStateIOS、LinkingIOS、PushNotificationIOS、StatusBarIOS、VibrationIOS，反过来看，剩余的都是一些抽象程度极强的基本组件。这样，用户必须在不同的平台下写两套代码，而且所有能力仍然强烈依赖 React native 开发人员暴露的接口。

由于最外层是React，初次学习成本高，不像往常的Hybird方案，只要多学几个JS API就可以开始干活了。当然，React的确让后续开发变得简单了一些，这么一套外来的（基于iOS）、残缺不全的（css-layout）在React的包装下，的确显得不那么面目可憎了。

另外，React Native仍然很不完善。文档还不全，我基本上是看着他的示例代码完成的demo，集成到已有app的文档也是今天才出来。按照官方的说法，Android版本要到半年后才发布：Blog | React ，届时整个系统设计可能还会有很大的变化。

PS，在使用Tabbar的时候，我惊喜的发现他们居然用了iconfont方案，我现在手头的项目中也有同样的实现，不过API怎么设计一直很头疼。结果，我发现他是这么写的：

<TabBarItemIOS

name="blueTab"

icon={_ix_DEPRECATED('favorites')}

....>

在 _ix_DEPRECATED 的定义处，有一句注释： // TODO(nicklockwood): How can this fit our require system?

以上。

下面是一周前，在React native还没开源的时候，通过反解ipa的一些分析过程，有兴趣的可以看看。

------------------------简单粗暴的分割线--------------------

背景和调研手段

React Native还没开源，最近和组里兄弟「反编译」了Facebook Group（这个应用是用React Native实现的）的ipa代码，出来几百个JS文件，格式化一下，花了几天时间读了一下源码，对React Native的内部核心机制算是有了一个基本了解。

React Native的核心实现：

先简单说几点，详细的等回头更新。

1. React Native里面没有webview，这货不是Hybrid app，里面执行JS是用的

JavascriptCore。

2. 再说React Native的核心，iOS Native code提供了十来个最基本核心的类（RCTDeviceEventEmitter、RCTRenderingPerf等）、或组件（RCTView、RCTTextField、RCTTextView、RCTModalFullscreenView等），然后由React Native的JS部分，组成二十来个基本组件（Popover、Listview等），交由上层的业务方来使用（THGroupView）。

3. 就如他们在宣传时所说，他们实现了一套类似css的子集，用来解决样式问题，相当复杂和强大，靠这个才能将Native的核心组件组成JS层的基本组件再组成业务端的业务组件，应该是采用facebook/css-layout · GitHub的C语言版本实现的（在ppt中我们看到了类似flex-direction: column一类的代码，这个正是css-layout支持的语法）。

4. 在React Native中，写JS的工程师解决的是「将基本组件拼装成可用的React组件」的问题，写Native Code的工程师解决的是「提供核心组件，提供足够的扩展性、灵活性和性能」的问题。

React Native的设计考虑：

ReactJS对React Native有着直接的影响（我没在生产环境中用过React，只看过代码&用过Angular，如果有误请指出）

ReactJS里面有这样的设计：

1. ReactJS 的大工厂入口createElement返回的不是某个实体DOM对象，而只是一个数组

2. 通过源码中 ui/browser/ 目录中的代码，将这个数组转换成DOM

3. 底层的渲染核心是可以更换的

另外，Facebook自己有JSX，css-layout等开源项目，基于这些，如果要做一个用 JS来开发Native app的东西，很自然就想到了一套最有效率的搞法：

1. 将 ui/browser 里面的代码替换成一套 Native 的桥接JS（实际上，iOS版是通过

injectGenericComponentClass方法，将核心组件的方法注入到JS里面），就直接复用React的MVVM，自动将数据映射到Native了

2. Native code里面实现三组核心API，一组提供核心组件的API（create、update、delete），一组事件方法（ReactJS里面的EventEmitter ），一组对css进行解析（css-layout）以及返回Style的ComputedStyle（React Native里面叫meatureStyle）。

这样，用上了ReactJS本身的所有核心功能和设计思路，Native的开发也足够简单。

那，React Native是什么看

其实这东西从Native开发来说，相当于重新发明了一个浏览器渲染引擎并且套一个React的壳，从Web开发角度来说，就是把原来React的后端换成了Native code来实现，就跟Flipboard最近搞的React Canvas 一样： Flipboard · GitHubreact-canvas

React Native的优势和劣势：：

优势相对Hybird app或者Webapp：

1. 不用Webview，彻底摆脱了Webview让人不爽的交互和性能问题

2. 有较强的扩展性，这是因为Native端提供的是基本控件，JS可以自由组合使用

3. 可以直接使用Native原生的「牛逼」动画（在FB Group这个app里面，面板滑出带一点果冻弹动，面板基于某个点展开这种动画随处可见，这种动画用Native code来做小菜一碟，但是用Web来做就难上加难）。

优势相对于Native app：

1. 可以通过更新远端JS，直接更新app，不过这快成为各家大型Native app的标配了…

劣势：

1. 扩展性仍然远远不如web，也远远不如直接写Native code（这个不用废话解释了吧）

2. 从Native到Web，要做很多概念转换，势必造成双方都要妥协。比如web要用一套CSS的阉割版，Native通过css-layout拿到最终样式再转换成native原生的表达方式（比如iOS的Constraint\origin\Center等属性），再比如动画。另外，若Android和iOS都要做相同的封装，概念转换就更复杂了。

更新1：添加了React对React Native的影响。

更新2：基本确定其使用了 css-layout，添加了对React Native的总结

更新3: React native已经开源了： React Native，只有iOS版。我写了几个demo，简单看了看objc代码并和开源前的我们的一些结论（见后文）交叉验证。简单地从前端工程师和系统整体角度说一下React native的特点和优劣吧。

更新4: 补充了几条优势和与前端开发的对照

1.更快、更流畅、更灵敏

首先，新版系统使用了新的处理架构，对多核心处理器的支持终于来到，Android设备中出现的双核、四核处理器将会得到更好的优化，发挥出强劲的性能表现。(PS：以前喷安卓没为多核处理器优化的将失去喷点，多核用户表示欢呼雀跃)

其次，在新版系统中，特效动画的帧速提高至60fps，4.1版系统还将会优化最佳性能和很低的触摸延迟，提供一个流畅、直观的用户界面。(PS：以前喷安卓界面不流畅的也将失去喷点了)

为了确保帧速一致，4.1版本的Android框架所有的绘图和动画都将统一VSYNC计时，应用渲染、触摸事件、画面构图、显示刷新等操作都会锁定在16毫秒响应，所有的帧都没有提前或者落后。

Android 4.1还增加了三倍缓冲，让所的渲染感觉更顺畅。触摸延时不仅会遵循VSYNC计时，还会在触摸操作时做出预判提前渲染，此外在CPU闲置时会分配更多的处理能力来应对触摸事件，以确保触摸没有延迟。

2.增强通知栏

在Android 4.1中，通知栏框架有了翻天覆地的变化，总体来说就是更大、更丰富、直接操作。

开发者可以在新版系统中使用三种不同的通知样式，最高可以达到256dp，用户可以直接查看图片、信息、邮件、提醒等内容，可以进行一键回拨、一键分享、一键回复等操作。(PS：又改版了，苹果快来抄吧)

。。。

更高分辨率的联系人照片(比如720X720）。(PS：这回联系人大头像也有了吧)

。。。

Android 4.1还引入了基于DNS的网络服务发现功能，可以通过WiFi网络寻找包括引动设备、打印机、相机、播放器等服务，开发人员可以通过这项新功能实现跨平台多人联机游戏等功能，也可以让手机连接到摄像头、打印机或者是其他移动设备的对等连接。

其中对等连接也是WiFi直接服务发现功能(P2P)，可以让手机开启自己的无线网卡，不需要移动网络、WiFi网络就可以直接找到其他移动WiFi设备，然后接通进行数据传输、共享资源。使用WiFi直接服务发现可以分享文件、联机游戏等。(PS：快牙表示压力很大。用过快牙的应该知道这个功能有多么强大实用，并且这个升级貌似比快牙功能还多还猛，可以预见由此引发的相关应用将不可限量)

新版中将会加入网络带宽管理功能，以更好的配合流量统计，节省自己的流量。

。。。

9.新的媒体功能

在果冻豆中，系统提供了更方便的硬件、软件解码器访问，支持USB音频输出，音频记录触发，多声道音视频输出(HDMI端口)，AAC 5.1音频编解码支持，音频预处理将可以提供更高的音质，媒体管理器将可以让用户选择使用什么方式进行媒体输出。。(PS：以前喷安卓音质不好的又将失去一个重要喷点，手机音乐党表示欢呼雀跃)

10.浏览器增强

在4.1中，Android浏览器和WebViews将提供更好的HTML5视频支持，滚动和缩放性能得到加强，并减少了内存占用，HTML5/CSS3/Canvas动画性能、文本输入、JavaScript引擎(V8)性能都得到了加强。。(PS：苹果引以为傲的HTML5优势也没了吧)

。。。

还有即将推出的Google游戏服务。

此外还有更强的renderscript计算、相机程序等。

[转帖] Android 4.1音频大跃进

通过对Google Nexus 7平板搭载的Android 4.1 Jelly Bean系统进行研究，我们发现安卓系统终于在音频延迟上做出了非常大的改进，而且这是软件上的改进，并非针对Nexus 7平板的，因为

Android 4.0 ICS系统手机Galaxy Nexus的延迟在100ms以上，因为其音频系统实在是太糟糕，而在升级到Android 4.1 JB系统之后，延迟大幅下降到了10ms以下。

虽然该成绩还有提升的空间，但至少可以肯定的是，那些iOS上的出色应用有机会移植到Android上了。

实际上Android 4.1在音频方面的改进很多，包括：

－提供了新的软件调音台和音频相关API的改进

－开始支持USB音频设备