react native 适配安卓有难度么?

为什么react native 目前只适配ios
关注者
229
被浏览
35183

5 个回答

之前的回答旧了,rn已经更新了不少版本。目前rn-android逐渐完善。现在已经可以考虑用rn来架构复杂的应用。

-----------------------

组里开发android的小朋友, 使用RN也有一段时间了,有一天忽然和我说:“我觉得React IOS是亲儿子, React Android是捡来的”

当然看得出React IOS更加成熟,开发工具更好用。

React Android确实有很多意想不到的坑, 适配虽然不会比IE7的适配更难, 但问题在于RN Android的hack技术, 还是un documented。 这给RN的适配带来了很大难度, 我们组遇到的很多问题,一开始都抱头痛哭。

我不是来黑RN的, 我是RN的支持者。 总体来说VIEW层80%兼容吧。 虽然还是有很多问题,在Android机器上,比如说TouchableX里面直接放Text, 有时候会触发Bug。 再比如说TouchableX可能会需要较多操作的setState产生线程冲突造成死锁……万恶的touchableX外, 还有RN android的线程处理,有一定的问题。 虽然官方承诺正在修复。

我还是觉得IOS,android工程师一起开发体验感觉很好,毕竟牛X的工程师,合起来用,就更牛X。 创造力当然是在叠加……

卡顿的地方,都有相应的黑技巧。 有时候是requestAnimationFrame, 有时候是更换下布局。 有时候是缓存VIEW。 真的非常追求体验的工程师, android上要下功夫了。 但所有的问题, 都是"solve once, use anywhere” ……历经辛苦,我们已经顺利的在200元左右的安卓机器上跑了非常流畅的RN应用,当然我们还没有来得及将所有的经验公布出来。


今天早起了,说说原理吧。 Android如果卡顿了, UI的FPS仍然有60左右, 往往是js渲染线程被无限制拖低了? 可是, 哪有那么多JS要跑? 何况是virtual DOM + reconciliation技术的RN ? 所以肯定是死锁。 在 js的main线程setState, 改变了virtual DOM 准备往真的RN android上同步时候, React Native Bridge的调度算法出了问题(一定是deal lock, 没有其它可能,因为IOS不卡)。 所以优化技巧往往是让JS的代码在时序上下功夫, 比如在setState时候注意加requestAnimationFrame。

当然还有一个更彻底的解法, 就是弄清楚RN的源代码然后去提PR。 其实从virtual DOM和android同步渲染的reconciliation算法,我觉得是这块需要优化~~


总的来说,瑕不掩瑜。 虽然github上android的PR已经堆积如山, 虽然react android不是fb亲生的儿子, 但在注入了community的灵魂后, 我还是非常看好 React Android。至少对于读过RN android代码的我, 比起某国产开源轮子的源代码, 我更加愿意去使用 React Android。 而且我发现, RN正在给Android开发带来更先进的理念。至少可以畅想, 至少自由 ,至少我们可以想想如何用cycle.js去实现整个APP的架构。 或者使用actor,curry~~ 去让APP更加富有活力。
谢邀。
(组里同学在和fb的同学跟进Android版本,占个坑后续同步信息。)

Android版本预计2015.10发布。Community Round-up #26

得到这个消息时还是有点失望的,组里几个Android同学也讨(y)论(y)过题主的问题,按照rn(react native)技术领域细分:
(知乎图片压缩得太厉害,见原图)

1. 布局及样式,与其说适配的难度,不如说改变的程度。相对ios,android的布局方式还是比较丰富的,android开发同学也更多使用xml管理layout、theme、style... 切换为rn的css-layout后第一感觉就是:有点弱,有点怪。布局会复用css-layout(facebook/css-layout · GitHub),整体难度上个人觉得不大。
2. 通信机制,rn ios是通过jscore与objc的bridge进行通信(React Native通信机制详解 « bang’s blog),android应该也会调用jscore,细节还需要再看下,无法直接评估难度。
3. UI渲染,这层通过android实现纯native ui,难度感觉还好,像rn发布稿提到的image decoding和text rendering等异步化也没问题。
4. 性能,会比webview更好,尤其中低端机,这点也是大家比较期待的。
5. 稳定性,待补充。
6. 扩展性,待补充。
7. 编程语言,自然还是React,最大程度复用,按照设计思路“learn once, write anywhere”会有android only api。

相关问题: