“Guide to app architecture” 的学习笔记

这是一篇我学习谷歌技术博客后作的总结，它介绍了通用的应用架构原则和在移动设备上，可供参考的工程架构的最佳实践。

项目架构中常见两个的设计原则：

模块分离

在项目架构设计中，模块分离原则是最要的，指根据单一的职责，把不同的功能模块用对应的代码封装起来。这样做的好处是，在定义好接口和实现其功能后，后续修改时，不需要知道具体实现细节，修改和改进当前模块的代码，并且不会对其他模块造成其他影响。

安卓中的activity、fragment是基本的UI组件，这些只会有一些元素的交互和与操作系统交互，当app因系统资源问题回收时，对应的ui视图会改变，但是我们的数据模块则不应该受到影响。除了UI模块，是安卓系统替我们维护外，其他的模块，应该以最小的单位去封装，这样具有明确边界的模块化代码才能让app更加容易维护和测试。

模型驱动视图

我们用Model来驱动视图，且优先使用持久化模型，系统中模型是用来处理数据的，同时它独立于UI和系统其他组件，它不受系统UI生命周期和其他模块的改变影响。
持久化的Model的有两个理由：
1.app会随系统内存不足被销毁，持久化Model可以防止数据的丢失。
2.网络的不稳定，我们需要持久化的model来加载缓存

当今，我们有很多项目架构去解决那些问题，具体采用哪种形式，这不是强制的。但是它们有下面几个共同的特点：

1. Persist data

数据从网络获取来的，我们需要持久化到本地。使用它们时，优先加载有效缓存，这样能提高数据显示到屏幕上的速度。同时有部分用户不是很喜欢用网络数据。

2. Well-defined boundary for each module

每个模块的边界需要定义清晰，让其各负其责。 模块大致分成视图层、ViewModel层、数据业务层。在模块搭建方面，我们可以用Dagger2框架，分单列或者注入的方式来初始对象，用依赖把模块都组合起来。在测试方面，可以Mock模块对象，如我们可以只mock数据业务层，用本地的测试数据模拟网络数据，不用修改ViewModel层的代码。

3. Single source of truth

有些数据来自不同的服务器地址，在他们更新的时候，因为网络关系会产生结构一致但内容不一样的数据。我们需要把这些来自不同服务器的数据保存到同一个地方，之后获取这些数据的时候，能确保它们的一致性。

4. A little function expose from each module

不要因为只有几行代码, 就随意在某个模块中加入，或者就把模块的某个接口实现暴漏出来，随着项目的增大，这些代码就会变成技术债，后续维护项目时偿还。

以上就是我的总结。

点击这里，可在我的个人博客上查看此篇文章。