本文为现代化 Android 开发系列文章第七篇。

完整目录为：

  • 现代化 Android 开发：基础架构
  • 现代化 Android 开发：数据类
  • 现代化 Android 开发：逻辑层
  • 现代化 Android 开发：组件化与模块化的选择
  • 现代化 Android 开发：多 Activity 多 Page 的 UI 架构
  • 现代化 Android 开发：Jetpack Compose 最佳实践
  • 现代化 Android 开发：功能监控（本文）

功能优化是开发永久绕不过的论题，也是通往高手的必经之路。但功能优化的前提是搭建了完善的功能监控体系，大公司都会投入人力建设完善的 APM 监控体系，而小公司则更多的只能运用大公司供给的渠道与 SDK，乃至由于事务压力，往往也没有时刻去搞什么功能优化。所以说这方面的生长，那得后退几年，在大公司才有时机得到训练。而现在，该有的 APM 体系都有了，现已是维护为主了。对外的 SDK 与渠道都在想方设法收点费了，小公司能够看数据剖析的当地就更少了。

假如是学习的话，那么极客时刻上张绍文大佬的《Android开发高手课》便是十分推荐的学习资源了，溃散、内存、IO、存储、网络、发动、包体积、UI等方方面面都有讲得很深。而且大佬是十分重视线上监控的，力求做到问题早暴露、早处理。

作为事务开发的我，当然不是讨论各个底层的完成，而是利用各种库和东西来完成自己的监控意图，所以本文首要讨论的事务层能够运用哪些东西。

上报

各大渠道供给大而全的 SDK，则是采集-上报-剖析一条龙的都承包了，关于运用端而言则是几句代码的事了，所以它点费也是理所应当，不过，小公司，非必要，给钱是不或许给钱的了。所以我在 emo 中开发了通用的上报库 report，封装了当即上报、批次上报等行为逻辑，后端能够运用 Prometheus，这便是把监控也作为事务数据上报的一部分。而由于 report 是一个通用的上报库，运用者需求自定义数据协议，所以 emo 之前规划的一个开展便是定制各种监控的数据协议，和后端供给配套的 docker，不过也只是有心而无力，没这个排期。

Crash

Crash 、ANR、OOM 应该是最受重视的监控目标，java 层的 crash 好捕捉，难的是 native 层的反常，难以捕捉，而且或许捕捉不到，所以往往为了获取详细的 crash 信息，大家都或许会一起接入几个 SDK 去监控。现在比较通用的或许仍是 Bugly，究竟免费。但 Android 端 SDK 现在做得最好的或许是爱奇艺开源的 xCrash，假如想要学习的话，阅览它的源码，应该是一个十分好的手段。

Bugly 额定增加日志文件支撑得不是很好，可是许多 crash，咱们往往要去日志中去寻求反常原因。所以现在我自己的反常上报计划便是运用 xCrash，在 crash 时把日志也上报一份。

除此之外，官方也在 Android 11 供给了 App Exit Reasons 这个 API, 用于咱们获取用户是由于什么状况退出运用的，现在，应该干流的手机都升级到 11 以上了吧，所以它也能够用起来了，而且它的 reason 还包括 REASON_LOW_MEMORY、REASON_EXCESSIVE_RESOURCE_USAGE 等很多原因，作为数据剖析，也是十分有用的。

内存走漏

内存走漏现在的干流剖析东西便是 LeakCanary 了，所以 App 怎样也得接入下，这个也是面试官十分喜欢问的问题了，属于面试必备了，了解下其完成原理也是很有必要的。

网络监控

网络监控首要是两个点，一个是上下行流量的监控，避免开发写了有问题的代码，出现在循环内张狂请求后台的状况，除了会给后台压力，也简单被用户投诉。emo 的 network 做了一个简易的上下行流量的采样，能够一段时刻采样一次，看是否出现突发流量的状况。

另一个便是网络连接稳定、耗时的监控了，由于现在基本上都是 OKHttp 了，所以直接运用它供给的 EventListener 就满足用了，就能够把 ssl 握手时刻、dns 时刻、connect 时刻等都计算下来。网络请求一般是十分多的，一般客户端需求先聚合下再上报给后台。

卡顿监控

卡顿监控，曾经基本上便是以下两种计划：

  • Choreographer 回调
  • Looper 自定义 Printer

咱们能够运用微信的 Matrix 来监控卡顿，其完成计划是基于 Looper 来做的。

后面体系供给了 FrameMetrics 接口，然后 jetpcak 开发了库 Metrics，jetpack 的完成确保了良好的兼容性，可惜现在稳定版还没到来，估计今后它便是干流了。

发动监控

发动优化也是一个重要的论题，假如首次发动时刻久了，用户或许就抛弃运用了。Google Play 能够选用大杀器 Baseline Profile 来优化运用首次装置后的发动时刻。而国内的厂商到现在都没有追随一下的意思，所以发动耗时就依赖于事务层的改进，把能晚点初始化的东西就晚点初始化。

微信的 Matrix 也供给了发动耗时的监控，用就行了。

体系也供给了 reportfullydrawn 方法，能够由事务方来告诉体系我的数据加载完成了，从而能够陈述发动到真正界面可用的时刻。不过这个是为了官方供给的剖析东西用的，不能直接用于线上监控。

最后

Matrix 除了上面提到的这些，还包括了：慢方法检测、APK 剖析、 SQLite 查看、电脑优化、内存重复图片检测、IO 检测等等。假如是国外市场，那就能够运用官方的各种诸如 Firebase Crashlytics 服务了。

假如是真的想学习这些技能，那就去看 xCrash、LeakCanary、Matrix 源码，一切的常识尽含其间。但需求巨额的时刻投入。不过现已被作业压榨得喘不过气，又哪来的闲余时刻呢？大伙都在事务上卷得你死我活的，这种功能优化总会被无限期延迟，也就永久没有实践的时机。

总是背负着无尽的技能债，跪倒在一次又一次的需求改变前，过着大负大跪的程序员生活，偶尔翻看下被丢掉的计算机基础常识，以求温故知薪。

现在这个系列文章就写到这儿了，之后会继续更新一些技巧与细节的讨论与思考，诸如 Compose 跨页面通讯、Text 行高改变等常识。