架构背景与要达到的效果：
1.业务功能，可预估时间。完成
2.软件稳定
3.后期bug可控，可预估
4.迭代版本可扩展，可修改
架构背后使用的技术调研（技术选型）：
1.语言 java还是kotlin
2.显示模式，如View呈现使用xml,还是compnent,是否使用NDK算法
2.第三方SDK ，多厂商的选择比较，兼容性，
架构达到的目的：
1.定位问题输出问题
2.解耦，而达到逻辑清晰。
3.简洁，容易阅读
4.人员分工业务工作量
5.扩展化
6.热修复
架构（业务）模型
MVVM，控制，数据，与视图展现之间的关系
服务进程，日志服务进程，微服务功能
组件化，解耦功能，达到功能独立，人工分开，后期维护分开，微服务功能
架构（代码）模型
建造者模式：管理状态数据池常量->而达到显示控制、功能控制，可扩展
策略模式（树形结构）：一个功能一个总父类->子父类->子类,归类，逻辑清晰，易控制，易阅读。
代理模式：对同样性质动作坐同样监控。从而让注解起到简化代码作用。控制
中介模式（适配器）：让解耦的数据和视图两个进行交互。易控制，简洁，解耦
责任链模式：NEXT->NEXT，一层，一层去拦截监控从而达到，每一层细节的问题抛出。稳定
PS:使用不同的模型，然而会用到，抽象类，接口，注解，反射等高级一点的语言特性。
代码细节
业务逻辑完整
例1：交互进入A状态-> 操作其他->被动跳到其他B状态->恢复状态A状态到初始化->操作B (简单解法是必须完成当前操作)
例2：交互进入A状态->未满足条件->进入等待状态->跳转到进入条件许可->条件满足->唤醒条件
根据例1，例2判断出：
1.操作异常，需要做第一种情况围堵，必须完成当前 第二种情况，恢复当前到初始化，跳到其他操作
2.操作条件不满足，进入等待，操作其他，等待被唤醒
稳定性容错处理
所以需要添加容错处理（0.NULL，越界判断去除 1.0，NAN 2.try,catch包容，数据注意抛出问题）
代码规范
1.必要注解（功能，版本）
2.拼写规范（易阅读）
3.一个函数小功能独立（逻辑清晰，易阅读）
代码测试
偶发问题的的解决（白盒测试）
对于偶尔问题，测试不易复现。这个时候需要Android 开发人员自己写 UnitTest/业务测试代码。等待问题的抛出
PS:自己根据工作经验总结编写，存在不足地方 wohaipeng@dingtalk.com
