前言

2022年09月。从21年入职薯片以来，不知不觉以及过了一年多了，成都9月新冠严重了，于是在家静默，等待复工，突然就想着不如把薯片学习到的东西整理一下，就当写写日记了。从薯片还是学到了蛮多的东西，从业务上的整体架构再到Android的架构思路及其一些细节，都值得仔细的思考。

正文

话说，架构是提供解决方案，这以架构命名，应该不至于被骂吧。毕竟是抄架构大佬的。

业务架构

话说，我一个Android写这个肯定是不全面和准确的，只能说描述一些自己看到的。

后端中台

薯片这边的服务器应该是分布式+服务器缓存表(这个调调好像经常换来着，数据老是同步贼慢)，同时基于业务功能，将业务分为以下几个已知中台（内容中台，订单中台等等，中台蛮多的），单纯从内容中台上讲，内容中台提供原始运营内容的审核发布，同时APP导航，版本号，数据字典，广告物料等等。

APP 或者wap 亦或者小程序都无法直接调用中台接口，中台接口只是提供标准服务(增删改查)和中台的管理界面，给前端提供的数据交互的是中台中间层，中间层之前有Node和JAVA，目前全部换成了JAVA，中间层作为桥梁处理前端的业务、版本适配、请求过滤等等功能。我感觉验签就是在中间层完成校验的，只是我没有证据。最近加了一层，大数据的大佬们终于有数据可以计算提供内容了，于是中间层调用了大数据中台，大数据基于内容中台提供过来的数据及其用户特征返回分析过的数据(嗯)。

这种中台模式是我工作这么久，搭建最好的一种模式，业务的分离和安全都有。不方便的地方也有，中间层不参与中台功能的设计，导致中间层和我们对的业务字段可能要换成中台提供的，有的时候整到一半才发现中台不支持这种业务，然后再把中台拉上迭代，到后面需求评审的时候，有没有中间层都没有多少意义直接拉中台过来，感觉中间层作用被削弱了。逻辑上不应该这样，这就导致了中间层做版本适配超级难，版本升级就新开一个接口，中台一旦迭代了老接口就用不了(加一个字段也用不了就过分了)，解决方式就是老数据导入到新表（好像也没有啥问题，但是这个怎么和Android不一样？他们好像没有数据库版本升级的说法与操作）。

app 架构

这也只能描述Android的了。

mvvm

从薯片的业务上而已，薯片APP的功能大多数都是信息展示，流程上的问题也都是通过数据展示然后用户操作进行处理。所以这种模式天然就是适合mvvm,viewModel+LiveData 这种带生命周期的数据回调，可以减少太多的生命周期问题。同时viewModel 提供的activity生命周期及其销毁能力，使得他可以较好的完成activity与fragment之间的数据共享，这种共享及其方便，同时也较为契合组件化思路。同时也减少了那种用得很少的业务单例（别问，问就是写过）

组件化

采用的解决方案是ARouter,因为APP是单进程也无需考虑跨进程通信。同时ARouter 提供的路由跳转能力可以较为切合内容中台中的导航配置，ARouter 提供了路由、拦截、降级、外部服务等基础能力，可以解决很多问题。

这会导致所有APP组件都必须依赖一个共同的common lib ,所以common中的内容是否是必须的，就得慎重考虑了，当然了，不组件化也有一个架构上的base,感觉没有多少区别，就是换一个名字，但是还是建议common 才有git 的子模块(嗯嗯，老实说，对于架构组把common 子模块换成module怨念很大，毕竟是整体决策)。ARouter 的服务接口、基础颜色、基础图片、网络请求、图片渲染、拦截器、base 等都可以丢common中。

组件化的好处蛮多的，按照功能需求初始化，启动速度加快，代码更加清晰，允许界面配置，结合子模块工程可以独立运行调试、基于提供的服务对接更加简单等等。

wap

每个APP都有自己的H5 界面，这个好像是通用的解决方案了，同时H5界面与原生的交互等也需要统一的方式。采用bridge webview。当然了还有一些webview的优化，就不详细描述了。

mpaas 小程序

可能在考虑到热修复的问题，所以目前的功能上的解决方案就是mpaas 小程序，这个调调好与不好用了自己体会吧。mpaas 采用webview 渲染界面，但是体验相对于wap 而已好一些，同时提供了很多功能。

网络请求及其数据缓存

网络请求是Retrofit，图片加载是glide，图片云是cos和oss,同时本地提供工具类按照显示大小设置图片大小。存储方案是mmkv,sqlite。

结束

其实通篇都是口水账，有很多细节也没有处理。先这样吧，主要是对于薯片整体的一个大致架构进行简单描述，如同备份一个，对于后期还是有很多借鉴意义的。

但愿早点复工，成都加油。