PK条是包含了业务逻辑的组件，用于显示多人之间的pk进度，主要用到PC客户端的内嵌页面web项目和移动端APP的内嵌页面web项目中。所以，我们要解决的是，pc web项目和移动端web项目之间如何共享这个组件资源。
有三种方案，一种是简单的复制粘贴，我们就不考虑了。第二种是npm包方式，如果使用的话，需要维护一个UI库，基于前面说到的npm包方式的痛点，也句不采用了。第三种就是我们说的EMP微前端方案。
使用EMP微前端改造的前后对比，可以将PK条这一业务逻辑组件放在远程组件基站维护，然后暴露出来，供应用项目使用。这是最终实现的产品效果图，PC web项目引入该资源组件，可以传参数自定化和修改样式。
后面的维护，只要在远程基站中，更新迭代PK条组件的功能，就可以同步远程桌面更新到这些应用项目中，提升了更新速度，维护起来也比较方便。
cocosd游戏项目
目前cocos2d游戏最主要的开发方式是通过官方提供的GUI图形界面工具——creator，通过 creator 开发者无需关注构建本身，只需通过界面操作即可对游戏代码进行构建打包。但是这样也存在着以下几个问题：
构建闭源，导致开发者对项目构建无法定制化，假如编译出来的代码存在兼容性问题，那只能进入 creator 安装目录寻找对应的某个配置文件进行修改，这种侵入性的修改很有可能会引发不稳定性。 无法使用其他构建工具进行打包，意味着项目无法使用新的技术方案，只能局限于 creator 设定的框架之中 游戏组件在不同项目之间难以复用，组件通常包含了 prefab、sprite 等资源，如何发布托管并在其他项目复用组件，简单地通过 creator 是无法做到的。 发版流程繁琐，因为开发多个cocos2d游戏可能会复用一些资源，如果使用npm包方式抽离的话，发布流程会比较麻烦。
第一段，改造现有项目为EMP微前端。开始改造新频道模板的时候，用create-react-app搭建了一个普通项目进行开发和部署。但后面要继续接新模板的时候，想要每个模板都抽离成一个个独立部署的应用，方便专门的人维护（一个模板的逻辑很复杂很多，可以抽离成一个项目了）。于是，这时候对新频道模板的项目进行了微前端改造，花了半天的时间。
第二段，用emp脚手架新建应用项目。在改造了新频道模板的项目为微前端后，我们将需要用到的功能资源，全部都整和到了基站管理，然后emp init项目之后，可以直接使用基站资源，起一个新项目很是迅速。
第三段，一键更新多个项目，同时维护多个项目。后面，有越来越多的模板改造成一个个不同的应用项目，这时候就体验到一键更新的好处了。如果多个模板的应用项目使用的共享资源需要更新，只需要更新基站，就可以很好达到我们的目的了。
联系客服
