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也一样适用，除了部分设备指纹维度有所区别。