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项目之后,可以直接使用基站资源,起一个新项目很是迅速。
第三段,一键更新多个项目,同时维护多个项目。后面,有越来越多的模板改造成一个个不同的应用项目,这时候就体验到一键更新的好处了。如果多个模板的应用项目使用的共享资源需要更新,只需要更新基站,就可以很好达到我们的目的了。
联系客服