iOS APM性能统计 - 基础篇

Tips：若是未发布应用，可以利用Xcode自带的instruments工具，对我们的应用进行cpu占用、内存占用、FPS、循环引用、离屏渲染、卡顿、页面耗时、网络、启动时长等各个维度进行分析。若为线上应用，我们只能通过自行打点采集各个维度的信息，来进行性能分析。

一、性能统计维度

1.设备属性维度

• OS类型
• 广告标示符idfa （iOS14.5开始强制权限，iOS14.0-iOS14.5可强行读取idfa，14以下老方法）
• 厂商标识符idfv （也可认为是应用维度）
• 设备名称
• 系统版本
• 设备Machine
• 运营商
• 硬盘总容量
• 物理内存总容量
• 当前硬盘容量
• 当前内存容量
• 分辨率
• 设备Model
• 时区
• 国家
• 设备语言
• 系统上次启动时间
• 系统上次更新时间
• 当前可用空间
• 当前网络类型
• 当前ip
• 当前cpu使用率
• 是否越狱标识
• 当前电池电量
• 当前屏幕亮度
• 当前充电状态
• gps开关状态
• UserAgent
• 最近一次定位坐标（需要定位权限）
• ssid 当前wifi名称 （iOS13开始需要定位权限）
• bssid 当前wifi的bssid（iOS13开始需要定位权限）
• bundleSeedID

2.应用基本属性维度

• 应用名称
• 应用bundle id
• 应用版本
  • BundleShortVersion
  • BundleVersion
• 应用热更版本（若有）
• 应用RN包版本（若有）
• 业务灰度包版本（若有）
• 小程序版本（若有）
• 性能统计SDK版本
• user id
• session id
• 自定义uuid（存储在keychain里）
• 是否在后台
• 应用运行时长
• 当前应用商店地区
• 当前应用商店商品货币类型

3.应用性能维度

• 持续电量统计
• 持续cpu使用率统计
• 持续内存使用率统计
  • 各个模块、插件、大文件内存使用
  • 循环引用监测
• 网络持续监测
  • 网络类型持续监测
  • 网络流量持续监测
  • 网络错误类型
• FPS
• 主线程卡顿监测
• 页面渲染时长
• 大文件存储监测
• 闪退日志记录
• 启动时间监测
  • 冷启动时间监测
  • 热启动时间监测
• 全打点，每个函数耗时监测（线上不推荐）
• Flutter、RN、web、小程序等问题日志（若有）

4.应用业务维度

• 应用生命周期打点
• 各个业务页面打点、停留时长打点
• 用户行为打点（通过AOP，自动获取view的链路树打点）
• 根据实际产品定制维度。。。

注意：由于苹果对标识设备、用户的行为监管越来越严，采集过多的设备信息会被苹果认为违规，会收到苹果的整改邮件通知。另外，中广协的CAID暂时不要对接，苹果审核时候会被劝退。

二、数据落地

0.设计理念

• 性能统计SDK接入足够轻量、简单、无侵入
• 策略配置灵活、易控制
• 性能损耗低、绝不能影响主业务本身
• 尽量不使用私有API，避免被苹果审核误判
• 本地数据做好持久化，避免闪退时候写本地失败，使用mmap
• 数据大小尽量小，可使用protobuf；另外部分数据可压缩上传
• 数据需要加密传输
• 上传数量策略灵活：部分点位实时上传、部分点位可以合并压缩后上传、断网重试等
• 针对不同机型，有不同配置
• 打点点位可以灰度、服务器下发
• 配套监控、报警体系，实时跟进线上突发以及新功能问题
• 全球化业务需要做到满足各国法规，国内三级等保、欧盟GDPR 等 ，隐私策略或是用户协议里需说明

1.数据采集

采集维度分为六大类：

• 启动后打点记录一次性基本设备信息维度: 机型、系统版本、idfa等
• 每次打点都需要包含的base维度：uuid、userid、会话id、sdk版本等
• 持续性的性能监测维度：电量、cpu使用率、内存使用率、卡顿、网络相关等
• 偶发性的统计维度：冷启动耗时、热启动耗时、闪退等
• 业务维度：模块、页面打点、停留时间打点等
• 自定义日志：自定义log等

{
     //base信息
     "timestamp":"事件产生时间(13位 毫秒)",
     "appId":"应用ID",
     "device":"设备型号",
     "sessionId":"会话id",
     "idfv":"应用开发商标识符",
     "advertisingId":"idfa",
     "deviceId":"自定义存keychain uuid",
     "sdkVer":"SDK版本号",
     "appVer":"应用版本号",
     "userID":"用户ID",
     ...  
     "deviceInfo":{
       ...
     },
     "crashInfo":{
       ...
     },
     "performanceInfo":{
       ...
     },
     "moduleInfo":{
       ...
     },
     "eventInfo":{
       ...
     }
}

采集时机：

• 实时上传维度
• 部分数据合并后择机上传
• 突破某个阀值上传
• 断网重试或是下次启动上传

2.数据合成、压缩、存储

• 数据存储，若为实时上传类型，则不用存储端侧，若实时上传失败且重试机制情况下依然失败，则需要存储端侧；若为非实时数据，则需要存储端侧；择机上传；
• 考虑到app意外退出，会有日志或是闪退信息无法存储端侧的情况，可以采用mmap方式存储日志；
• 考虑到频繁的IO会造成性能上的消耗，我们需要对数据进行合并，且读写时候，需要参照当前机型的虚拟内存页的大小，老的机型是4KB。即每次读写都是按开辟4KB存储；
• 考虑到上传数据的大小问题，可以考虑使用protobuf对数据进行压缩；另外，protobuf数据本地持久化的过程可以参照微信的MMKV设计；
• 另外数据是否加密，可以酌情考虑
• 端侧日志数据存储上限应针对不同硬盘大小设定

3.上传服务器

• 上传失败重试机制
• app闲时或是刚进入后台等时机，择机上传
• https

4.数据分析处理

• 数据上传到数据服务器，进行解压、处理、按业务维度进行处理
• 根据具体业务进行多维度处理
• 入库需要的数据，定时清理老日志文件

5.web仪表盘展示

• 按应用维度、版本维度、系统维度、业务维度、动作维度、机型维度 等等进行展示；
• 业务点击率、转化率等；
• 按PV、UV、DAU、MAU、PCU、APA、ARPU等维度；
• 异常、闪退维度；
• 更多。。。

6.监控、报警体系搭建

• 根据已有的维度以及数据，对线上业务或是新版本进行监控，比如初始化成功率、登录成功率、支付成功率、某个业务的点击或是完成率、在线用户数，针对不同时段给到一个上、下限，若是触发了边界值，则通过邮件、企业微信、短信或是报警电话等方式通知相关干系人；
• 具体的监控以及报警体系以实际业务为基准定制；
• 我们部门有买了小米75寸电视作为监控屏幕，挂在部门墙上；
• 按照经验，我们部门在凌晨会经常收到误报，常见的是苹果支付的问题（一般是苹果服务器抽风）， 另外是业务部门在做停服更新，登录、支付、用户等指标骤降，会触发报警，还是需要跟各个业务部门定好更新机制；

三、复盘、优化、整改

• 有了以上的日志分析，需要对各个业务线进行复盘、优化、整改，再监测，再优化整改，不断循环；
• 监控与报警体系搭建也不是一朝一夕，也需要不断优化，使其更加精准，尤其是节假日的时候，发挥其作用；
• 这么多的数据如何有效的利用以及如何用来改善产品，需要运营、产品一起去有效的开发，而不是纯粹的只是记录、监控；
• 这些数据可以有效的帮助市场同学分析，在各个移动平台广告投放的效果 以及转化；
• 作为技术人员，除了关注技术侧的应用本身质量、稳定性、性能等，视野也要拓展，协同运营、产品、市场给应用带来更多的用户，更好的体验；

四、总结

APM开发力度如何，应视业务规模而定，若达到一定的量，必须认真对待。本文更多的提了一些iOS侧，对于android也一样适用，除了部分设备指纹维度有所区别。