基于RN+微应用打造多业务支撑的企业官方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正常运行。
关于作者:刘磊,普元移动产品资深研发工程师,诺亚财富,张家港银行、韵达快递、中信重工、联通集团等众多移动平台项目实施研发经验,精通移动平台架构及管控体系设计。