苍耳的博客

细水长流

0%

Android架构学习之路一-漫谈

发表于 更新于 分类于 ， 阅读次数： Valine：

架构是什么

架构学习之路系列

这是架构学习系列的第一篇，随便讲几句。对于架构，我也有些一知半解，读了一些架构相关的文章，结合实际项目经历，有了自己的一些理解。

关于架构是什么？这点可以顾名思义去看，架构=架+构，即整体的一个架子和各个组件之间的组合结构。当然可能不同的程序员对于项目架构的风格和习惯不一样，但是底层的思想应该都是类似的，诸如我们可能听到起了茧子的“关注点分离”，“低耦合高内聚”，“可扩展可复用易维护”等等，听完这些话，感觉自己懂了，又感觉啥也不懂，好像有所收获了，准备开始写代码的时候，脑子里想的可能又是“工期太赶了，就这样写吧，反正干完这几票就跑路了”。

架构离我们并不远，反而在我们的实际开发中无处不在，它是一个很笼统的概念，上至框架选型，组件化等，下至业务代码，设计模式都能称为架构的一部分。对于架构学习而言，我觉得首先得对面向对象(抽象，继承，多态等)及设计原则有一定的理解，进而结合 Android 常用的一些架构如 MVVM, MVP, MVI 等思想，基础与理论理解清楚了，架构就在日常的开发中，多思考，多结合理论与实际，一点一点地积累起来了。

一起吐槽

我想每个程序员在写代码的时候可能都有这些历程(夸张)：

  1. 这坨代码谁写的，怎么要这样写啊，我这个需求该怎么加代码！
  2. (尝试在shit山上小心地走，并添加新代码)写的好难受，shit越改越chou了…
  3. 算了，爷来重构一下，结束掉一切吧！
  4. 重构的一天：我曰，这个地方怎么埋了个雷，我来排一下；哇，怎么这里还有奇怪的逻辑，哼哧哼哧问了之前的同事说是PM改的需求；哎，爱咋地咋地。
  5. Several days later -> git revert -> 下班
  6. 在原来的shit山上再拉一坨，OK，很稳定，提测。

新员工整天都想着重构，而经验丰富的老人早就知道能不动别人的代码就不动的(doge)，shit都是互相的，你来我往才能生生不息。写代码嘛，就讲究一个礼尚往来~

背后的原因

吐槽不是针对某个人，这种现象其实也挺正常的，因为技术在发展和迭代，业务也在丰富和重构，所以在当时看起来，这块代码是很优秀的，只不过由于一步一步的发展，以及一些历史包袱(PM: ??)，慢慢的原先的架构可能就跟不上业务需求了，毕竟，架构不是一成不变的，业务在发展，技术在迭代，熵增很正常。到了一定的地步，评估好成本和收入，老老实实提需求重构吧。

当然，虽说随着业务的发展，熵增是必然情况，但是也得注意自己的代码质量呀，毕竟大家应该都不想被后面的同事接手的时候偷偷吐槽你的shit太chou了吧，除非真的抱着干完这一票就溜溜球的想法(doge)。

简而言之原因可以分为两种：

  • 产品的发展，技术的更新迭代
  • 每个人的代码习惯可能不一样，比较参差

怎么做

学好面向对象

听说即使是许多年的老 Java 人，可能在开发中也不怎么注意面向对象的思想，我也经常疏忽这点，啊不对，我不算老 Java 人(囧)。

关于面向对象和面向过程的区别，网上很多介绍的，随便抄了一份：

  • 面向对象：面向对象是一种风格，会以类作为代码的基本单位，通过对象访问，并拥有 封装、继承、抽象、多态 四种特性作为基石，可让其更为智能。
  • 面向过程：分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了，更侧重于功能的设计。

在开始做需求的时候，先别急着写代码，思考一下这个需求的本质是干嘛，用面向对象的思想去抽象这个过程，不是直接搞几个类就可以了的。

举个栗子，之前在老东家的时候做过后台启动的需求，当时的情况是这样子的：针对不同的 Android 版本，可能有一种或者多种不同的启动方式，需要挨个尝试。直截了当的方式是 if else 从头到尾一路火花带闪电，但是觉得这样子肯定是比较难以维护的，所以就把每种启动方式都抽象成了一个 Starter 类:

1
2
3
4
5
6
7
abstract class Starter {
    // 做后台启动的事情
    abstract fun handle(context: Context, intent: Intent)

    // 是否满足特定Android版本和业务场景等
    abstract fun satisfy(): Boolean
}

然后把这些启动方式串起来，通过类似责任链的设计模式去工作，具体代码不贴了，有兴趣可以看看之前的文章: 实战|Android后台启动Activity实践之路。可能现在看当时的代码，会觉得有些稚嫩，但程序员不就是得一直进步的嘛~

接着就是那些常用的面向对象设计模式了，讲道理这些设计模式是很有用的，另外还有面向对象的六大设计原则，这些网上应该很多很多的文章都会讲。

设计架构

前面已经提过随着技术和业务的发展，架构也在一步一步迭代，比如说一开始的单体架构，把用户界面，业务逻辑，数据管理都糅合到一起，到后面根据业务和技术拆分结构，如 MVC, MVP, MVVM, MVI 这些，以及模块化和组件化，服务注册和发现等等，另外还有比较复杂的 Clean 架构，Android 版的 Redux 架构之类的等等。多的一批，哎，好卷。

有时候会产生疑问，这么多新的东西冒出来到底是技术必需的迭代还是由于 OKR, KPI 太卷了(doge)。但能怎么着哦，还是得哼哧哼哧学习。这些文章计划在后面慢慢整理，就当给我年初补充的flag 两年半，加油Android|2021年终总结 吧！

不过架构再多，也都是为业务服务的，没有什么完美的架构，适合当前需求的才是最好的。

写在最后

写代码的时候，记得三思而后行，想一想你写的代码是不是在它该在的位置，是不是以该有的形式存在的。

架构不是一蹴而就的，希望我们有一天的时候，能够从自己写的代码中找到架构的成就感，而不是干几票就跑路的想法，这个系列应该会一直更新，记录我在架构之路上学习的脚印儿，一件一件扒开架构神秘的面纱。