若一开始代码架构不清晰，就是前人挖坑，后面所有人掉坑里

以下我摘录自Android架构指南的一段话，翻译的不太好，见谅

Common problems faced by app developers

原文链接: https://developer.android.google.cn/jetpack/docs/guide

APP应用开发这面临的常见问题

Unlike their traditional desktop counterparts which, in the majority of cases, have a single entry point from the launcher shortcut and run as a single monolithic process, Android apps have a much more complex structure. A typical Android app is constructed out of multiple app components, including activities, fragments, services, content providers and broadcast receivers.

不像传统电脑桌面应用开发的那样在大多数情况下从应用启动开始有一个单一的入口作为单一的整体的进程。Android app有更加复杂的架构。一个传统的Android应用构建在很多的app组件，如activities, fragments, services, content providers and broadcast receivers上面。

Most of these app components are declared in the app manifest which is used by the Android OS to decide how to integrate your app into the overall user experience with their devices. While, as mentioned earlier, a desktop app is traditionally running as a monolithic process, a properly written Android app needs to be much more flexible as the user weaves their way through the different apps on their device, constantly switching flows and tasks.

大多数的APP组件都声明在app的mainfest中用来被android系统使用以决定如何的把APP集成到用户的设备中。然而，在这之前，一个桌面app是按传统的模式运行在一完整的进程中。一种最合适的android app的做法需要更加灵活的穿梭在不通的应用之间以方便用户在他们的设备上使用来不断切换流程和操作。

翻译结束。

最新在看一Android代码，深感项目结构的重要性。若代码架构不清晰，是在一个人挖坑其他人掉坑里。本来精力应该花在业务和功能上，结果呢，不少时间浪费在理清混乱的代码结构和处理bug上。就好比在混沌的一锅粥里不知如何加料。

随着代码和业务的增长，想重构已经没了精力，想继续维护吧，前人留下的坑让后人也花不少精力。最终会导致进退两难的境地。

看到的是 全局变量常量一大堆，到处都是，

从工程代码结构上，也看不出结构。各种工具类这放点儿那放点儿，想到哪就把代码加到哪，随心所欲。

我觉得，针对Android项目，首先大体上确定是MVVM还是MVP，然后，

有一种按功能模块划分的意识。

拿一POS机来说，分 存储模块，显示模块，通信模块，读卡模块和框架逻辑。

如果这几块都有的话，实现一功能是多么的简单清晰。

针对一个项目，

1.全局用到的变量，常量，应该放到一个地方去维护。

2.对需要保存的参数，应分类存储。而不是混沌的一锅粥，到处的SharedPreferencesHelper去存储，想到哪用到哪。

3.对需要保存的参数，留出来接口，用到时直接 赋完值调用save()。

4.存储是一大项，存储不是调用原生的增删改查就完了，也要设计为接口。保存记录时，只需save().读取时只需read()

5.通信模块，要考虑到通信通道可能会变，比如http,tcp,串口。也要留出清晰的接口。

6.各个功能模块，尽量做到高内聚，低耦合。最大限度的复用。

7.用到的各种工具类，放在一个文件夹下统一管理。