什么是微应用
其实和小程序还有微前端的概念有点类似（抛去小程序的商业模式来说），都是为了将一大堆的小应用集中到一个大的应用上。我们设想能不能有一种方案，像小程序一样的接入，但却不想像小程序一样，再用特定的标签去构建，增加技术的普及成本；像微前端那样，有一个主应用和众多子应用之间做通信。快速集成“现有老旧的项目应用”。有“按需加载”带来的首屏极速开启的便利，又有“全量加载”时，页面切换的流畅体验。
简单的想法
这里我计划用一个原生应用作为这样一个主应用，通过 web sdk，也就是 js-api 去打通各个自应用之间的通信问题。类似的方案其实在混合开发中应用的很广泛。但是我设想着有没有这样一套方案，依托于 umi 让这样一个流程推进的更加顺滑。在性能体验上做到更好。
为什么说想要依托与 umi 构建呢？
因为 umi 的插件机制可以很灵活的，将需要扩展的功能快速接入，或将仅仅编译时需要的运行时环境剔除到项目之外。举个例子来说，比如我提到的 web sdk，可能我在开发过程中需要一个 mock 环境来调试，但是当微应用被集成到主应用之后，它就不需要这样一个 mock 环境了，这在 umi 中可以很容易的实现。当然在其他的前端架构中，通过 webpack 的配置要剔除某些东西，也是一件简单的事情，但是要把某些东西加回来，可能就比较困难了。比如，在 umi 中请求 request 对象，它在调试环境（纯 web 的环境中）可能就是一个 featch ，但是在微应用平台中，可能就是一个类似 wx.request 这样的方法了。同样的比如路由跳转的方法，其实也是同样的道理。
方案的初稿
一、应用开发（包含扩展能力）
支持所有的web方案，不强制使用框架，最终产物也更贴近于web资源，只是在需要原生能力的时候调用平台SDK。但是依旧推荐使用alita 开发，因为可以通过框架层支持，把产物包拆的更小，可以使打开微应用的时候加载的web资源更少。可以解决web应用要么首屏打开慢，要么切换页面需要再次加载资源的问题。
二、平台SDK对接（应用API和服务端API）
1、应用API
① 基础能力（设备系统信息、更新微应用）
② 网络能力（请求、上传、下载、WebSocket）
③ 媒体（地图、图片的选择和保存、相机、音视频）
④ 位置（定位、选择地址）
⑤ 文件（保存、删除、选择）
⑥ 开放能力（登录、授权信息、支付、指纹和人脸识别、活体检测、数据统计）
⑦ 设备（NFC、剪切板、屏幕信息、扫码）
2、服务端API
① 登录
② 获取用户信息
③ 接口调用token
三、平台实现方案（这里只描述现已知的技术难点）
1、原生端（无特指的话均为ios和安卓）
① 走 web 资源下载的方式，类似cordova的形式，然后做文件管理，不同的微应用定向到不同的文件夹。
② 提供sdk相对应的原生函数方法。
③ 提供alita需要的环境，比如在全局变量中有 react 等基本库。
④ 提供开发调试的环境，未上架之前如何调试原生能力
2、web端
① 编译时抽离一些基本库，只打包业务需要的代码。基本剥离了所有的第三方库
② 提供 sdk 的对接文件
③ 提供开发调试环境，未在原生场景时，调用原生方法应给出正确的说明等
④ 编译产物是否需要加密，涉及到原生端下载web资源的方式
3、服务端
① OAuth2.0 认证
② 大数据分析
③ 数据统计
4、后台管理端
① 数据统计报表
② 数据分析平台
③ 基本的功能对应《平台接入流程》
总结
其实上面的方案，在很多游戏分发平台上都有过类似的实践。实现难度不是很大。但是我觉得最大的难点，也是方案最大的亮点，通俗的讲就是提供一个 umi 项目的运行时环境，比如将 umijs/plugin-react 这个插件集，所需要的第三方库，都打包到浏览器中。项目中仅仅需要打包的就是那么一点点业务文件。加上 gzip 压缩的话，一个产物包的大小可能仅仅只有100kb。这样一个环境可以在app内静默加载或者预加载，而在打开微应用或者切换微应用的时候，仅仅需要从远程更新 100kb 的 web 资源文件。
（以上言论仅仅只是一个设想，各位大佬请多多指教）
