前端如何推动react-native项目落地

[iscarecrow]

在移动开发中，不管业务快速迭代需求还是技术发展都让前端需要承担更大的责任。

所以大方向上cs方案到bs方案的推进探索，我认为是一个趋势。而react-native在现有前端体系中属于一个不错的选择。

面临的问题

• 如何获取iOS，安卓等部门的配合
• 如何说服产品，boss等
• 技术快速迭代的风险
• 业务的怎么选择分配
• 团队内部人员的培训

rn方案的优势

• 动态发包更新
• 开发效率高，一端开发两端可用
• 体验好

先推销方案的优势吧。其实这块的推动，问题不在于技术上的问题，更多的阻力会来自部门分工和业务职责，所以好好思考怎么说服其他人吧。取决你团队影响力，其他人的认知，协调其他部门等问题。

快速技术迭代的风险

rn当前release周期，差不多两周一次。包括bugfix，newfeature等。所以技术方案的不成熟，对团队成员来说有蛮多的挑战。
可以关注react-native git 上的 issue 和 release情况。

• rn issue

业务分配问题

面临开发人员有限和技术不成熟等问题，会考虑以下几点将页面切换成rn

• 只会在app内部出现的页面，不需要同时维护h5
• 有强交互并且访问频率极高的页面
• 性能上可用，非无限下拉页面

所以暂时将商店相关的购物车，礼券，订单，详情，还有我等页面做了rn切换

开发与上线验证

• 热更新方案
• fabric采集奔溃信息
• 性能采集
• 开发环境

热更新方案上首选 react-native-code-push

自建流程：

打包rn的js包 -> 转化成zip -> 部署 -> 客户端拉取远程zip包 -> 解压到对应的目录。

需要提供对应的包管理后台，此处根据客户端的版本配置发包。

更新过程 客户端运行时

• 弹框，下载
• 杀掉应用，重启后更新

性能采集
当前采用人工手法，模拟器下，看内存情况。比如ListView， 嵌套层级，多view进入等的内存改变情况。自动收集方案???(待思考)

fabric采集奔溃信息
看fabric的奔溃日志

开发环境
个人开发采用本地部署方式。如何进行Debugging 看官网。 那么对于测试人员进行测试应该怎么做呢？

• 借助了dt现有的系统，部署静态资源包括js包和图片
• 需要客户端做host代理，可访问到对应资源

团队内部培训

为了让客户端和前端的开发同学，对于新技术不产生恐惧，首先得激发他们对新技术的热情。然后就是做技术分享了。大致包括：

• react基础， 生命周期，组件定义，数据，jsx等
• redux数据层管理， 如果理解 redux的数据模型
• react native的布局方案 flexbox布局如何写
• react native 基本控件介绍，针对现有业务如何拆分

目的上是希望不管是前端还是客户端都能参与到rn的开发过程中

技术问题汇总

• 导航栏，采用了客户端自建方案。 iOS希望自身导航栏统一。引入pageView模块
• 数据层设计，直接获取数据使用客户端的Service。 比如消息，个人信息等，架构希望发展成客户端的Service模型对多平台展现层可公用
• 请求库HttpRequest，采用统一切换到客户端方式，统一客户端处理
• ListView控件Recycle性能不够，iOS需要自己封装TableView，但是同时也面临代码与安卓不一致。 cell层级过多的东西，所以对可控的下拉列表，还是使用ListView的方案
• 布局整体基本布局都没问题，安卓和iOS存在一些不一致的情况，具体业务具体处理
• kv存储，数据库
• 打点接口
• 广播系统， 需要保持 客户端，h5，rn三者接收一处广播
• 设备信息
• 路由方式，如果采用全app rn方式，可采用前端路由。 现有的设计里，是通过打开新页面后重新注册一个rn页面的方式处理的

产出

最终结果还是非常不错的。 至少已经有页面在线上生产环境投产，同时监控反馈，并没有造成奔溃问题。整体推动流程速度不算快，遇到的问题更多的来自部门沟通和业务排期等。 毕竟没有专门的团队来做这块，作为技术型驱动项目，更多还是得靠自己的推进的。

建议点

此项目还是需要客户端和前端一起开发才合适， 当然对于个人而言最好能懂iOS和安卓开发，这样在整个app角度的设计上，才能站在更高的高度