回顾青训营「客户端架构设计及应用」
这是我参与「第四届青训营 」笔记创作活动的的第4天
项目背景
首先对上课的图简单仿照的画了一个示意图，产品和架构的生命周期
很”有幸”在这次的项目中体验到了这一个过程，在项目启动时临危受命担任了小队长，负责框架的搭建。对于刚开始学Android的我来说，要自己搭建一套框架无疑是有难度的，所以决定先借鉴开源框架进行学习。
根据我们的需求文档是开发一个极简抖音，包括电影页、个人页面；要求使用MVVM框架进行开发。
基础概念
了解MVVM框架以及一些基础工具。
MVVM：
它是Model-View-ViewModel的简写，主要的逻辑就是将View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。
和我们平时的简单UI，他能给我们带来什么好处呢？
1. 低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的"View"上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
2. 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
3. 独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用Expression Blend可以很容易设计界面并生成xaml代码。
4. 可测试。界面素来是比较难于测试的，测试可以针对ViewModel来写。
抽象化了之后又有什么缺点呢？MVVM的创造者John Gossman本人他指出
1. 复杂化。 实现MVVM的开销对于简单的UI操作是“过度的”。
2. 推广难。对于更大的应用来说，推广ViewModel变得更加困难。而且，他说明了非常大的应用程序中的数据绑定会导致相当大的内存消耗。
多框架对比：
（来源字节青训营,侵删）
思考：为什么本项目要选择MVVM呢？
基于本次的需求开始分析，抖音电影，综艺，剧集榜单，抖音个人页。
虽然说从表面上理解就一个功能块，但是他包含了电影信息，个人的发布的视频，点赞的视频，关注的列表，粉丝列表，个人的一些信息。
虽然功能点多，但是是单个业务，符合我们的MVVM小应用的规则
然后在看常用的MVC， 如电影页面，我们的一些功能是可以复用的，但是MVC中用的是controller来控制，大部分的代码集中在了Activitty/Fragment页面中，如果我们想抽离出来，无疑是一个大工程。
但是在MVVM中，我们就可以通过复用viewmodel层进行修改
借用课上的一段话
越来越复杂是客观规律，表现在：理解成本变高和预测难度变大。
认识到这个规律，我们就不要幻想简单架构来解决复杂问题，架构要做的是简约而不是简单， 通过简单明了的约束来保障一致性，让大家好理解，好维护。
宏大的规模是不好理解的，譬如：在城市路网中容易迷路，但在乡村中就那么几条道
复杂的结构是不好理解的，譬如：一个钟表要比一条内裤难以理解
那怎么去区分呢，接下来让我们跟着产品图一步一步开始吧！
一、孕育期—快速组织关系
本阶段，我们用抖音电影榜单来锻炼
分析页面
用以前从Flutter学的老经验：从上到下，从左到右
从上到可以分为三层appbar -> tab -> viewpager
逐层进行从左到右
appbar ：背景、工具栏、文字
tab：设置Item子项目
viewpager：榜单选择->可滚动的列表-> 图片 ->电影信息 ->按钮
实践：
我们可以使用简单的andorid ui布局实现以上操作。这里不做展示
二、婴儿期—分而治之
我们来到了第二个页面抖音综艺榜单
分析
本页面又和抖音电影榜单有相似的也有不同的，如上半部分的appbar的背景和工具栏是相同的，但是文字不同。
下半部分，没有切换的tab只是单页面，然后展示的信息又有一些不同。
思考：相同的页面我们如何进行复用减少一点代码呢？
这时候就需要我们逐步有架构的基础概念了，对不同的业务进行拆分，代码进行封装抽象。
如顶部的appbar进行封装使用，展示的图片进行封装等等
三、学步期—分层架构
分析
页面设计完成了之后，我们就可以进行数据的写入，如网络请求，本次存储等等的设计，大家各自都想抽象出自己的代码。
如我们的榜单的列表滚动图片的缓存，数据的缓存，榜单时间的缓存，之间如何设计，形成一个约定。
思考：随着我们不断的抽象，中间层就会越来越多，代码越来越冗余，灵活性降低。怎么解决呢？
四、青春期—设立业务之间的接口契约
分析
上一层我们不同业务和模块混合，需要解耦。
我们就可以使用服务化架构：
首先，需要约定模块可以对外提供的能力
接着，模块之间需要遵循相同的调用方式
然后，旧的模块需要按照相同标准来改造
继续，使用方不应该直接依赖于实现方
……
解决思路
这样我们就可以分出不同的服务层级，如网络层、数据层、业务层、逻辑层等等。这样我们的一个基础的业务就基本上完成了。
五、壮年期—业务变得更加灵活
分析
随着新业务的发展，这时候我们来到了第二个功能—抖音个人页，这时候就面临的一个问题：这两个业务之间的Token是相互独立的，让业务变得更加内聚，需要灵活插拔。
解决思路
这时候就可以使用我们的微内核架构来实现配套插件注册和发现机制，业务动态发布。
六、稳定期—战略优化
分析：
随着我们的APP逐渐趋于稳定，产品不断迭代，历史包袱沉重，新技术的发展，我们怎么对产品进行兼容发展呢？
解决思路：
课上提出领取驱动开发，由专业的认识对问题进行展开分析解决
常用的架构手段有：微服务架构
微服务：Service Component，一个高度内聚的模块集合，对外暴露服务接口。每一个微服务都是独立的，分 别向服务注册中心注册自身所能提供的服务接口。
优点
1、健壮性好，单个服务不影响全局
2、服务隔离，服务之间互不相耦合
缺点
1、容器出现服务数量腹胀难以管控
2、服务发现和通信需要额外的成本
七、贵族期—对抗架构衰老，从我做起
分析
产品不可能一直处于稳定期，肯定会遇到产品瓶颈期如
这个业务要打磨一下用到其他业务->推到重来吧->打嘴炮的吧，根本消费不了->哪哪都是坑
解决思路
保持情怀，勇于行动，仔细实践
如以下思维的转换
这个组件不迭代了，不用改了吧 》 这个组件的API不合理，其他App很难用，得改
这一坨陈年无用代码反正也不影响功能 》 这对其他App就是累赘，必须删掉
这个逻辑有点多，改起来容易错，还是新搞一个吧 》 通用逻辑，还是好好重构统一吧
这个着急合码，先这样吧，后面再改 》 不行啊，此时不改，祸害好几方
小问题来着，就头条有，先观察一下 》 不仅仅影响到局部了，得谨慎分析一下
八、官僚期
分析
人们相互甩锅，大家都不想改代码，虽然大家都不想进入这个时期，但是这是一个客观的规律
解决思路
保持好心态，积极面对。
总结与体会
在经过几个项目的之后，很多时候项目开始大家都是满怀激情，从孕育期努力到了学步期就极限拐弯到了消亡期，很多小项目是存在这样的问题，但是我们应该保持好一个积极的心态，在前期的时候利用一些手段让我们的情怀保持。
下面说一下在项目中我是如何去保持的，
首先：如果在小组内可以选择一些能力较强的同学作为目标，观察他平时是如何工作的，从中学习一些经验。
其次：我们自身应该保持一个积极的心态，脚踏实地的工作，切忌浮躁，在哪一个时期就完成哪一个时期的事情，不要想着一口吃成一个胖子。
最后：善于沟通，因为工作是一个团体项目，埋头苦干虽然也有一些成效，但是与他人沟通的过程中可以减轻我们的压力又可以减少一些不必担心的麻烦，或许还可以收获到一些不错的效果。
阳光总在风雨后，同学们一起加油！
参考文章
阿里大牛：选择大于努力，所以MVC、MVP、MVVM，我到底该怎么选？
萌新初学，本文为笔记，大佬若有更好的方案欢迎评论区留言
