BEH_SEND_PATH：发送日志后缀名
#define BEH_SEND_PATH @"m" // 添加埋点事件，比如APP启动，自定义事件，用户留存等
#define CLK_SEND_PATH @"aclk" // 推荐统计，在sdk代码里已经集成，统计页面访问量
#define SHARE_SEND_PATH @"ashare" // 没用到
#define PUSH_SEND_PTH @"apush" // 没用到
#define COMMENT_SEND_PTH @"acomment" // 没用到
#define AFAV_SEND_PTH @"afav" // 没用到
APP设置里面有发送时机的设置: 有启动时发送, 和间隔时间发送两种
会优先网络同步的信息，然后是用户自己配置的信息，如果都没有，采用sdk内置的默认值，如下如：
#define policyInterval @"INTERVAL" // 定时器间隔发送
#define policyBatch @"BATCHING" // 启动时候会发送
UDID获取使用两种方式, 如果支持idfa则取idfa, 否则使用idfv_时间戳的形式, 后者存储到keychain, 前者未进行存储.
idfa:
每个设备只有一个IDFA，不同APP在同一设备上获取IDFA的结果是一样的，它是系统存储的。设备重启不会产生新的IDFA
但IDFA存在重新生成的情况:
用户完全重置系统(设置程序 -> 通用 -> 还原 -> 还原位置与隐私)
用户明确还原广告(设置程序-> 通用 -> 关于本机 -> 广告 -> 还原广告标示符)
苹果禁止不使用广告而采集idfa的情况。
idfv:
com.example.app1和com.example.app2,只有最后的后缀不同，所以会产生相同的vendor ID
注意：如果用户将属于此Vender的所有App卸载，则idfv的值会被重置，即再重装此Vender的App，idfv的值和之前不同
keychain:
keychain不是存储在手机的沙盒内，而是手机的某个公共区域，手机重启和应用卸载，都不会对这片存储区域造成影响，因为是加密 存储不存在被其他应用修改的问题，所以就有人拿keychain来存储唯一标识
综上总结：
sskeychain+idfv 用来保存唯一标识，无论卸载或重装都不会改变，但不同vender生成的标识不一样，一部手机会有很多不同vender。所以我们可以先获取idfa（因为有苹果审核可以做个宏给开发做选择），获取不到的情况下在使用sskeychain+idfv。
startPage里向list中添加对象, endPage时只取last和end的page进行比对, 是否合理.
他的逻辑应该是，一个页面展示和销毁分别调用startPage和endPage,这是一种情况。另外一种情况是打开页面A调用一次startPage，在该页面又打开另外的页面B，上一个页面仍然能看到或者没有销毁。此时如果销毁B，在销毁A，那么仍是合理的。
endpage的remove按照先进后出的顺序，也就是view的生命周期符合栈的规律就是合理的。
sessionBgTimeOuts 是什么字段
唯一使用到的地方：
if ([[[mAgentConfig sharedInstance] sessionBgTimeOuts] intValue] < space)
self.sess_time = [NSDate date];
}
这里统计sess_time，值代表进入前台激活的时间，如果离线时间大于于sessionBgTimeOuts的值，那么会sess_time会重新被赋值 。这里sessionBgTimeOuts意思是：App进入后台多久后刷新sess_time。
appList 有什么用么.
NSArray *targetList = @[
@{@"name": @"微信", @"urlName": @"weixin"},
@{@"name": @"facebook", @"urlName": @"fb"},
@{@"name": @"微博", @"urlName": @"weibo"}
];
if ([[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:url]]) { if (isDebug) NSLog(@"install %@", name); [dic setValue:name forKey:[NSString stringWithFormat:@"%d", count]]; count++;
这里appList应该是线上配置完了后，下发到sdk通过canOpenURL来遍历应用和手机已装app匹配，然后发送 [MAgent onEvent:@"APPLIST" attributes:dic]日志。目前无法使用好像ios10这种方法给禁止了。
MonitorButton 具体是什么.
监控一个view里面的button事件的点击，monitorList是从平台配置获取到的，数组元素是type是button，代码里的button的tag要和平台的tag一致才能绑定事件。目测是无埋点。感觉有点简单粗暴，没有测试过。
watchNow 里面调用到很多个uploadInfo, 具体是什么样的发送流程.
多个uploadInfo，每个代表不同的本地文件，文件名不一样，发送的地址不一样。
文件里存的是数组，把每个元素拼接成字符串，中间用/n隔开，然后把字符串序列化成二进制，在通过gzip方式压缩，增快传输速度和减少服务器使用带宽。
发送的一些配置是否都能生效, 是在哪里控制发送流程的, 目前只发现了发送时机和发送网络状态的配置生效.
如app发送时机问题：
会优先网络同步的信息，然后是用户自己配置的信息，如果都没有，采用sdk内置的默认值
uploadInfo 中如果遇到正在写入的情况就停止发送, 正在发送的情况没有操作, 是否正在发送中的状态对下次发送没有影响.
无影响，justWriteToFile是在主线程做的，uploadInfo这个方法也是主线程判断isWritring,所以说写数据后再执行watchNow。他们是顺序执行下去的，建议优化把写数据和上传放在一个串行队列里面。
要发送的数据存到本地, 存了几个文件, 分别存了些什么
如问题1
发送的数据分了类别, 现在是否用到了, 在后台页面能体现吗.
onAppEnd 中把clickList列表中的数据, 存了好几个文件, 发送的时候, 这几个文件中的数据又都进行发送, 是怎么回事.
// for(BehInfo *info in self.clickList) // { // info.isaborted = @"1"; // [self justWriteToFile:info sendPath:SHARE_SEND_PATH]; // } // for(BehInfo *info in self.clickList) // { // info.isaborted = @"1"; // [self justWriteToFile:info sendPath:PUSH_SEND_PTH]; // } // for(BehInfo *info in self.clickList) // { // info.isaborted = @"1"; // [self justWriteToFile:info sendPath:COMMENT_SEND_PTH]; // } // for(BehInfo *info in self.clickList) // { // info.isaborted = @"1"; // [self justWriteToFile:info sendPath:AFAV_SEND_PTH];
以上代码需要注释在uar中没有用到
clickList 这个数组没有初始化, 没有写入操作, 只有读取操作, 会产生些无效操作, 是不是没必要.
是的，因为list是那种有可能会存多个事件情况，clickList意思是推荐点击，是瞬时事件是没有必要的，可以删掉
