自己用 React Native 写了个关于学校的 App，想看看 React Native 表现的童鞋们可以来试试，另外说说自己的开发体验
WildCat · 2015-11-09 13:18:02 +08:00 · 9104 次点击这是一个创建于 3083 天前的主题，其中的信息可能已经有所发展或是发生改变。
地址奉上： https://github.com/imWildCat/HappySdufe
React Native for Android 发布之后，自己一直想试试。不过在备考雅思，不想分心。
考完雅思用一周的时间写出来这个（当然之前有做设计和服务端），感觉还不错。写 React Native 还是比较愉快的，如果按照开发体验来排序： 原生 iOS （ Swift ） > React Native > 原生 iOS （ Objective-C ） > 原生 Android >> PhoneGap 。
虽然 React Native 的理念是“ Learn once, run everywhere ”，而非“ Write once, run everywhere ”。但是我这里还是用统一的 UI 实现的，一是因为没时间做两套设计，二是因为很多官方 Component 可以通用。
由于自己不是计算机专业学生，所以代码质量与见解可能比较不专业，见笑啦。
代码可以直接运行，我的服务端在 DO 。当然你也可以自己运行我开源的服务端，代码在 https://github.com/imWildCat/kalecgos-docker ，基于 docker （也是为了尝试新技术）。客户端代码中，需要把 https://github.com/imWildCat/HappySdufe/blob/master/src/utils/api_client.js#L41 中的 false 改为 __DEV__ 。已知问题： Android 平台下，自己实现的 MapView 存在内存泄漏。
使用感受
自己尝试过比较多的跨平台框架，包括 PhoneGap （ Ionic ）、 Xamarin 、 Titiaium 、 RubyMotion 等等，目前感觉这之中最有前景的还是 React Native ，原因大概如下：
1. 开源，社区参与度高，方便 hack
2. 背后有大厂推动
3. 与 React 相呼应，有希望统一前端 和 移动端开发体验（ flux 现在就可以通用）
4. 未来 native 库丰富后，可能只用 JavaScript 就写出来有趣的 App ，其他几个方案要么是第三方库比较少，或者是性能不足
5. React Native for Android 是个半成品，非常不完善
6. 要做出来像样的 App ，还是需要写不少 native 代码的。
结论
React Native 整体看起来非常赞，不过远不够成熟，在生产环境请慎用。如果你有闲暇时间，还是值得尝试一下的。
关于 SQLAlchemy 的一个问题
想顺便在这个帖子里问下，我的服务端，大约运行 12 小时之后就会提示：“ MySQL Server has gone away ”。我之前有在 https://github.com/imWildCat/kalecgos-docker/blob/master/kalecgos/kalecgos/db/database.py#L14 设置连接池，但是似乎没有用。
 |
1
kikyous 2015-11-09 13:24:49 +08:00
感觉 react native 只是一个过渡品，算是一个折中的方案吧
Ionic 这类应该更有前途 |
 |
4
chshouyu 2015-11-09 13:46:45 +08:00
安利下我做的 V2EX 客户端
https://github.com/chshouyu/ReactNativeV2ex |
 |
5
cloverstd 2015-11-09 13:49:38 +08:00  1
我没用 SQLAlchemy ，我用 Peewee 时，也会出现这个问题，然后根据官方提示 http://docs.peewee-orm.com/en/latest/peewee/database.html#error-2006-mysql-server-has-gone-away
要手动打开关闭数据库连接 |
 |
7
yyfearth 2015-11-09 14:23:53 +08:00 1
@kikyous @WildCat React Native 确实是一个很有意义的试探 之后会怎么样还很难说
PhoneGap ／ Cordova ＋ Ionic 或者其他移动 HTML5 框架 这条路线目前来看 对于某些类型的 App 或者服务来说已经足够好用了 一些简单的 App 用这个还是很不错的 而且在目前比较新的系统和机子里面 效果和性能已经还不错了 但是对于 UX 或者 性能 要求比较高的 App 肯定还是不行的 但是在 Native App 里面嵌入 HTML5 页面的做法 已经非常普遍了 总的来说没什么坏处 因此 我觉得有 React Native 存在 把 Native App 和 HTML5 Web App 融合更近一步 而且我觉得在 React Native 的框架下 一部分用 Native 实现 一部分再用 Web 实现 都是可以的 还可以充分重复利用 JS 业务逻辑代码 只把需要高性能的部分用 Native 实现就可以了 这些与 Xamarin ／ RubyMotion 并不具有可比性 因为一个是 .Net 一个是 Ruby 主要针对的开发人员不一样 而 React Native 和 PhoneGap ／ Cordova ＋ Ionic 等 主要都是 JS 所以可以用来比较 因为往往是已经有了成熟的 Web 系统之后需要开发移动 App 这样的情况比较适合 |
 |
9
WildCat OP 1
@yyfearth 抱歉，可能拿其他语言的方案来比较有点“关公战秦琼”的味道。但是我的主要意思是站在一个初创团队或者您说的“已经有了成熟的 Web 系统之后需要开发移动 App 这样的情况”。虽然 Xamarin/RubyMotion 面向的是不同语言的开发者，但是无法忽略的一个事实是，这两种方案的资料太少（或者说用户群太小），即使有实现类似 cross-platform 的方案，也不够成熟。我觉得既然打算开发 App 了，肯定不能局限于某种语言（.net / Ruby ），所以我不认同您说的“因为一个是 .Net 一个是 Ruby 主要针对的开发人员不一样”。下面简要说说我为什么不看好这两个方案。
1. Xamarin ： Xamarin 开发分 native 的方式（我记不清怎么称呼这种开发方式）和 Xamarin.Forms 。 native 类似用 C# 包装的原生 API ，学习这类开发还是得去查阅 iOS / Android 官方文档，成本不见得低，而且后期维护成本可能更高。对于 Xamarin.Forms ，我 13 年夏天买了学生版本的 Xamarin Business Plan ，一直希望能用 Xamarin.Forms 来实现自己的 Idea 。自己觉得写足量的 Custom Renderers 就可以获得原生的体验，但是现实不尽人意。抛开语言的因素不谈，私以为 Xamarin.Forms 是可以与 React Native 作比较的， Custom Renderer 正好对应 Native UI Components ， Dependency Service 对应 Native Module 。 2. RubyMotion ： Ruby 是我喜欢的语言，但是对于 RubyMotion ，我最不认同的一点，和 Xamarin 的 native 方式一样，预期调用写好的 wrapper API ，还不如直接写 Java/OC/Swift 。类似 Xamarin.Forms/React 的方式也有社区实现过，但是我之前给官方提问的时候，他们表示官方不会实现这种方式的，参见： https://groups.google.com/forum/#!topic/rubymotion/psWWoGQewCk 。 3. NativeScript 的方式与 RubyMotion 类似。 对上面这些方案的看法，与 http://fex.baidu.com/blog/2015/05/cross-mobile/ 这篇文章的观点类似： > 可以看到用法和官方 SDK 中的调用方式是一样的，只不过语言换成了 JavaScript ，并且写法看起来比较诡异罢了，风格类似前面的 Hyperloop 类似，所以也同样会有语法转换的问题。 这么做最大的好处就是能完整支持所有系统 API ，对于第三方库也能很好支持，但它目前最大缺点是生成的文件体积过大，即便什么都不做，生成的 apk 文件也有 8.4 MB ，因为它将所有 API binding 都生成了，而且这也导致在 Android 下首次打开速度很慢。 所以，我觉得我拿这些方案对比是合理的，尤其是站在一个初创团队（并没有局限某种语言）的角度上来讲，出发点仅仅是节约开发成本（当然不可避免牺牲一定的用户体验）。 当然，我个人的开发可能比较激进（愤青？），我也经常与某位支持 RubyMotion 的朋友吵得不可开交，谁也不能说服谁。但是我发这个帖子的目的，也算是抛砖引玉，让大家都说说自己的观点，以便他人参考；并不是要评出个一二三来。不过主楼和此楼都是站在楼主的角度讲，难免有失偏颇，请见谅。 我觉得对于我们写代码的，如果要选择一个跨平台方案学习，选择的出发点应该是学习成本比较低（比较常用的语言、文档完善、用户群大，方便搜索）、潜在应用范围大的。至于具体怎么判断，我觉得大家自行思考为好 ：） |
|
10
WildCat OP |
 |
11
ipconfiger 2015-11-14 01:37:51 +08:00 1
SQLAlchemy 的問題很簡單，在 create_engine 的時候加入參數 pool_recycle= xxx , xxx 是秒數，表示 xxx 秒後，連接池會回收這個連接，因為 MySQL 默認會在連接 7 小時內沒有操作就主動斷掉連接，所以設置為 3600 * 7 以內的數字就行了
@WildCat |
Select Language