2B模式下APP定制架构要思考的问题—多角色联合体巨应用解耦

引子：在客户交流的时候，他提出APP应用做一个就可以了，理由很简单，一个用户有多种角色，你若是为每一个角色都做一个APP，那登录使用岂不是要多次的切换。

从当前时期APP架构技术来看，分不同角色架构设计不同的APP是主流，这样的架构方式主要能带来这样的一些好处：

（1）交互设计问题 不同角色所做的事情是不同的，基于用户体验感知来看，应该为不同的角色进行不同的交互设计。比如“滴滴”APP就区分了乘客版本和司机版本，“饿了么”APP也区分了大众订餐版和商家版。但凡事情都有个尺度，角色颗粒度的划分也是如此，我所理解的不同角色，指的是不同角色种类，他们大部分使用情况下，是不会重叠的。就像滴滴的司机和乘客，司机自己开着车拉着活还能抽空来打个车？但在2B领域，有些人既是一线操作者，也负责调度排班，又还身兼了一个团队管理者，那么我们在角色架构分析的时候，就需要把这三者整合成一类角色。

（2）使用升级问题 巨体应用带来的就是对单个用户来说，过于频繁的升级。其中针对某些功能的升级，即使你不使用到这些功能，面对这新版本的功能介绍，似乎也不能完全明了，大部分时候都选择了继续升级。巨体应用最显著的特征就是FILE SIZE巨大，即使在4G和百兆光宽的环境里，动辄100M的应用也让人生畏，莫是在下载游戏吗。

（3）开发绑定问题 巨体应用无疑是由单个乙方开发的，当甲方需要更换乙方的时候，其要考虑的内容就比较多了，项目的影响面更大、干系人更多、项目复杂度更高、工期更长、投资更大。

回到客户最初的问题上，之所以想做一个单体巨应用，无疑是为了推广运营方便，特别是三四类角色的时候，不需要频繁跟每个人去说你该下载哪个APP去使用。这种需求场景下，我们可以考虑使用下面的模式

这其实是一种弱耦合的组合模式,前端轻量化模式，用户属于哪类角色由WEB端应用根据员工ID来判断，给出下载APP链接。当用户有新的角色变化（主要是新增）后，可以在原有APP上看到新功能的链接，由原APP直接打开新APP进行自动登录，期间可能需要延迟下载并加载新应用（一次性）。

对客户来说，在运维上并不需要花精力去通知终端用户去切换APP，同时也彻底分割巨体应用，特别还避免多个单体应用组合打包所带来的诸如兼容性差、使用问题定位难、升级代价高的问题。