mirror of
https://github.com/NohamR/knowledge-kit.git
synced 2026-05-24 20:00:37 +00:00
docs: APM style
This commit is contained in:
杭城小刘
@@ -351,7 +351,7 @@ dispatch_async(dispatch_get_global_queue(0, 0), ^{
|
||||
if (++strongSelf.countTime < strongSelf.standstillCount){
|
||||
continue;
|
||||
}
|
||||
// 堆栈信息 dump 并结合数据上报机制，按照一定策略上传数据到服务器。堆栈 dump 会在下面讲解。数据上报会在 [打造功能强大、灵活可配置的数据上报组件](./1.80.md) 讲
|
||||
// 堆栈信息 dump 并结合数据上报机制，按照一定策略上传数据到服务器。堆栈 dump 会在下面讲解。数据上报会在 [打造功能强大、灵活可配置的数据上报组件](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.80.md) 讲
|
||||
}
|
||||
}
|
||||
strongSelf.countTime = 0;
|
||||
@@ -365,7 +365,7 @@ dispatch_async(dispatch_get_global_queue(0, 0), ^{
|
||||
|
||||
##### 3.2 子线程 ping 主线程监听的方式
|
||||
|
||||
开启一个子线程，创建一个初始值为0的信号量、一个初始值为 YES 的布尔值类型标志位。将设置标志位为 NO 的任务派发到主线程中去，子线程休眠阈值时间，时间到后判断标志位是否被主线程成功（值为 NO），如果没成功则认为猪线程发生了卡顿情况，此时 dump 堆栈信息并结合数据上报机制，按照一定策略上传数据到服务器。数据上报会在 [打造功能强大、灵活可配置的数据上报组件](./1.80.md) 讲
|
||||
开启一个子线程，创建一个初始值为0的信号量、一个初始值为 YES 的布尔值类型标志位。将设置标志位为 NO 的任务派发到主线程中去，子线程休眠阈值时间，时间到后判断标志位是否被主线程成功（值为 NO），如果没成功则认为猪线程发生了卡顿情况，此时 dump 堆栈信息并结合数据上报机制，按照一定策略上传数据到服务器。数据上报会在 [打造功能强大、灵活可配置的数据上报组件](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.80.md) 讲
|
||||
|
||||
```Objective-c
|
||||
while (self.isCancelled == NO) {
|
||||
@@ -702,7 +702,7 @@ for (int i = 0; i < threadCount; i++) {
|
||||
}
|
||||
CPUPayloadData = [parsedData copy];
|
||||
|
||||
// 3. 数据上报会在 [打造功能强大、灵活可配置的数据上报组件](./1.80.md) 讲
|
||||
// 3. 数据上报会在 [打造功能强大、灵活可配置的数据上报组件](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.80.md) 讲
|
||||
[[PrismClient sharedInstance] sendWithType:CMMonitorCPUType meta:CPUMetaDictionary payload:CPUPayloadData];
|
||||
}
|
||||
}
|
||||
@@ -1457,11 +1457,11 @@ timer = [NSTimer scheduledTimerWithTimeInterval:0.01 target:self selector:@selec
|
||||
|
||||
iOS13 开始 <os/proc.h> 中 `size_t os_proc_available_memory(void); ` 可以查看当前可用内存。
|
||||
|
||||
> ## Return Value
|
||||
> Return Value
|
||||
>
|
||||
> The number of bytes that the app may allocate before it hits its memory limit. If the calling process isn't an app, or if the process has already exceeded its memory limit, this function returns `0`.
|
||||
>
|
||||
> ## Discussion
|
||||
> Discussion
|
||||
>
|
||||
> Call this function to determine the amount of memory available to your app. The returned value corresponds to the current memory limit minus the memory footprint of your app at the time of the function call. Your app's memory footprint consists of the data that you allocated in RAM, and that must stay in RAM (or the equivalent) at all times. Memory limits can change during the app life cycle and don't necessarily correspond to the amount of physical memory available on the device.
|
||||
>
|
||||
@@ -2402,7 +2402,7 @@ API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))
|
||||
self.errModel.errorCode = error.code;
|
||||
self.errModel.exceptionName = error.domain;
|
||||
self.errModel.exceptionDetail = error.description;
|
||||
// 上传 Network 数据到数据上报组件，数据上报会在 [打造功能强大、灵活可配置的数据上报组件](./1.80.md) 讲
|
||||
// 上传 Network 数据到数据上报组件，数据上报会在 [打造功能强大、灵活可配置的数据上报组件](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.80.md) 讲
|
||||
}
|
||||
self.dataTask = nil;
|
||||
}
|
||||
@@ -2457,7 +2457,7 @@ API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))
|
||||
self.dataModel.useProxy = obj.isProxyConnection;
|
||||
}
|
||||
}];
|
||||
// 上传 Network 数据到数据上报组件，数据上报会在 [打造功能强大、灵活可配置的数据上报组件](./1.80.md) 讲
|
||||
// 上传 Network 数据到数据上报组件，数据上报会在 [打造功能强大、灵活可配置的数据上报组件](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.80.md) 讲
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -3595,7 +3595,7 @@ HTTP 请求报文结构
|
||||
}
|
||||
```
|
||||
|
||||
6. 在 `- (NSURLRequest *)connection:(NSURLConnection *)connection willSendRequest:(NSURLRequest *)request redirectResponse:(NSURLResponse *)response` 方法中将数据上报会在 [打造功能强大、灵活可配置的数据上报组件](./1.80.md) 讲
|
||||
6. 在 `- (NSURLRequest *)connection:(NSURLConnection *)connection willSendRequest:(NSURLRequest *)request redirectResponse:(NSURLResponse *)response` 方法中将数据上报会在 [打造功能强大、灵活可配置的数据上报组件](https://github.com/FantasticLBP/knowledge-kit/blob/master/Chapter1%20-%20iOS/1.80.md) 讲
|
||||
|
||||
```objective-c
|
||||
-(NSURLRequest *)connection:(NSURLConnection *)connection willSendRequest:(NSURLRequest *)request redirectResponse:(NSURLResponse *)response
|
||||
@@ -3620,11 +3620,6 @@ HTTP 请求报文结构
|
||||
return request;
|
||||
}
|
||||
```
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -3647,7 +3642,15 @@ HTTP 请求报文结构
|
||||
- 设置 UIDevice 的 batteryMonitoringEnabled 为 true
|
||||
- 获取到的耗电量精确度为 1%
|
||||
|
||||
```objective-c
|
||||
### 2. 定位问题
|
||||
|
||||
通常我们通过 Instrucments 里的 Energy Log 解决了很多问题后，App 上线了，线上的耗电量解决就需要使用 APM 来解决了。耗电地方可能是二方库、三方库，也可能是某个同事的代码。
|
||||
|
||||
思路是：在检测到耗电后，先找到有问题的线程，然后堆栈 dump，还原案发现场。
|
||||
|
||||
在上面部分我们知道了线程信息的结构， `thread_basic_info` 中有个记录 CPU 使用率百分比的字段 `cpu_usage`。所以我们可以通过遍历当前线程，判断哪个线程的 CPU 使用率较高，从而找出有问题的线程。然后再 dump 堆栈，从而定位到发生耗电量的代码。详细请看 [3.2](#threadInfo) 部分。
|
||||
|
||||
```objective-c
|
||||
- (double)fetchBatteryCostUsage
|
||||
{
|
||||
// returns a blob of power source information in an opaque CFTypeRef
|
||||
@@ -3694,16 +3697,6 @@ HTTP 请求报文结构
|
||||
|
||||
|
||||
|
||||
### 2. 定位问题
|
||||
|
||||
通常我们通过 Instrucments 里的 Energy Log 解决了很多问题后，App 上线了，线上的耗电量解决就需要使用 APM 来解决了。耗电地方可能是二方库、三方库，也可能是某个同事的代码。
|
||||
|
||||
思路是：在检测到耗电后，先找到有问题的线程，然后堆栈 dump，还原案发现场。
|
||||
|
||||
在上面部分我们知道了线程信息的结构， `thread_basic_info` 中有个记录 CPU 使用率百分比的字段 `cpu_usage`。所以我们可以通过遍历当前线程，判断哪个线程的 CPU 使用率较高，从而找出有问题的线程。然后再 dump 堆栈，从而定位到发生耗电量的代码。详细请看 [3.2](#threadInfo) 部分。
|
||||
|
||||
|
||||
|
||||
### 3. 开发阶段针对电量消耗我们能做什么
|
||||
|
||||
CPU 密集运算是耗电量主要原因。所以我们对 CPU 的使用需要精打细算。尽量避免让 CPU 做无用功。对于大量数据的复杂运算，可以借助服务器的能力、GPU 的能力。如果方案设计必须是在 CPU 上完成数据的运算，则可以利用 GCD 技术，使用 `dispatch_block_create_with_qos_class(<#dispatch_block_flags_t flags#>, dispatch_qos_class_t qos_class, <#int relative_priority#>, <#^(void)block#>)()` 并指定 队列的 qos 为 `QOS_CLASS_UTILITY`。将任务提交到这个队列的 block 中，在 QOS_CLASS_UTILITY 模式下，系统针对大量数据的计算，做了电量优化
|
||||
@@ -3737,7 +3730,7 @@ NSCache 的使用可以查看 SDWebImage 这个图片加载框架。在图片读
|
||||
|
||||
|
||||
|
||||
## 六、 Crash 监控
|
||||
## 七、 Crash 监控
|
||||
|
||||
### 1. 异常相关知识回顾
|
||||
|
||||
@@ -6499,7 +6492,7 @@ Crash log 统一入库 Kibana 时是没有符号化的，所以需要符号化
|
||||
|
||||
|
||||
|
||||
## 七、 APM 小结
|
||||
## 八、 APM 小结
|
||||
|
||||
1. 通常来说各个端的监控能力是不太一致的，技术实现细节也不统一。所以在技术方案评审的时候需要将监控能力对齐统一。每个能力在各个端的数据字段必须对齐（字段个数、名称、数据类型和精度），因为 APM 本身是一个闭环，监控了之后需符号化解析、数据整理，进行产品化开发、最后需要监控大盘展示等
|
||||
|
||||
|
||||
Reference in New Issue
Block a user