基于RN+微应用打造多业务支撑的企业官方App_开发

标签: | 发表时间:2021-05-28 20:21 | 作者:
出处:https://www.sohu.com

一、用户体验差

大型企业里不同C端业务大都是由不同的团队开发,所使用的技术以及页面风格都不相同,有的使用原生开发,体验较好;有的使用h5,体验较差。很难做到统一。

二、碎片化严重

不同的业务建设相互独立的App,独立分发推广,浪费资源不说,还显得很杂乱。对于市场和需求的变更,很难形成合力。

三、需求响应缓慢

市场需求变化非常快,越来越多的业务都在手机端处理了,以保险业务为例,用户办理了寿险的业务同时引导用户办理财产险业务,这个时候希望可以直接办理而不是去下载一个产险的App再去办理。

四、用户留存率低

App业务的单一化导致用户需求量大大减少,用户大多是在业务员的推广中下载安装了App,但App只涉及到单一业务,很难吸引用户再次开启去查看。

综上,大型企业建设统一的官方App是一种必然趋势。当然,在建设的过程中也将面临诸多挑战,接下来给大家分享建设官方App所面临的 三大挑战:

挑战一:用户体验与技术门槛的抉择

随着移动技术的的发展,智能手机的普及,越来越多的App建设把用户体验放在了第一位,要求界面好看,操作要流畅,简单来说就是要像微信支付宝一样好用。需要完成这样的需求首要选择是使用原生开发。原生开发无疑体验是最好的,但同时也带来了新的问题,操作系统的多样性如何快速适配,业务如何快速上线,如何可以不经过Appstore的审核即可灵活控制上线流程……

挑战二:独立建设的App如何整合

很多企业在移动信息化的浪潮中建立了许多App,建设统一的官方App不可能从零开始,不然原有的投入浪费不说,大型企业的业务相对复杂,如此多的业务很难在短时间内开发完成。

挑战三:不同的团队如何协作开发

独立建设的App往往是有不同的团队开发,所采用的技术语言不同,引用的第三方sdk的版本不同。相同的功能模块选择了不同的实现,如OCR,有的团队使用的是前端解析,有的是后端。整合到一起后的App如何协同开发是第三大挑战。

2.基于RN+微应用打造多业务支撑的

企业官方App

为什么选择RN作为整合技术?

选择什么样的技术作为官方App的整合技术是关键,既要良好的用户体验,又需要快速开发、易于整合。我们来看下移动端技术的演进,大致分为如下 四个阶段

1、网页开发

相信早期做移动App还记得,Appstore刚推出来的时候,还是允许App做个壳,直接连的是后端的一个网站,目前这种App上不了Appstore,体验实在是太差。当然本地能力也是缺失了,比如调用摄像头。

2、原生开发

随着智能手机的普及,原生开发兴起。原生开发的体验好,但是成本相对来讲高,业务一致性相对比较低,业务上线的时候,Android和iOS都要上线才可以。当然,对于这种方式还有个硬伤,更新应用严重依赖与市场和用户是不是主动下载最新版本,推广的难度也比较高。原生热更方案难以落地,特别是上Appstore的应用,会直接被拒绝。

3、混合开发

是结合了网页开发的和原生开发的优点,其大致的思路是采用HTML(或者很多人说的H5)作为UI,通过嵌入或者系统的浏览器作为渲染(通常采用Webkit),当需要本地能力的时候,采用原生语言的方式编写,并提供接口给UI端调用。因其UI的渲染采用浏览器的方式,难免会影响到用户的体验。

4、驱动原生

对于驱动原生,这种方案的大致思路是,在运行态的时候,通过调用操作系统提供的接口,对UI进行渲染,而不是把渲染交给浏览器内核。无论从用户体验、跨平台、性能、以及热更方案,都得到了广泛的认可。

综上我们选择的RN作为整合官方App的主要开发语言。

选择RN的优势一:技术先进,用户体验好

RN技术的三大特性:体验好,热更新,原生能力。可以实现一个真正的Mobile Native App,降低了技术门槛的同时带来了良好的用户体验。

但RN有一个缺陷就是开发人员开发的所有业务代码最终都会打包成一个bundle文件:

1、随着业务的增加,bundle文件越来越大,应用启动和运行速度都会较慢,达不到原来预想的原生体验。

2、对于多个开发团队,开发的代码耦合性太高,必须打包一起才可以发布,开发维护成本非常高;对于需求的响应会变的缓慢。

选择RN的优势二:RN多bundle模式支撑多团队开发

针对原生的RN应用,我们团队将其拆分成了多bundle,有效支撑多团队并行开发:

1、将RN基础能力和公共的一些API打包成了单独bundle文件,随着apk和ipa一起发布到应用市场。

2、业务代码拆分打包成了多个bundle文件,每个bundle文件都可以独立发布。

3、应用启动的时候加载badebundle+所需要的业务bundle,做到按需加载,业务代码再多也不用担心首次启动过慢问题。

选择RN的优势三:底层原生,易于整合多应用

很多大型企业早期对于C端业务也建设了一些App,建设统一的官方App并不是从零开始,如何有效的整合原有的应用,保障业务的正常运转是官方App必须考虑的问题,原有的多个App都使用了三方SDK,如何处理呢?

第一步:需要梳理出公共的SDK,封装公共API

第二步:对于一些偏向业务的原生模块,封装成业务API

选择RN做为整合语言,因为RN底层是原生应用,易于整合现有的三方SDK和公共的API,可以很好的和其他微应用通信。

为什么选择微应用模式?

微应用模式区别于传统的App开发模式,具备以下 三个特点

第一:开发期项目独立,这是微应用模式的基础

开发的独立性,确保了多个团队能够并行开发且无需要相互依赖,其应用的功能又可以与官方App相互独立,确保其自身功能的自由性。当然开发期的独立性并不意味着没有相关的约束。为了能让官方App健康的发展,相同的约束是必须的。我们熟悉的微信,在开发公众号时,需要遵守微信的相关的API规范。总结来说,开发期项目的独立性,并不是随意性,而是从团队、时间、功能等角度的独立性。

第二:业务上隔离性是官方App能够正常运转的基础

这里需要考虑两个因素,业务的相关资源需要单独规划,避免业务之间相互干扰;同时需要避免新增代码导致整个官方App的不稳定性。

第三:运行态支持动态部署

开发完成的App既可以运行在官方App中,也可以打包成单独的App在手机上运行。开发人员不用关心开发完成的App是在微应用中运行,还是独立的App。

选择微应用模式的优势一:既支持独立开发,又能约束引用

微应用模式的好处就是独立开发,对于使用RN结合微应用模式,RN使用的公共接口我们在basebundle里约定,可以很好的控制App的安全性和稳定性(特别是三方SDK的引用,可以有效控制,避免冲突),会有专门的团队去维护basebundle。各业务功能的开发团队只需要根据API文档开发相应的业务功能即可,然后打包成微应用提供给官方App即可。

选择微应用模式的优势二:统一开发流程,易于整合现有业务

官方App建设不是说所有的功能都完美了再发布,而是一个快速迭代的过程。微应用模式的第二个优势:可以制定统一的开发流程,从RN微应用的开发调试、编译、测试、发布更新全生命周期的管理。保障了各模块新的业务功能能够独立的开发测试及发布上线,互不影响。

3.某保险公司官方App案例

某保险公司C端App现状

某保险公司有着千万级别的用户群体,包含产险、寿险、健康险、养老、保险箱等多项业务,而这些触点都是独立开发维护的,所使用技术也不一样,原生+RN+H5+混合开发,移动端的技术基本都使用了,如何有效的整合现有的App到官方App里,是非常大的难点。

基于RN+微应用聚合官方生态App

在该客户实施过程中,我们采用了RN+微应用的模式,整合了现有App共同打造了集团的官方App。对于原有的业务,依然由原有的开发团队使用微应用模式开发,通过统一的编译服务,最终整合成统一的官方App,保障了原有业务的正常使用。

统一的官方App

建设完成的统一的官方App,小伙伴们在首页就可以看到熟悉的业务App图标,点击立即到达。

建设完成统一的官方App:

一、提升用户体验

一站式APP内体验跨子公司的服务,统一入口,全面提升用户体验

二、提高用户覆盖数

全集团统一APP,实现各BG客户关键旅程的融合,提高用户覆盖量达分发数80%

三、提高用户活跃度

统一APP入口,提供多元化服务,满足客户多样化业务需求,提升整体用户活跃度

四、降低开发成本

基于同一套APP基座进行应用层面功能开发,统一管理,有效降低开发成本

4.总结

建设统一的官方App是一种必然趋势,通过本文主要和大家分享了采用RN+微应用模式建设统一的官方App,采用RN技术有效整合原有的开发资源,带来原生的用户体验;采用微应用模式,支撑了多团队快速开发业务需求并能整合到官方App中,降低了开发维护成本。建设完整的官方App打造了一站式服务体验,提供多元化服务,满足客户多样化业务需求,提升整体用户活跃度。

问1: 微应用的原理是啥?

1)有没有侵入RN jsbundle的打包,id转化为name之类的

2)支不支持动态的删除和加载微应用(在不重启的情况下)

3)RN不同版本的适配问题

4)微应用动态加载过程中能够定位出现的问题吗?

5)微应用的开发调试

答:微应用是应用存在的另一种模式,支持动态加载

1)我们修改的RN的js编译流程,对rn的编译做了优化

2)对于所有的微应用支持在不重启的情况动态加载,刷新RN的缓存

3)对于RN的版本我们约定统一版本,所有接入微应用会统一升级

4)在开发期调试错误会正常显示,运行太实用框架收集错误日志

5)我们提供了微应用的调试服务和调试基座,支持动态调试

问2: rn和flutter,该怎么选呢?

答:RN 是Facebook2015年推出的驱动原生框架,Facebook自己也在使用,各大主流的互联网公司使用类似的技术开发App。开发期使用js,一次开发可以运行在Android和iOS两个平台,运行时接近原生的体验。google自己推出的框架在自己公司的产品里都没有使用,建议观望其发展而不要冒然跟进。

问3: 请问微应用也是rn开发的吗?

答:是的,大多说的微应用是使用RN开发的,也有部分微应用采用的混合模式,后续会迁移使用RN开发。

问4: APP基座主要负责提供哪些能力给微应用?

答:基座负责整个App框架的搭建,所有接入的三方能力(如微信分享、支付、OCR、活体)等等。提供微应用运行能力,微应用之间业务流转能力等。

问5: 原生渲染和h5相比,效率差很多吗?

答:原生渲染使用的操作系统底层的能力渲染,而h5使用的是webkit的壳渲染,效率相差很大。

问6: 目前很多app,原生部分已经很少了,大部分是h5页面,那么替换成rn是否有必要呢?另外rn只是实现原来原生的部分,还是一些h5也要改成rn呢?

答:感兴趣的话您可以去关注下目前各大互联网公司的App,基本都是采用原生或运行时原生处理的。对于需要交互的界面为了用户体验大都采用原生,而浏览类的使用h5。h5有使用的场景,不是所有的都要替换,建议用户交互类的使用RN开发,单纯的浏览功能使用h5。

问7: 还是不明白这几种不同方式开发的app是如何整合到统一官方的app,能否再详细点说说这个过程。

答:对于采用不同开发技术及语言开发的App整合到一起确实不是一件容易的事情,前期需要做大量的调研工作。

1、调研各App团队所使用的技术语言,开发框架

2、需要各团队整理出使用的三方组件

3、制定统一的开发规范和集成规范

4、整合开发集成

问8: airbnb早期宣布放弃rn,能分享下rn做业务开发遇到的坑吗,还建议使用吗?

答:任何的技术语言和开发框架都有利有弊,主要是合理利用其优势部分。RN 的优势在于快速开发、迭代,支持热更新,业务可以快速到达。

问9:上面说的案例,各个团队按微应用方式开发,是说按新框架进行原有应用的整个开发吧?

答:微应用模式开发,但不是推翻重新开发,而是按照统一的开发规范改造原有应用使其能够在统一的官方App正常运行。

关于作者:刘磊,普元移动产品资深研发工程师,诺亚财富,张家港银行、韵达快递、中信重工、联通集团等众多移动平台项目实施研发经验,精通移动平台架构及管控体系设计。


相关 [rn 应用 业务] 推荐:

基于RN+微应用打造多业务支撑的企业官方App_开发

- -
大型企业里不同C端业务大都是由不同的团队开发,所使用的技术以及页面风格都不相同,有的使用原生开发,体验较好;有的使用h5,体验较差. 不同的业务建设相互独立的App,独立分发推广,浪费资源不说,还显得很杂乱. 对于市场和需求的变更,很难形成合力. 市场需求变化非常快,越来越多的业务都在手机端处理了,以保险业务为例,用户办理了寿险的业务同时引导用户办理财产险业务,这个时候希望可以直接办理而不是去下载一个产险的App再去办理.

电商RN项目秒开优化实践

- - 掘金 前端
这是我参与「掘金日新计划 · 6 月更文挑战」的第34天, 点击查看活动详情. 可以申请 App 启动时预下载首包,建议拆包后申请,可以大幅度降低包下载时间. 预渲染提前渲染页面相当于从第一个阶段创建容器便开始优化. 模块拆包,Tree-shaking,懒加载. 模块拆分:可以拆分首包,可大幅提升包下载更新和加载性能.

Binlog 的三个业务应用场景

- - IT瘾-dev
02、binlog的业务应用. 01、什么是binlog. binlog是mysql的一种二进制日志文件,用来记录数据的变化. mysql使用binlog进行主从复制,如图:. 客户端向master的mysql sever写入数据. 当数据发生变化时,master将变更的数据记录写入到二进制文件中,即binlog.

Windows商店业务应用程序的关键技术

- - InfoQ cn
相比于其他各类应用程序,业务应用程序往往更强调数据存储和安全. 尽管Windows 8商店有很多限制,我们仍然有不少不同的选择来满足这些需求. 有三个直接可用的本地存储技术. Application Data API用于设置和状态的保存. 前者对文件大小没有限制,而后者是通过 ApplicationData.RoamingStorageQuota来限制的.

k8s外网如何访问业务应用之Service 池化pod

- - IT瘾-geek
一、废话:先讲述一个k8s重要概念,我觉得这个概念是整个k8s集群实现微服务的最核心的概念. Service定义了Pod的逻辑集合和访问该集合的策略,是真实服务的抽象. Service提供了一个统一的服务访问入口以及服务代理和发现机制,用户不需要了解后台Pod是如何运行. 只需要将一组跑同一服务的pod池化成一个service,k8s集群会自动给这个service分配整个集群唯一ip和端口号(这个端口号自己在yaml文件中定义),一个service定义了访问pod的方式,就像单个固定的IP地址和与其相对应的DNS名之间的关系.

业务流程成熟度对应用系统的四个影响

- - 《商业价值》杂志
企业若能在实施应用系统之前就提高流程的成熟度,建立成熟的业务流程体系,那么就能从源头上减少上述问题带来的不利影响. 业务流程是企业运作的基本条件之一,应用系统依附于企业的业务流程上,整个生命周期都和业务流程息息相关. 笔者从事IT工作20多年,发现企业管理层常常希望通过实施应用系统来实现规范化、标准化的管理来提高企业经营效率.

同步转异步+RPC的一个POS行业应用-业务模型介绍

- - 行业应用 - ITeye博客
最近在做一个挺有意思的POS消费项目,工作量不太大,但涉及的技术运用还挺有意思的. 可能有人奇怪,POS项目怎么用到JAVA语言了,先来简单介绍下这个项目背景:. 改造前:收银机下单,POS机下单并刷卡支付. 改造后:收银机跟POS连线,收银台直接下单并触发POS刷卡支付动作. 这里就涉及一个关键问题,POS机只能单线程工作,就是一个时刻只能干一件事情,比如打印,刷卡,跟卡主机通讯,都必须是一件件做.

分布式数据库在光大银行关键业务系统的应用探索

- - InfoQ推荐
近十年,我和我的团队一直负责光大银行总行的数据库运维,这里面既包括交易型数据库,也包括 MPP,还有 Hadoop 这样的大数据运维. 在运维的过程中,我们一直也在思考现在的数据库有哪些问题、面临哪些风险、数据库技术的发展趋势是什么,这一点是很重要的,因为它决定了我们为什么要转向分布式,我们希望分布式能替我们解决哪些问题,它能够解决哪些问题和它不能够解决哪些问题.

小心了Google,iPhone4S的人工智能应用Siri语音助手可能严重威胁你的搜索业务

- austin - 36氪
Siri虽然不是搜索技术,但是结合计算搜索引擎Wolfram Alpha,Wikipedia以及Yelp等后,其仍有潜力严重威胁到Google的搜索业务. 昨晚在苹果的iPhone4S发布会上,其已经演示了Siri的功能:利用Siri用户可以通过手机读短信、介绍餐厅、询问天气、语音设置闹钟等. Siri支持自然语言输入,并且可以调用系统自带的天气预报、日程安排、搜索资料等应用.

广电行业 | 大数据在用户流量分析中的应用 2015年上半年电视互动业务分析

- - 199IT互联网数据中心
199IT数据中心微信账户:i199IT. 我们可以先来设想一个生活场景:当你早上醒来打开电视,遥控器已经自动更换到你以往关注的财经频道;当你准备开车去上班,导航仪已经按照目前的路况规划了你的上班路线,及时避开了拥堵路段;在你上班的时候,手机提醒你快到结婚纪念日了,同时用你的消费喜好数据为你推荐了几款礼物以作备选;当你结束一天的工作回到家中,电视已经根据你的内容喜好为你推荐好了频道和节目,这就是大数据应用.