我本人是一个篮球迷，平时很喜欢打篮球也有关注与篮球相关的资讯，相信NBA对每个篮球迷来讲都是一个再熟悉不过在平台了。篮球是我的爱好，而编程是我的职业，我是一名移动开发者。业余时间想着自己捣鼓个应用，思来想去觉得就做个与篮球相关的吧，一来是自己对这方面稍微了解一些，二来是完成自己的一个念想。
应用需要兼容目前最主要的两大移动平台：Android和IOS，而为每端独立开发一套代码，就人力来讲耗时太长，工作量也相对较大，所以就考虑使用跨平台技术来开发，选用由FaceBook开源的React Native，尝试一下非原生模式的开发体验。
APP的状态维护会随着功能的增加而变得艰难，在React中禁止直接操作DOM节点，不然会出现状态变化和异步结果混淆在一起，但是更新State仍然是个棘手的问题。而Redex的集成可以让应用中的数据流更加可控。
Redux的工作流程如下：当你想要更新状态时，你需要发送一个活动（Action），Action里面写清楚你想要干什么，当你把事情分清楚之后，需要写一个把每个Action和返回的新状态联系起来的函数，这种函数统我们称它为Reducer，它负责给应用中监听状态处返回新的状态。
熟悉面向对象开发的开发者可以选择Typescript作为开发语言，因为它具备面向对象语言的特性，React Native提供了插件用于将Typescript转换成Javascript。它提供了编译时的类型检查，可以尽可能地避免Javascript语言运行时可能出现的‘undefined’问题。
① 使用 Git 进行代码管理；
② 本地开发环境搭建，参照 React Natie开发文档；
③ IDE：Visial Studio Code、Android Studio（本人在应用开发过程仅在Android环境下进行了调试，IOS还没跑过，想要跑IOS在同学需要自己搭建开发环境，可能会一些兼容问题得处理。）
在实现上有两种方案可供选择，一个是本地通知，还有一个是远程通知。
本地通知的原理是这样的：用户在APP内选择了自己的“主队”之后，客户端将主队的标签以redux缓存保留在本地，一天内用户第一次打开APP的时候就会网络请求后两天的比赛数据，将本地的“主队”标签与网络请求返回的数据集进行比对，提取出与“主队”相关的赛事信息集合，保存在本地。接着，需要JS层与Native层的交互，自定义一个NativeModule接口，接口里面实现一个从JS层获取赛事信息集合的方法，赛事信息集合以方法参数的形式传递过来。最后，使用JPush提供的创建本地通知的API构建通知，设置通知的标题、内容、触发时间。最后，客户端在监听到通知之后就会弹出系统通知框提醒用户相关的赛事信息。
远程通知的原理是这样的：使用JPush官网提供的服务端SDK在本地集成一个推送服务项目，用户在APP内选择了自己的“主队”之后，客户端将主队的标签以redux缓存保留在本地，与此同时，客户端调用react-native-jpush提供的接口JPushModule.setAlias(alias, successCallback)将标签发送给服务器SDK，后台接收到标签之后会保存起来。每天凌晨零点，推送后台会发送一个访问NBA赛事接口的请求，获取当天的比赛数据集合，然后与“主队”标签做比对，提取出用户关注的球队的赛事信息存放到集合里面。接着，服务器调用JPush服务端SDK提供的接口JPushClient.createSingleSchedule(name,time,PushPayload)设置定时推送通知任务，推送的用户根据就是客户端提交上来的别名，在比赛开始前半个小时会给用户设备发送推送通知，客户端在监听到通知之后就会弹出系统通知框提醒用户相关的赛事信息。
综合比较两种方案，第二种方案更具可行性。第一种方案受网络因素限制较大，请求比赛数据集合和推送通知都放在客户端进行处理，受用户使用APP情况的影响较大，比如用户今天没有打开APP的话，就无法请求数据，通知推送就无法进行。相比之下，将获取用户关注的球队的赛事信息和推送通知的实现放在服务端来做的话，就可以不受用户操作APP情况的影响，客户端只需要监听通知，这个方案更加准确可靠。
推送服务方案二的原理图如图7.2所示：
-
运行Android工程失败
-
React Navigaion：导航对象没有根页面
-
更新Typescript
-
开启Hot Reloading动态更新布局
-
React Navigation：如何给React Navigator的headerRight添加监听触摸事件
-
打印日志
-
关闭黄色的WarningBox
- React Native “Write once，run everywhere”的设计理念能让开发者以比较小的学习成本来开发出一个跨平台的应用软件，很适合数据流式的App，使用Redux能够很好地管理数据状态；
- 对于有比较重的需求的软件，比如需要大量使用地图，不建议使用RN开发，一个是性能问题没有原生的好，还有就是第三方地图库对RN的支持不那么完善，很多时候需要自己填坑；
- 使用RN写UI时，需要关注页面重复渲染的问题，组件的更新在底层使用了diff算法，在Props或者State发生变化时，就会引起组件的重新渲染，当然这也可以通过shouldComponentUpdate生命周期来加以控制，或者让组件继承PureComponent。可能在渲染数据量较小的时候对性能的影响不那么明显，但是还是得养成在写代码过程中关注性能的好习惯；
- 对于RN能否缩短开发周期，提高开发效率的问题，只能说凡事有利有弊，使用RN开发UI的效率高了，但是在解决一些特定平台问题上面花的时间可能会比较多，因为有些问题只能放在Native去解决，也就意味着需要Android和iOS各自开发一套，然后还要加上Naitve与JS交互的代码。