基于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正常运行。

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