docs: APM、多句柄数据上报SDK、软件测试小结

Chapter1 - iOS/1.72.md

@@ -24,19 +24,19 @@
   #endif
   ```
 - 对于你的某个 SDK，你在为某个方法、某个类、某个宏定义命名的时候需要注意选择合适的前缀
-  比如。你的某个项目是在做监控，SDK 的名字叫做 Prism-Client。那么你的类名称、类方法名称、宏定义、分类名称、分类方法名称等都需要合适且统一的前缀，一般选取 `前3个字母组合`。当前的项目叫做 `PCT`。类前面加 PCT，类里面的方法不加前缀。分类名称加前缀 PCT，分类里面的方法前面加前缀，小写的 pct。
+  比如。你的某个项目是在做监控，SDK 的名字叫做 Hermes-Client。那么你的类名称、类方法名称、宏定义、分类名称、分类方法名称等都需要合适且统一的前缀，一般选取 `前3个字母组合`。当前的项目叫做 `HCT`。类前面加 HCT，类里面的方法不加前缀。分类名称加前缀 HCT，分类里面的方法前面加前缀，小写的 HCT。
   普通类的方法不加前缀是因为普通类已经通过类名的唯一性确定了方法的唯一。
   分类里面方法加前缀是因为分类的方法在工程里面这个类都可以访问。所以要在方法前面区分
   ```Objective-C
   // 安全的数据获取方法
-  #ifndef PCT_SAFE_STRING
-      #define PCT_SAFE_STRING(x) (x) != nil ? (x) : @""
+  #ifndef HCT_SAFE_STRING
+      #define HCT_SAFE_STRING(x) (x) != nil ? (x) : @""
   #endif
 
-  NSData+PCTAES.h
-  - (NSData *)pct_AES128EncryptWithKey:(NSString *)key gIv:(NSString *)Iv;
+  NSData+HCTAES.h
+  - (NSData *)hct_AES128EncryptWithKey:(NSString *)key gIv:(NSString *)Iv;
 
-  PCTRequestFactory.h
+  HCTRequestFactory.h
   + (void)fetchUploadConfigurationWithRequestURL:(NSString *)requestUrlString
                                                 params:(NSDictionary *)params
                                                success:(void (^)(PRCConfigurationModel*model))success
@@ -60,11 +60,11 @@
   - 内联函数的定义须在调用之前
   - Objective-C 中内联函数用 NS_INLINE ，等价于 static inline。且内联函数的命名需要注意，在该模块内的内联函数需要加前缀。
   ```Objective-C
-  NS_INLINE NSString * PCTGetTableNameFromType(PCTLogTableType type){
-      if (type == PCTLogTableTypeMeta) {
+  NS_INLINE NSString * HCTGetTableNameFromType(HCTLogTableType type){
+      if (type == HCTLogTableTypeMeta) {
           return PRC_LOG_TABLE_META;
       }
-      if (type == PCTLogTableTypePayload) {
+      if (type == HCTLogTableTypePayload) {
           return PRC_LOG_TABLE_PAYLOAD;
       }
       return @"";
@@ -94,6 +94,6 @@
       NSLog(@"%zd", [AFNetworkReachabilityManager sharedManager].networkReachabilityStatus);
   }
   ```
-  之前在做一个类 `PCTRequestFactory` 用来管理网络相关的逻辑。需要判断网络状态，我们都知道 AFNetWorking 第一次判断网络状态得到的是 AFNetworkReachabilityStatusUnknown。而我的逻辑需要 SDK 启动的时候判断网络状态，然后去上报数据。所以刚开始 AFNetworkReachabilityStatusUnknown 显然不能上报 Crash 数据，所以想着是将第一次的网络状态获取放到 **load** 方法里。这样是没问题的，可以拿到网络状态，但是我们知道 load 是类加载的时候调用的，打开 Xcode 看到 Build Phases 里面 `Link BiBinary With Libraries` 这个里面的库的顺序决定了里面的类加载顺序。我们知道 Pod 的原理是在 Podfile 里面描述的 pod 库依赖，然后会按照字典序（首字母排序去）引入，所以 AFNetWorking 这个肯定早，所以会成功的。但是万一是人工手动去引入或者修改库的位置，则在 PCTRequestFactory 里面的 load 方法执行的时候不一定可以保证 AFNetworkReachabilityManager 已经加载好。所以将 load 逻辑移动到 init 里面。
+  之前在做一个类 `HCTRequestFactory` 用来管理网络相关的逻辑。需要判断网络状态，我们都知道 AFNetWorking 第一次判断网络状态得到的是 AFNetworkReachabilityStatusUnknown。而我的逻辑需要 SDK 启动的时候判断网络状态，然后去上报数据。所以刚开始 AFNetworkReachabilityStatusUnknown 显然不能上报 Crash 数据，所以想着是将第一次的网络状态获取放到 **load** 方法里。这样是没问题的，可以拿到网络状态，但是我们知道 load 是类加载的时候调用的，打开 Xcode 看到 Build Phases 里面 `Link BiBinary With Libraries` 这个里面的库的顺序决定了里面的类加载顺序。我们知道 Pod 的原理是在 Podfile 里面描述的 pod 库依赖，然后会按照字典序（首字母排序去）引入，所以 AFNetWorking 这个肯定早，所以会成功的。但是万一是人工手动去引入或者修改库的位置，则在 HCTRequestFactory 里面的 load 方法执行的时候不一定可以保证 AFNetworkReachabilityManager 已经加载好。所以将 load 逻辑移动到 init 里面。
 
   另外，load 方法一般只做和本类有关系的逻辑，比如 hook 方法。