用 React Native 写 APP 后的一些感想和大家交流，或许有一些更好的解决方法也说不定
zipspeed · 2016-06-24 14:26:40 +08:00 · 9722 次点击这是一个创建于 3109 天前的主题，其中的信息可能已经有所发展或是发生改变。
摘录相关部分如下：
2. 开发工具
我用 Facebook 的 React Native 开发的安卓和 iOS 的版本。 1%估计还是要放掉，这个确实没办法。
但是，至少是在我写这篇文章的 2016 年 6 月，不，我不推荐你这么干。
因为我在 React Native 上时间花的最多的是三件事。
对于 Android ，我一开始是想搞纯 Material Design 的，这就需要有 immersive statusbar 。但是某些聪明的国内手机厂商在自己的 ROM 实现了非标准的黑色状态栏字体，然后这个智能判断状态栏字体的判据也比较呵呵。原生的话比较好解决…… React Native 的话我调整了一段时间后无果，那么直接就把代码删掉。不管状态栏了。
对于 iOS ， React Native 提供两个 Navigator 。一个是原生的，一个是与安卓通用的……照理说为了减轻代码量优化程序结构，咱们应该用通用的版本。
——但是坑爹的点在于，通用的版本里面，需要自己写工具栏。保持和原生风格一致的问题不说，坑点在于 iOS 的毛玻璃效果，是通通没有的……那么我下面 TabBar 有上没 NaivigatorBar 没有怎么破。
没办法，重写一遍程序，换回 iOS 专用版本，问题解决。然后又有一个坑……因为 ScrollView 滚上去的内容，是要现实在 NavigatorBar 的后面，然后 Facebook 写了一点神奇的东西，自动判断这种情况然后在 View 里面加点东西让第一行和 NavigatorBar 的下界对齐。为了把事情简化一下，我就说这种自动判断在某种情况是不 work 的，然后我又为此重新写了三个双平台通用的模块。
对于 Android 和 iOS 来说， Flux 的优劣见仁见智。我只能说对于业务逻辑复杂的 app 可能会变成一团 mess ，但我自己的因为需求简单所以还比较好。但是另外一个坑是刚上线的时候发现的，因为业务需要所以实现了一个 IM ，用了这个库 https://github.com/FaridSafi/react-native-gifted-messenger 。然后在做最后的测试的时候，发现输入中文的时候，特定长度以内气泡会越过屏幕边界……英文完全没有问题。
并不知道这算是控件的锅还是 React Native 的锅，但我决定不在这上面浪费时间，直接把气泡宽度写死。丑是丑了点，总归聊天内容都能看到吧。
相对来说，实现业务逻辑确实是小事，所以 RN 的愿景 learn once, write everywhere 也算是部分的实现了？不过，我觉得在目前的情况下，只有两种情况比较适合用 React Native ：
一、 C 轮以后或者是大公司（像 Facebook 自己），然后大老板拍板，五人以上团队，愿意钻到 framework 里修 bug 加 feature ，愿意自己自力更生包装 native 控件，然后也有做原生应用的团队一边协作（但这样优势在哪？）。
二、你像我一样，没有 KPI ，愿意花点时间研究 hack （当然前提是得 hack 出来），也愿意在应用里有些 compromise （英语应用，面向海外的应用，坑会少不少），然后拿出来做 lean startup 快速迭代试错的。
总之建议是想跳坑的可以再观望下。
全文链接： https://zhuanlan.zhihu.com/p/21411171
2. 开发工具
我用 Facebook 的 React Native 开发的安卓和 iOS 的版本。 1%估计还是要放掉，这个确实没办法。
但是，至少是在我写这篇文章的 2016 年 6 月，不，我不推荐你这么干。
因为我在 React Native 上时间花的最多的是三件事。
对于 Android ，我一开始是想搞纯 Material Design 的，这就需要有 immersive statusbar 。但是某些聪明的国内手机厂商在自己的 ROM 实现了非标准的黑色状态栏字体，然后这个智能判断状态栏字体的判据也比较呵呵。原生的话比较好解决…… React Native 的话我调整了一段时间后无果，那么直接就把代码删掉。不管状态栏了。
对于 iOS ， React Native 提供两个 Navigator 。一个是原生的，一个是与安卓通用的……照理说为了减轻代码量优化程序结构，咱们应该用通用的版本。
——但是坑爹的点在于，通用的版本里面，需要自己写工具栏。保持和原生风格一致的问题不说，坑点在于 iOS 的毛玻璃效果，是通通没有的……那么我下面 TabBar 有上没 NaivigatorBar 没有怎么破。
没办法，重写一遍程序，换回 iOS 专用版本，问题解决。然后又有一个坑……因为 ScrollView 滚上去的内容，是要现实在 NavigatorBar 的后面，然后 Facebook 写了一点神奇的东西，自动判断这种情况然后在 View 里面加点东西让第一行和 NavigatorBar 的下界对齐。为了把事情简化一下，我就说这种自动判断在某种情况是不 work 的，然后我又为此重新写了三个双平台通用的模块。
对于 Android 和 iOS 来说， Flux 的优劣见仁见智。我只能说对于业务逻辑复杂的 app 可能会变成一团 mess ，但我自己的因为需求简单所以还比较好。但是另外一个坑是刚上线的时候发现的，因为业务需要所以实现了一个 IM ，用了这个库 https://github.com/FaridSafi/react-native-gifted-messenger 。然后在做最后的测试的时候，发现输入中文的时候，特定长度以内气泡会越过屏幕边界……英文完全没有问题。
并不知道这算是控件的锅还是 React Native 的锅，但我决定不在这上面浪费时间，直接把气泡宽度写死。丑是丑了点，总归聊天内容都能看到吧。
相对来说，实现业务逻辑确实是小事，所以 RN 的愿景 learn once, write everywhere 也算是部分的实现了？不过，我觉得在目前的情况下，只有两种情况比较适合用 React Native ：
一、 C 轮以后或者是大公司（像 Facebook 自己），然后大老板拍板，五人以上团队，愿意钻到 framework 里修 bug 加 feature ，愿意自己自力更生包装 native 控件，然后也有做原生应用的团队一边协作（但这样优势在哪？）。
二、你像我一样，没有 KPI ，愿意花点时间研究 hack （当然前提是得 hack 出来），也愿意在应用里有些 compromise （英语应用，面向海外的应用，坑会少不少），然后拿出来做 lean startup 快速迭代试错的。
总之建议是想跳坑的可以再观望下。
全文链接： https://zhuanlan.zhihu.com/p/21411171
 |
1
gouflv 2016-06-24 15:17:38 +08:00
能有毅力一路填坑已经很厉害了
|
 |
2
learnshare 2016-06-24 15:41:02 +08:00
我认为还不太合适做复杂的产品， Web 转原生哪有那么顺利
|
 |
3
zhouquanbest 2016-06-24 15:48:54 +08:00 via Android
今天在 infoq 的 gmtc 看了下 qq 空间团队的 rn 分享
感觉这货看起来没有想象中的没 目前业务变化很快 又有三端要开发 也在考虑要不要用 rn 但调研了下 坑也多 在 android 中低端机上甚至出现性能完全不如纯 html 的问题 准备先做成豆瓣那种混合方式 在一步一步替换成 rn 看看 |
 |
4
jakes 2016-06-24 15:48:55 +08:00 via Android
楼主用 rn 做 im ，表情输入怎么处理？如何图文混合输入？
|
|
5
learnshare 2016-06-24 15:58:34 +08:00
@jakes 富文本编辑器？大课题
|
 |
6
zaishanfeng 2016-06-24 18:01:24 +08:00 via Android
看得我蛋疼 比看英语还累 不愧是做留学的
|
 |
7
elone 2016-06-24 20:01:31 +08:00
嗯 ，在 rn 和原生之间纠结了一段时间。我是个人开发者，现在有一个项目想着手开发，在 RN 和原生之间考虑了很久，综合来看，最终还是准备原生。毕竟 ，我是个人开发者， RN 可能 Hold 不住 。而原生的话，这么多年下来，资源一搜一大把，还是比较好解决。
|
 |
8
iyaozhen 2016-06-24 21:47:08 +08:00 via Android
@jakes 手机端 IM 的话压根就不让混合输入，传图、视频等都是发送文件。表情可以用 emoji
|
Select Language