日本研发预防犯罪的手机APP 具有报警器功能_励志网

日本研发预防犯罪的手机APP 具有报警器功能

2018-11-21 03:57 来源:励志网

发布页面的UI是用ScrollView控制还是ListView控制?

首先从整体上了解一下基于RN的App开发架构。架构共分为五个部分:Native组件/API层、JS中间层、JS业务层、视图载体页、热更新平台。JS业务层、JS中间层、Native组件/API层三者运行于视图载体页中,且JS业务层和JS中间层的代码更新是通过热更新平台更新到用户手机应用中的。Native组件/API层是整个装置的基石,JS业务层通过JS中间层调用Native组件与API。

万事具备,水滴石穿#p#分页标题#e#5月份PM已经陆续把需求整理完成了,然后成立了项目组,加入了发布业务的FE及Server。项目代号为“水滴”,无线FE同学的创意。水滴,源自于三体,多维空间武器,通过量子纠缠进行超远距离通讯和控制。ReactNative如同水滴,对JS-Native通讯和控制。另外,寓意水滴石穿,坚持不懈,终能成功!

热更新这块,在这里我从另外一个角度来阐述,即我们为什么不用现有市面上的方案,而要自己搞一套。下面的三个章节来逐步叙述。

由于是集成到已有项目,如何处理项目中的统一导航和RN提供的导航?

RN热更新调研(2016.4)热更新调研是整个调研最最关键的一环,因为官方并没有热更新的成熟方案。整个4月份一直在进行热更新的调研,直到5月8日结束。热更新调研主要涉及的主题为:

导读ReactNative在iOS界早就炒得火热了,随着2015年底Android端推出后,一套代码能运行于双平台上,真正拥有了Hybrid框架的所有优势。再加上Native的优秀性能,让越来越多的公司在实际项目中一探究竟。58同城App发布模块年代久远,一直计划进行重构以适应日益苛刻的用户体验,这个需求与我们在ReactNative上一探究竟的意愿一碰撞,就产生了ReactNative在58App的开发实践。

合并diff调用google-diff-match-patch的API为(iOS端为例,其他端可找到对应API):

作者简介:彭飞,58同城iOS客户端架构师。专注于新技术的研发,主要负责App端组件化架构以及性能优化,并已推广ReactNative在58同城App中业务场景的应用。在MDCC2016iOS开发峰会上分享《58同城App在ReactNative上的开发实践-iOS视角》主题演讲。

至于JS业务层与Native组件/API层之间的耦合关系,可以试想,如果没有中间层的封装,以上文的dialog组件为例,在业务层中将会,其中WBCustomDialogManager是Native的组件标识别,还有show函数的相关参数存在多份这样相同的代码。这些与Native相关的内容如果发生变化,则所有与这个组件相关的业务都要更改。而引入了中间层之后,业务调用方,将不再关注这些细节,中间层在其中做了解藕。即使Native发生了变动,也会最大限度降低业务层的变动。

#p#分页标题#e#在介绍diff生成及合并算法之前,先介绍一下一个关键性要点。即我们重点关注ReactNative中JSBundle的内容的特殊性,发现打包编译后的一个JSBundle可以拆成一个稳定的公共部分加上差异部分。如上图所示,针对一个入口文件pageIndex.jsbundle,可以拆分成稳定的commonPart.jsbundle以及差异部分diffPart.jsbundle。其中,commonPart.jsbundle与具体业务无关,是ReactNative中一些公用的JS库。

上图所示的是在自定义弹窗组件(Dialog)中的代码片段,从代码的95行到102行,所做的是处理iOS/Android两个平台上弹窗界面确定按钮放置的位置不同而做的差异化处理。类似这些平台差异化的内容在实际开发中会有很多,如果这些差异都有业务方去做,不仅代码可复用性差,而且耗时耗力,每一个新接入方都要重新开发调试。

2.计算增量的基准文件不唯一,平均合并的diff个数过多,增加了服务器处理增量的复杂度和降低了App端合并diff性能。

curl':8081/blank.ios.bundle?minify=true&dev=false'-ocommon.ios.jsbundle得到的common.ios.jsbundle结果如下图所示:

热更新平台热更新平台是整个框架的核心。热更新平台的主要功能是将JS业务层及其引用的代码编译link好的JSBundle下载到NativeApp中。在此过程中,需要控制更新文件的大小以及失败情况的处理。

生成diff调用google-diff-match-patch的API为(iOS端为例,其他端可找到对应API):

热更新流程如上图所示。图中载体页是指native加载ReactNative代码的一个载体。RN是ReactNative的缩写。下面对上述流程进行叙述:

Native组件/API层与JS中间层是无状态,可以被复用的,它们被不同业务调用和组装,能形成不同的业务功能。在这里,一切业务都是基于组件的,任何业务的形成,都是调用Native组件及API来的。尤其是引入了JS中间层,不仅抹平了在不同平台(iOS/Android)上调用组件的差异性,还解耦了JS业务层与Native组件层。如果没有JS中间层,Native一个组件或者API的变动,都需要通知所有的业务方去进行修改,在业务到达一定量的情况下,这种改动不仅费时费力还具有风险,会影响线上功能。引入了JS中间层之后,Native组件及API的变动,都在JS中间层进行处理,JS业务层毫无感知。

Diff更新以JSBundle文件为单位,业务Diff之间相互不干扰。

CodePush和react-native-pushy在利用bsdiff算法计算增量时,是相邻两个版本文件的diff。现在假设用户本地App文件版本是1.0,而服务器最新文件版本是4.0,则服务器需要返回App3个diff(1.0至2.0一个diff,2.0至3.0一个diff,3.0至4.0一个diff)。所以,由于bsdiff算法计算增量的基准文件不唯一,导致平均需合并的diff个数过多。这不仅增加了服务器处理增量的复杂度,还降低了App端合并diff的性能,合并时间多长,阻塞用户操作。

性能方面,通过对ListView的针对性分析,在数据量不大的情况(50条左右),内存和CPU的差别在iPhone4S以上的设备上可以接受;当数据量比较多,比如试验过程中的150条,内存比较大,在低端设备(4S/5C)上随着业务的扩展,性能会有瓶颈。

工欲善其事,必先利其器ReactNative是一项全新的技术,不同公司使用有不同的体验,好坏众说纷纭。基于此,必须根据自身的情况进行摸底调研。58App的调研过程从2015年6月就开始了,那时候Android还没推出,仅调研了iOS的相关情况。真正的全面调研展开是在2016年3月开始的,整个过程持续到5月初结束。下面分三个阶段介绍一下58App调研的具体历程。

在这一层,除了ReactNative本身提供的原生组件外,我们还对没有覆盖到的组件进行了封装。ReactNative提供的组件有Image、ListView、Picker、Text、TextInput、ScrollView等,具体可从ReactNative官方网站上查询。我们扩展的组件有:支付、语音、弹窗、单选选择器、多选无联动选择器、登录等。

本文重点介绍的是实践过程中的技术架构和Native组件层以及热更新平台的基本情况,以期能对ReactNative的从零到深入有一个整体的把握。

热更新现在公开的两个方案是微软的CodePush和ReactNative中文网中的react-native-pushy。这两种方案实现思路其实差不多,但针对我们的App,不能满足以下情况:

这些扩展的组件和API使得用ReactNative,来实现本地化的业务成为了可能。当然随着业务的逐步扩大,还会不断丰富组件/API库,以适应业务的特殊性和多样性。具体自定义组件情况如下图:

视图载体页#p#分页标题#e#视图载体页在这里扮演了很重要的角色,是所有业务的一个统一载体。以58同城App为例,里面有大类页/列表页/详情页/发布等不同形态的各种业务。通用的做法每一个业务一个载体页。因为载体页是Native代码写的,这使得当需要扩展一个业务线的时候,必须依赖发版。而统一了载体页后,只需要通过热更新平台将JS代码更新到App本地即可实现。

Server端热更新diff文件存储方案及更新方案?

跳转协议在不同的App中,实现思路不同,有很多App采用的URL形式来实现,但具体思路与上文描述的JSON形式相同。

在App提交给应用商店审核时,会将RN集成编译后的JSBundle打进内置资源里面去,而一个完整的JSBundle在区分平台(iOS/Android)以及JS压缩的前提下,体积有600K左右。如果随着业务的快速扩展,假设有100个JSBundle的内置资源,那么大小就会达到60M。而应用商店的App大小,以58App为例,大小才100M。内置资源过大,导致整个应用包的体积过大,一是占用用户手机容量,另一个每次下载应用耗时超长。这在一定程度上是很难接受的。

1.内置资源体积过大,导致整个应用包的大小过大,导致过多占用用户手机容量以及下载应用耗时超长。

以弹窗dialog组件为例,Native与JS交互的协议为:

视图载体页单一载体功能的实现,很关键的部分在于跳转到载体页跳转协议的设计。由于跳转协议与具体的业务关联较大,我们的跳转协议中有一个重要的参数pagetype,在这里我们将pagetype设置为RN,而不是list(列表页)/detail(详情页)等与业务相关的类型。这样在跳转入口,服务器进行配置的时候,不需要维护到特定载体页的映射,从根本上解除了因业务变动带来的跳转配置耦合。

1.新建一个blank.ios.js文件,在文件中仅需引入react及react-native,注意不要包含任何业务代码,具体代码如下截图:

当然,ReactNative的理念是比较好的,既能拥有Native的良好用户体验,又能具备Web的快速发布和迭代的功能。如果Android后续能很好推出,还能实现跨平台的“一处编写,多处运行”的效果。无论集成与否,后续要持续关注,保持前沿技术的敏感性。对应ListView性能问题,RN官方一直没有一个很好的解决方案,我们最近也在做一些调研和组件的重新封装,期望能从根本上解决这个问题。

开发学习成本上,上手会比较快。但在开发的过程中遇到一些复杂的业务逻辑,得基于现有的框架扩展组件;还有在崩溃的收集上会比较麻烦,只能定位到OC层的代码,对于JS的运行时崩溃,目前的崩溃收集系统还无法采集。

进入载体页之后,会先判断是否有RN缓存,如果有缓存,则直接进行下一步。如果没有缓存,则去服务器下载对应的RN资源(RN资源指的RN代码文件)。

既要控制更新包的大小,又要控制内资资源的大小;

iOSRN调研(2015.6)ReactNative确切的说从2015年开始在国内火起来的。墙外开花,墙内结果,国外技术研发,国内炒得火热。阿里天猫在这一方面走的比较靠前,但这时候Android部分还未推出,仅有iOS。当时我们是拿二手车的列表页进行的试验,主要测试用RN实现的列表页和用Native实现的列表页在性能上的差别,当时得出的调研结论如下:

JS调用的示例为:

3月份的调研,在RN的应用层面做到了一个心中有数,为后期的技术工作开展奠定了一个很好的基础。至于基础调研过程中的问题,限于篇幅问题,就不一一展开叙述了,有兴趣的同学可以私下交流。

如何用RN提供的原生组件实现发布界面?

是基于二进制算法的diff还是基于文件算法的diff?

3.将整个App的所有JSBundle文件打包进行更新,不区分业务。导致如果一个业务的JSBundle有问题,会影响其他业务JSBundle的正常运行。

JSBundle拆分及公共部分生成

异常回滚机制?

在ReactNative中,除了组件,还有API。官方提供的API有ClipBoard、AsyncStorage、AppRegistry、Alert等,更多完备的API可从ReactNative官方网站上查询。我们扩展的API有:跳转、定位、埋点、初始化参数等。

降低服务器处理增量复杂度和提高App端合并Diff性能;

基于对上面的分析,我们得出了热更新需要解决的三个问题:

基于RN的移动App开发架构

JS业务层JS业务层主要专注了业务的实现,包括视图的渲染、组件的串联、UI样式的设置、ServerAPI接口的调用与数据的处理。JS业务层在改装置中是最终代码的落地,视图载体页加载的视图以及热更新系统更新的代码都是直接针对JS业务层的,只是这时业务层引用了JS中间层的代码来实现对Native组件的调用。

双平台RN基础调研(2016.3)在2015年底,ReactNative就推出了Android版本,然后就有很多公司在开始尝试了。春节流量高峰一过,上面就在筹划RN上开发尝试的事了。大体方向是以App中的发布模块做为试点,然后我们调研的技术偏向于发布模块的相关功能实现。调研由无线的总监专门组织,iOS/Android/JS分别出一个人,成立了调研三人组,每周汇报进度。3月份的调研主要面向的是RN基础调研,摘取了其中的一些调研细节:

需要补充的是,因为commonPart.jsbundle依赖Native代码,所以commonPart.jsbundle的更新是跟着App发版走的。

热更新的三个主要问题

2.通过curl命令将blank.ios.js文件编译成common.ios.jsbundle。笔者在本地的执行命令为:

Android/iOS如何将RN集成到当前项目中?

1.进入载体页,判断是否有缓存。

JS中间层JS中间层是非常关键的一层,是为上文中扩展的Native组件/API来服务的。JS中间层如上文所述,不仅能抹平在不同平台上调用Native组件/API的差异,还解耦了JS业务层与Native组件/API层。

Native端如何获取文件的更新?

下面对这五个部分进行分别介绍:

写完的JS如何打包给Native使用?

Native组件/API层Native组件/API层是在整个架构的最底层,也是整个装置的基础。

热更新平台涉及JSBundle资源管理系统(Server)、JSBundle数据接口层(Server)、JSBundleNative更新及管理层(Native)。JSBundle资源管理系统负责将相关JS业务层代码编译link成JSBundle文件,并将相关更新写到一个数据缓存中心(例如Redis或Memcached)。当Native通过JSBundle数据接口层提供的接口获取对应的JSBundle的信息时,数据接口层将从数据缓存中心查询数据并返回给Native端。Native端为了提高用户体验,会对JSBundle进行缓存,用户访问相关页面的时候,先展示缓存,再访问接口,看是否有更新。

热更新Native端的流程?如何控制热更新包的大小及内置的资源大小?

发布表单中图片区域如何处理?Native封装的组件粒度如何?

Diff的生成与合并基于上文对jsbundle的拆分,我们选择了google-diff-match-patch算法生成diff及合并diff。在计算diff时,以commonPart.jsbundle为基准,计算当前版本的pageIndex.jsbundle与commonPart.jsbundle之间的文本差异,然后APP端拿到文本差异描述后,再利用google-diff-match-patch算法将文本差异合并到本地的commonPart.jsbundle中去。

集成ReactNative需要从iOS7.0开始,在7.0以下会因私有API问题在审核过程中被拒;

CodePush和react-native-pushy做的是一个通用的热更新平台,一个App有一个key,文件更新以此key为标识,所有文件在一个zip包里面,不区分业务。当前稍微大的互联网公司,都是以业务线划分职能的,在技术架构上,各业务线业务应该做到相互不干扰。react-native-pushy这种不区分业务的更新模式,会导致如果一个业务的JSBundle有问题,会影响其他业务JSBundle的正常更新,造成业务的相互干扰。

热更新的解决方案基于上面的三个问题,我们有如下的解决方案:

commonPart.jsbundle生成的方法为(以iOS为例,Android的原理相同):

热更新中涉及的细节真的很多,上面只是列出其中的一些。我们的调研过程,也是内部一遍遍技术评审/修改/再评审的过程。在下一章节会对这里提到的主要问题进行分析和解释。

责编: