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

转载本文需注明出处:微信公众号EAWorld,违者必究。

引言:

随着移动信息化的发展,近年来很多大型企业建设了许多C端App。用户在同一家企业办理不同的业务需要下载多个App,越来越不方便,建设统一的企业官方App已是一种必然趋势。

建设官方App过程中会面临诸多挑战,选择什么技术?如何快速整合,保障原有业务正常运转?RN如何支持多团队多应用协作开发?……本文将会为大家逐一解答。

目录:

一、大型企业C端业务移动化挑战分析

二、基于RN+微应用打造多业务支撑的企业官方App

三、某保险公司官方App案例

、总结

1.大型企业C端业务移动化挑战分析

随着移动信息化的飞速发展,很多大型企业近年来建设了许多C端App,每个App都各具特色,用户在同一家办理不同的业务需要下载多个App,越来越不方便。

随着市场需求和用户需求的不断增加,问题也逐渐显露出来,主要体现在以下四个方面

一、用户体验差

大型企业里不同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正常运行。

原文发布于微信公众号 - EAWorld(eaworld)

原文发表时间:2018-09-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云计算D1net

采用云计算和虚拟化的益处

在目前的情况下,IT部门热衷于降低成本和提高性能。创新使用先进的技术,这是一个合乎逻辑的解决方案,但很难实现。数据中心需要优化的基础设施和部署策略,以提高数据中...

3615
来自专栏企鹅号快讯

关于小程序的历史留存

微信小程序有一个很重要,但是却经常被忽略的功能——使用历史自动留存功能。 该功能最直观的表现形式是,小程序的使用历史列表。而除此之外,还有两个人们可能不太会注意...

24710
来自专栏BestSDK

想做产品经理,先从写一篇PRD开始吧

一、什么是PRD? PRD为Product Requirement Document的简称,其中文翻译为:产品需求文档。该文档是产品项目由“概念化”阶段进入到“...

4297
来自专栏逸鹏说道

解析微服务架构(二):融入微服务的企业集成架构

上一篇文章介绍了微服务架构的起源、定义、通用特性、常见概念误区、微服务架构与SOA架构比较、微服务架构收益以及企业引入微服务架构的策略。 本文将介绍融入微服务的...

3076
来自专栏即时通讯技术

新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践

随着社会的发展、互联网技术的进步,以前的大型机服务端架构很显然由于高成本、难维护等原因渐渐地变得不再那么主流了,替代它的就是当下最火的互联网分布式架构。

1354
来自专栏飞总聊IT

互联网企业的开源使用窘境与出路

1 自从Hadoop生态圈流行开来以后,以Apache基金会为代表的开源社区空前强大,国内外互联网公司都纷纷使用开源软件。然而参与开源社区并非是一件容易的事情。...

3688
来自专栏云计算D1net

关于无服务器计算,您需要知道的10件事

如果您阅读了2017年有关于IT特别是云计算方面的各种预测,您很有可能碰到“无服务器计算”这一术语。早在2014年亚马逊的网络服务(AWS)已推出了第一大无服务...

3436
来自专栏Snova数据仓库

Snova数仓简介

Snova为您提供简单、快速、经济高效的PB级云端数据仓库解决方案。借助于Snova,您可以在数分钟内创建拥有数百节点的企业级云端数据仓库,并高效的完成日常维护...

1602
来自专栏程序你好

为什么Devs喜欢GitHub(和微软购买它)?

822
来自专栏Java架构师历程

学习微服务的十大理由

始终关注新技术,语言和框架,以彻底改变您的组织。如果你仍然在你的立方体中使用整体框架中的代码搞乱,那么你可能生活在过去,那里有一个小应用程序和一些员工来处理它。...

2753

扫码关注云+社区

领取腾讯云代金券