分享篇 -《App架构师实践指南》阅读总结人工智能u014294681的博客-

本文章主要是对《App架构师实践指南》一书的阅读总结，作为自己阅读结果的提炼。

目录：

1. 使用内部类最大的优点是什么？
2. 匿名内部类的内存泄露
3. 如何在 github 上选择开源库
4. 使用开源库时，为什么要封装一层
5. 堆积、组件化、模块化以及插件化历程
6. 重构分类
7. App 质量监控思维导图
8. CI 的概念
9. Android 异常分类
10. A/B 测试
11. App 性能优化思维导图
12. App 耗电优化
13. 关于 16ms 与 60帧/s

1. 使用内部类最大的优点是什么？

内部类可以非常好的解决多重继承的问题，每个内部类都能独立地继承一个 (接口的) 实现，所以无论外部类是否已经继承了某个(接口的) 实现，对于内部类都没有影响。

2. 匿名内部类的内存泄露

使用匿名内部类时，一定要慎重对待内存泄漏 (内部类保持了外部类的引用实例，内部类不销毁，外部类就无法被回收)。一般用静态内部类＋弱引用方式或者动态代理方式替代。

3. 如何在 github 上选择开源库

• Author: 选择一个开源项目时，我们必须了解项目作者，是知名个人 (所谓网红) 还是大型公司 (如 Google 等)，这是我们选择的依据之一。
• Last commit: 我们需要重点关注的是最后更新时间，如果该项目己经停止维护或者最后更新时间超过一年，就要慎重选择。
• 指标: Github 上，一个项目的 Star/Issues/PullRequests/Releases/Contributors/ Latest commit 信息值得我们关注。
• 文档: 可用于查看 README.md 、功能介绍、使用方法及基本原理等，便于快速集成验证。
• 依赖: 明确是否对其他第三方库有依赖，如果有很多依赖，则要谨慎使用。
• 聚合: 判断某项目是否是大而全的聚合型源码或框架？聚合型项目一般都是高藕合，很难扩展和业务适应，需谨慎使用。

4. 使用开源库时，为什么要封装一层

封装的好处非常多，如可以实现入口统一，适应业务变换或者开源项目本身的变换，灵活快速替换成其他开源库实现等。

5. 堆积、组件化、模块化以及插件化历程

Android 应用架构的发展，经历了原始野蛮式堆积、组件化、模块化以及插件化历程，这里我们谈谈 3 者的定义与异性。

• 模块化: 可以简单理解为：以业务功能为单元的独立模块，如登录模块化就是将登录模块抽离出来作为独立单元模块。
• 组件化: 组件化实现了与业务无关，以软件复用为核心，达到 “即插即用” 快速构造应用软件的效果。
• 插件化: 与组件化不同，插件化在运行时合并模块，而组件化是在编译时合并模块。插件化有黑科技的概念，它可以线上更换你手机应用中的代码或模块，实现远程控制。

6. 重构分类

重构的内容部分，分为架构和代码。

• 架构上: 随着业务的不断发展，当初的架构往往面临着各种问题，如无法满足客户的需求、无法实现应用的扩展、无法实现新的特性等，在这些情况下，作为架构师或开发者，将要开始考虑通过架构重构来解决问题。
• 代码上: 可能由于种种原因，先前代码存在结构混乱 (代码无层次堆积，各种代码风格杂交，强藕合等)、可读性差 (超长函数，代码不规范不 致，冗余代码，运算逻辑难以理解等) 等问题，在这些情况下，我们需要对代码进行重构。

7. App 质量监控思维导图

8. CI 的概念

持续集成 (Continuou Integration)，英文缩写为 CI. 

CI 词来源于极限编程 (Extreme Programming)，作为它的 12 个实践之一出现，官方定义为 “持续集成是一种软件开发实践”，即团队开发成员经常集成他们的工作，通常每个成员至少每天集成一次，也就是每天可能会发生多次集成，每次集成都通过自动化的构建 (包括编译、发布、自动化测试) 来验证，从而快速地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快地开发内聚的软件。 

CI 的目的是让产品快速迭代，同时保持高质量，针对移动应用平台，可以简单地理解成当有人向代码库的主分支提交代码的时候，后台的持续集成服务器会尝试去构建整个产品，包括编译打包、自动化测试、质量分析等，输出结果成功或失败。

一个完整的 CI 流程如下图所示，包括开发者的代码提 CI Server Build 及测试，通过后再提交给 Code Server 合并，然后由 CI Server 打包给 QA(Quality Assurance)，审核发布。

9. Android 异常分类

• Java 异常: Java 中出现未捕获异常，导致程序异常终止退出。
• ANR (Application Not Responding): 应用与用户进行交互时，在一定时间（如主线程输入事件中为 5 秒) 内没有响应用户的操作，则会引发 ANR 错误，并弹出一个系统提示框，让用户选择继续等待或立即关闭程序，同时会在／data/anr 目录下生成 traces.txt 文件，记录系统 ANR 异常的堆栈和线程信息。
• Native 异常: Native 异常/崩溃指在 Native 代码 C/C++ 中，因访问非法地址、地址对齐等问题，或程序主动 abort 所产生相应的 Signal 导致程序异常退出。Linux 中定义了很多 Signal ，当然并不是所有的 Signal 都会引发崩溃， 一般会引发异常退出的 Signal 有 SIGSEGV, SIGABRT, SIGILL, SIGBUS, SIGFPE。Native 异常具有与 Java 异常不同的特点：程序会直接闪退到系统桌面，Android 5.0 以下不会弹出提示框提醒程序崩溃，Android 5.0 以上会弹出提示框提醒程序崩溃。

10. A/B 测试

人生没有 AB 可选，但 App 是可以的。A/B 测试 (A/B Testing)，简单来说，就是为目标制定两个方案 (比如两个页面)，让部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用情况，看哪个方案更符合设计目标。A/B Testing 是在移动 App 上验证产品方案的有力工具，可用于视觉 UI 选择、某个功能页面转换率判断等。例如，验证一个功能，方案 A 和方案 B 哪种用户更加接受和认可；再如，判断新功能的加入对产品各个指标的影响程度等。

11. App 性能优化思维导图

12. App 耗电优化

手机中的耗电大户／主要耗电场景：

• 手机屏幕毋庸置疑，手机中最耗电的模块肯定是屏幕了。亮屏时间越长，电量消耗越快。
• CPU 相关复杂运算逻辑、无限循环等会直接导致 CPU 负载过高，耗电剧增。
• 网络相关。一般情况下，网络相关 (网络请求、数据传输、网络切换等) 是仅次于屏幕的耗电大户。例如网络请求，涉及通过内置的射频模块与基站通信，而射频模块又涉及一系列驱动和底层的支持，非常耗电，再如大数据的传输等。2009 Google 大会 Jeffrey Sharkey 的演讲中就总结了 Android 应用耗电主要在大数据传输、不停地网络间切换以及解析大文本数据个方面，而这些方面其实都是直接或间接地跟网络相关的。
• WakeLock 是 Android 系统中用于优化电量使用的一种手段，通过在用户一段时间没有操作的情况下让屏幕和 CPU 进入休眠状态来减少电量消耗。一些应用中出于特定业务场景调用 PowerManager. WakeLock 使 CPU 保持持续运转，而释放需要时间，甚至你根本就忘记释放了，灭屏后 CPU 却还一直运转，从而大大增加了耗电量。
• GPS 定位涉及 GPS 位置传感器，也是 位不折不扣的耗电大户 。平时不使GPS 的时候，记得把它给关了。
• Camera 涉及前后摄像头硬件，如果一直使用 (录屏等)，耗电也会非常可观。

电量优化手段：

【1】网络相关：

• 发起网络请求时机。业务区分当前网络请求是需要及时返回结果的 (用户主动下拉刷新等)，还是可以延迟执行的 (异步上传数据)，可以延迟执行的有针对性地把请求行为绑定在一起发出。
• 减少移动网络被激活的时间和次数。采用回退机制来避免固定频繁的同步请求，例如，在发现返回数据相同的情况下，推迟下次的请求时间。使用 Batching (批处理) 的方式来集中发出请求，避免频繁的间隔请求，例如同一业务尽量少使用多次请求，合并多次请求。使用 Prefetching (预取) 的技术提前把一些数据拿到，避免后面频繁再次发起网络请求。
• 数据处理，网络数据传输前进行压缩处理，进行大数据量下载时，尽量使用 GZIP 方式下载，使用高效率的数据格式和解析方法，推荐使用 JSON Protobuf.
• 慎用或禁用 Polling (轮询) 的方式去执行网络请求， Android 可以采用 Google Cloud Messageing, iOS 可以采用 APNs.
• 减少推送消息次数和频率。App 收到服务端大量或频繁的推送消息，对手机的耗电肯定会有一定影响。
• 网络状态，处理具体业务前，养成判断当前网络状态的习惯和编程思维。例如，在移动网络下，减少数据传输或降低数据传输频率，Wi-Fi 下网络传输耗电远比移动网络少。在网络不可用状态下，尽早进入网络异常处理逻辑，避免不必要的运算逻辑等。

【2】界面相关：

• 离开某个界面后停止对应的耗电活动。例如，用户离开了界面，而对应的耗电活动井没有及时停止，就会造成资源浪费。
• 应用进入后台禁止异常消耗电量。

【3】定位相关：

• 使用 GPS 后记得及时关闭，减少更新频率，根据实际情况切换 GPS 和网络，不要任何时候都同时使用两者。
• 对定位要求不高的业务场景，尽量用网络定位代替 GPS。
• 慎用持续定位，对于大多数场景，使用一次定位接口即可。
• 慎用被动定位，防止被动定位唤醒。

【4】消息广播，程序中避免频繁地监昕系统广播或业务消息造成严重耗电问题，灵活控制消息广播接收的有效与无效状态。

【5】Android 专栏：

• 慎用 WakeLock，使用 WakeLock 时一定记得成双成对，及时释放，使用 WakeLock 时，建议通过带参数的 aquire 设置超时，以防止 App 异常等不可抗拒因素导致没有释放。
• 定时任务选择 Android 中可以通过 Handler/Timer、AlarmManager 以及 JobSchedule (Android 5.0+) 3 种方式执行定时任务，前台任务建议使用 Handler/Timer ，简单直观；后台任务，对调度时机没有强烈要求的场景，建议使用 JobSchedule
  管理任务 (Android 5.0＋)，对于触发时间准确性要求非常高的场景，如果没法通过算法降级处理，再考虑 AlarmManager ，对于 WAKEUP 类型且 Exact 调度模式的 AlarmManager 任务一定要慎用。

13. 关于 16ms 与 60帧/s

• 绘制原理 16ms 原则：Android 系统每隔 16ms 发出 VSync 信号，触发对 U1 进行渲染，这就意味着 Android 系统要求每一帧都要在 16ms 这个时间内绘制完成，即无论代码或业务如何复杂，要保证平滑完成一帧，那么渲染代码必须在 16ms 内完成，从而保证流畅的用户体验，这个速度意味着要能够达到流畅的画面需要 16ms 的帧率。
• 60 帧/s 与 16 ms：为什么会以 60 帧/s 或 16 ms 为标准呢？其实两者是一个统一的概念，一帧 16ms，即 1/0.016 帧/s=62.5帧/s ，而 60 帧/s的标准是源于人眼和大脑之间的协作无法感知超过 60 帧/s 的画面更新。市场上绝大多数 Android 设备的屏幕刷新频率都 60Hz ，超过 60 帧/s 就没有实际意义。

[未完待续]