我们在处理用户表的时候，除了抽象基础用户信息时，有可能还需要一层业务公共层，以我们公司为例，多数用户是医生，所以像职称、所属医院这种信息会经常被用到，这个时候就会出现直接使用这种业务公共表的情况：
子系统A与子系统B都是使用的与子系统C一样的用户id，但是他们直接依赖了公共业务关联，他们在公共业务中获取了类似科室、职称等信息，如果这个体系再扩展的话，会是这样的：
体系化的第二步是H5整合Server服务，当公共的服务出现后，这里便需要提供公共的H5页面，这里会遇到一个难题需要突破：
① 各个业务有自己的定制，比如注册时候要求的字段都不一样
② UI会成为第一个拦路虎需要你去说服
既然是公共页面，就需要满足一些业务的定制需求，当底层框架完善并且统一后，便可以以规范的力量给予业务开发以指导与限制了，只有将公共业务做好后，才能真正提高我们整体的开发效率
第一个问题是业务受限，那就说明公共服务做的不行，不具有通用性，那就改设计，改到满足就行了
第二个问题，肯定是在我们已经有公共服务的情况下，告诉UI，我们这个是公共服务，是不能乱改的，设计要中性化
要整个公司的人都形成公共服务，以及重用，效率的思维后，大家才会认可这个，在人家不知道或者不认可的情况下，说那么多也没用，知行合一才是王道。
一个较为合理的公共页面可能是这个样子的：
所以，后期我们的系统就变成了这个样子了：
当我们这套体系走的足够远后，我们整个系统可能就是这样的了：
体系化第三步是整合H5与Native资源，这里也是所谓的Hybrid体系，只有在前两步完成后，才能很好的完成这一步，否则就只能称为内嵌页，不能叫Hybrid，更不能说是什么移动体系化。
整合Native与H5的第一步仍旧是账号打通，一般来说，我们强制要求native中H5只能使用native提供的统一页面进行登录，不管这个页面是native的还是H5的。
事实上，我们H5端就登录一块做了三套页面一个弹窗，一套账号登录（废弃）、一套手机号登录、一套手机号登录并且带第三方登录，还有在页面里面直接弹出的登录框，一个个APP中是不应该允许存在两个退出账号或者有个人信息的地方。
设想，如果H5具有自己的登录，那么整个情况会变得极其复杂，首先APP具有一套自己的登录，而H5如果与APP登录了不同的账号，那么就会存在用户串了的情况，当然，APP可以监控H5的登录态变化，但这个东西技术实现成本比较高，并且容易出错，所以我们这边要求所有H5的登录全部走Native的一套体系，每次Native打开webview时，如果有cookie就注入webview，这样前端就自己有登录态了 一旦当app注销账户，之前所有的页面也将全部弹出掉，新开一局，如此一来账号体系已经打通。
当做到H5与Native账号打通后，我们便可以实行我们的Hybrid化进程了，这里简单以Header为例。
主流Hybrid都是使用的Native的Header，原因有很多：
① 稳定，防假死
我们料不到前端会出什么错，特别是第三方网站，一旦前端出错如果iOS连个退出的按钮都没有，那么就app假死了，这个比crash还讨厌
② 体验
我们在刚打开一个H5页面时，可能会有白屏，如果header也不在的话，体验会比较差
而我们在设计Header交互时候，需要考虑到前端的使用习惯，最好能保持业务代码一致，处于不同宿主容器表现不同，这里的设计是左中右的设计，图中就是我们能提供的所有header样式了，不够也没办法咯。
完了我们需要对tagname定制化，header中的所有按钮的唯一标识为tagname，所以tagname不得重复，其次常用tagname会有一个默认图标，需要定制化的话，就读取线上资源。
相关文章
精彩导读
热门资讯
关注我们
