如何写出一份“有理有据使人信服”的Android项目设计文档

是的，虽然咱不是写论文，但是肯定多多少少有引用到一些文章，技术博客，哪怕是第三方类库的官方简介，也都要放在文末，以供其他组员参考。同时这也是一个霸气的结尾,"老子调研的这么辛苦这么尽责，看了这么多文献，你好意思反对么?",此时无声胜有声。。。。。

有时候，对于同一个项目，同一个功能，还有其他的第三方类库或者结构可用，那么最好也要列举出来，同时比如各自的优劣势，这是给你选用的架构的很好的背书。这里就不列举例子了。这个环节也可以参考之前讲过的架构描述方法。

android小项目设计

开发项目日期正式发版10/01/2020Beta bug修复09/24/2020Beta QA09/10/2020Beta 发布08/27/2020Code Freeze08/26/2020开发07/26/2020设计/文档07/15/2020技术选型调研07/01/2020

比如，我要2020年10月一号正式发版，那么假设我们Beta内测需要两个周，Beta bug修复一个周，QA测试内测版release两个周回乡创业的农村老人多吗，那么我们开发的Code Freeze日期就定下来，大概是八月26号左右。有了Code Freeze日期，设计，开发周期就有了：

通过上面这个对比图，阅读者可以很清晰的看到，在现有的设计中，我们完全没有修改Adapter和View之间的通信方式和流程顺序，仅仅是修改了Adapter和数据源的操作，从原来的Adapter修改本地数据库和发送网络请求两手一把抓，变成了现在仅需向Amplify SDK修改模型Model数据。

假如我们的产品是一款点餐的软件，我们的Model(数据模型)是一道一道的菜，同时菜本身可以修改相应的元数据，比如辣的程度，是否加入了配菜等等。每当我们把菜加入到购物车的时候，不同设备同一账号的软件的购物车应该出现相同的菜品。

这些都是文档阅读者在阅读完你写的简明易懂的架构简介之后会问的问题，是一个顺其自然的事情，当他们问到这里的时候，你应该感到高兴而不是紧张害怕，因为这说明大家把你的文档读进去了，而不是敷衍和不耐烦。能让阅读者和作者产生互动的技术文档，是好文档！

Amplify Android SDK的Engine组件通过Observer模式，注册了一个数据源变化的观察者，如果有新的Mutation，Engine就会从Mutation数据库将Mutation取出并发送到API组件，API组件再将其封装成一个GraphQL的Mutation 请求发送至后端

安卓APP源码和设计报告——Android小程序超级小猫

Berak；}语句对页面进行的切换控制。根据各个页面时时反馈的CanvasIndex值确定跳入哪一个页面。CanvasIndex值设置为0、5、10、15、20、25、30、35、40分别代表帮助页面 、logo页面、主页面、加载页面、主程序页面、结束页面、第二关切换页面、第二关加载页面、第二关主页面。用switch控制能简单有效的切换到下一个页面而退出上一个页面。

在本程序中对主人公的跳跃，死亡，点击主菜单按钮都加入了音效，此外游戏中还有背景音乐。这个功能的实现用了Android中的SoundPool和MediaPlayer，前者控制音效，后者控制背景音乐。部分代码如下：

由图3.3表示，主人公与障碍物的碰撞，当在范围①时，表示在障碍物上面，可以站在上面进行跳的动作，否则就是在空中，进行下降的动作。当跳到④的范围时，表示玩家与障碍物碰撞，障碍物执行自己的方法（消失或者变化），玩家自由下落。主人公与敌人的碰撞中，当主人公在范围①—④时出于碰撞的临界点，碰撞后玩家和敌人执行自己的方法（死亡图片或者爆炸消失）。敌人与主人公的碰撞与主人公与障碍物的碰撞类似，道具与主人公的碰撞与主人公与敌人碰撞类似。

游戏的核心重点在于碰撞检测方法的编写，即使绘图再美，玩家控制的再好，到了不该过去的地方照样过去，失去了游戏的规则。碰撞检测包括，游戏主人公与敌人的碰撞、主人公与障碍物的碰撞、敌人与障碍物的碰撞、道具与主人公的碰撞

游戏的控制分为系统控制和玩家控制，由系统控制的只需设置其相应的方法，在需要的时候执行相应的线程。由玩家控制的主要是对主人公的移动控制，在编写代码的过程中，左、右移动相对简单，让它跳起来一度用了不少时间学习，对跳跃加入重力引擎方法 成功解决了实现跳跃高度一定，速度变化，有真实感的跳跃动作。

为了游戏美观和地图设计的方便，要把图片处理成跟屏幕分辨率宽高都成比例，借助Batch Image Resizer和PS图片处理工具分别对游戏素材进行缩放和去除图片背景的操作。游戏中的主人公是位图播放，Android中提供给我们播放帧动画的方法。在绘图中，Android中的绘图类SurfaceView，默认采用双缓冲技术，保证了屏幕不出现闪烁现象。

该模块实现了公共图片金币的动画效果、游戏主人公死亡后显示图片效果、碰到毒蘑菇显示图片效果、杀死敌人后敌人消失效果、碰撞普通砖块后的爆炸效果、碰撞问号砖块后弹出金币效果。主要由TX、TX1、TX2、TX3、TX4、TX5、TXManager几个类分别实现。

该模块实现了游戏地图信息的保存，增加了游戏的扩展性。由map类和TiledMap类实现，地图信息保存在一个二维数组中位图大小经过处理为16*16，屏幕宽为480，高为320，即地图信息为20行，列根据关卡的长度自定。

这些都是我现在闲暇时还会反复翻阅的精品资料。里面对近几年的大厂面试高频知识点都有详细的讲解。相信可以有效地帮助大家掌握知识、理解原理，帮助大家在未来取得一份不错的答卷。

在这里就还分享一份由大佬亲自收录整理的学习PDF+架构视频+面试文档+源码笔记，高级架构技术进阶脑图、Android开发面试专题资料，高级进阶架构资料

我们只需要知道的每个实现 BaseApp 接口的类的全限定名并写到moduleInitArr数组里，然后通过反射获取 Class 对象从而获取构造函数创建实体对象，最后调用 BaseApp 的 onCreate 方法将 application 传入，每个Application生命周期的方法都可以通过这种方式传递。

val module = clazz.getConstructor().newInstance() as BaseApp

可以看到其实和页面跳转的方式基本雷同，包括获取 Fragment 实例的方式也是这种。ARouter把所有通信的方式都用一种api实现，让使用者上手非常容易。

实际上市面已经有比较成熟的路由框架专门就是为了组件化而生的，比如美团的WMRouter，阿里的ARouter等，本例使用 ARouter 框架，看下ARouter页面跳转的基本操作。

implementation: A implementation B，B implementation C， 但 A 不能访问到 C 的东西。

由于library是不需要 Application 和启动Activity页，所以我们要区分这个文件，应用manifest指定的路径没有特定，随意找个路径创建即可。在应用AndroidManifest.xml里我们要设置启动页：

isModule 为 true 时表示组件可以作为 apk 运行起来，false 表示组件只能作为 library。我们根据需要改变这个值后同步下gradle即可。

前面有提到非大型项目一般不会进行组件化，但是就像上面提到的功能重用，这个优势并不是只能用到大型项目 。我们可以在写需求或库时完全可以拥有组件化思想，把它们单独写成一个基础组件或业务基础组件。当第二个项目来的时候正好也需要这个组件，那我们就省去了拆出这个组件的时间（因为写需求的时候很可能会造成大量耦合，后续拆分要花费时间），比如登录组件，分享组件等等都是可以在一开始就写成组件的。

功能重用：一次编码处处复用，再也不需要复制代码了。尤其是基础组件和业务基础组件，基本上调用者根据文档就可以一键集成和使用。

提高协作效率：每个组件都有专人维护，不用关心其他组件是怎么实现的，只需要暴露对方需要的数据。测试也不需要整个回归，只需要重点测试修改的组件即可。

加快编译速度：每个业务组件都可以单独运行调试，速度提升好几倍。举个例子：video组件单独编译运行时间为3s，因为此时AS只会运行video组件以及video组件依赖的组件的task，而如果集成编译时间为10s，app所引用的所有的组件的task都会执行。可见，效率提升了3倍。

这里先提几个概念，我们日常业务需求开发的组件叫做业务组件，如果这个业务需求是可以被普遍复用的，那么叫做业务基础组件，譬如图片加载、网络请求等框架组件我们称为基础组件。搭建所有组件的app组件称为壳组件/工程。接下来看一张架构图：

这里先提几个概念，我们日常业务需求开发的组件叫做业务组件，如果这个业务需求是可以被普遍复用的，那么叫做业务基础组件，譬如图片加载、网络请求等框架组件我们称为基础组件。搭建所有组件的app组件称为壳组件/工程。

创建一个 Project 后可以创建多个 Module，这个 Module 就是所谓的模块。一个简单的例子，可能在写代码的时候我们会把首页、消息、我的模块拆开，每个 tab 所包含的内容就是一个模块，这样可以减少 module 的代码量，但是每个模块之间的肯定是有页面的跳转，数据传递等，比如 A 模块需要 B 模块的数据，于是我们会在 A 模块的 gradle 文件内通过 implementation project(':B')依赖 B 模块，但是 B 模块又需要跳转到 A 模块的某个页面，于是 B 模块又依赖了 A 模块。这样的开发模式依然没有解耦，改一个bug依然会改动很多模块，并不能解决大型项目的问题。

小项目是不需要组件化的。当一个项目有数十个人开发，编译项目要花费10分钟，修改一个bug就可能会影响到其他业务，小小的改动就需要进行回归测试，如果是这种项目，那么我们需要进行组件化了

业务领域千差万别，可能是电商项目，可能是社交项目，还有可能是金融项目；开发技术也一直在快速迭代，也许在用纯 Native 开发模式，也许在用 Flutter、RN 开发模式，也许在用混合开发模式；但无论如何，这些项目在架构设计方面的底层原理和设计思路都是万变不离其宗的，这些东西也正是我们真正要学习和掌握的核心能力。

做好项目的架构设计需要我们考虑到技术选型、业务现状、团队成员、未来规划等很多方面，并且伴随着业务的发展，还需要在项目不同阶段对工程和代码进行持续化重构。

private final CallbackProxy callbackProxy = new CallbackProxy();

public class CallbackProxy implements Callback1, Callback2, Callback3 {

public class SimpleCallback implements Callback1, Callback2 {

这种方案确实能解决外部无法静默升级SDK的问题，但却会带来另外的问题，随着每次接口升级，外部设置回调函数的代码将会越来越多。

以上是很常见的一种回调设置方式，如果仅仅是做业务开发，这种写法没有任何问题，但如果是做成给外部客户使用的SDK，这种做法就会存在瑕疵。

public void onEvent(String action, Object... args) {

eventManager.registerObserver(new EventManager.OnEventListener() {

农村加工厂创业项目大学生public class EventManager extends Observable< EventManager.OnEventListener> {

topIcon.setVisibility(visible ? View.GONE : View.VISIBLE);

private void onFirstItemVisibleChanged(boolean visible) {

onFirstItemVisibleChanged(layoutManager.findFirstVisibleItemPosition() == 0);

LinearLayoutManager layoutManager = (LinearLayoutManager) recyclerView.getLayoutManager();

public void onScrollStateChanged(RecyclerView recyclerView, int newState) {

recyclerView.addOnScrollListener(new RecyclerView.OnScrollListener() {