在日常的开发过程中，总有很多莫名其妙的问题出现在别人的手机上，就好像上帝开的一个玩笑。然后我们拿着别人的手机连上mac，重新编译后，问题又神奇的消失了，这时候我们只能摇摇头，问题不能重现，但这并不代表问题已经解决。
很多时候，比如打点情况，并不能直观的提供给测试人员验证，很多时候需要日志来提供一些验收，而在非联机的情况下日志的输出查看又比较困难。
经常有用户反馈卡顿等情况，而我们的测试机又有限，难以覆盖足够的场景，用户的反馈又比较模糊，并不专业，所以很多卡顿往往在猜测中并没有被解决。
由于我们项目目前的状况，是没有那么多的人力来配合做一套BI系统。所以这里我做了一套小型的日志和系统运行情况手机系统。
功能
init.png
设计之初就是设计成一对多的模式，所以可以支持多台手机连接到同一台电脑上，其实还可以更疯狂的连接方式，架构部分会详细描述。
home.png
每个设备双击打开都是一个窗口，每个设备只能打开一个窗口。
窗口的首页是几个基本统计项，内存、cpu、FPS，最短1秒就会有一次统计数据。
net.png
请求部分是使用URLProtocol来做的，所以只能统计http类型的请求。
net_detail.png
这里是每个请求统计的数据，目前还没有好好整理。
net_stat.png
这里是对所有请求的一个分析，和上面一样，其实没有好好的利用数据。暂时没有想出来怎么很好的利用这一部分的数据，如果有想法，可以告诉我。
runloop.png
这里统计的是主线程一个runloop运行时间超过1/60s的情况，项目之前有部分卡顿就是因为代码问题，导致主线程产生大量运算形成的。
这里如果时间超过一定阈值（暂定为0.5s），此时会触发截屏，所以在严重卡顿的时候会自动把卡顿的界面保存下来。
file.png
这是一个简单的文件管理系统，从应用沙盒的根目录开始。
file_download.png
同时可以选择某个文件进行下载，直接保存到电脑中。
console.png
这是连接日志输出系统的。debug日志会输出到3个地方：
* xcode console
* system log，这个可以从mac的日志查看器里面看
* socket log
同时我们可以选择过滤器，这样就会展示相应的日志。这里的过滤系统是根据我们项目中特定日志格式来做的，实际情况可能需要不同的定制。
jspatch.png
在苹果爸爸还没有封杀jspatch的时候，我们为了验证patch真是煞费苦心，需要在工程中加入代码，然后计算md5验证。这里可以直接写patch代码，点击按钮就会直接传输给手机直接应用，非常方便。
架构
structure.png
大致的架构如上图所示，其中通信方式使用的是socket。可能使用websocket这种比较成熟的方案会更好，但是想自己写网络层，所以就自己写了长连接部分。（目前这部分留下点坑，服务端处理分包粘包偶尔会有问题）。其中socket内容为双方通信，不能按照我们平常客户端-服务端这样的架构来看待，手机端（暂且称为客户端）也需要处理服务端下发的请求。
手机端
是一个简单的长连接和部分处理请求的服务，和服务端保持一对一的链接。
服务端
服务端其实包含的是两部分，nodejs和pc端，这里先说nodejs。其实这两部分是完全分离的，并没有任何关联。这里服务端就特指nodejs。它包含两种通信模式：
1. rpc 进程间通信，是和`pc端`通信的方式。
2. socket，是和`手机端`与其他`nodejs`端通信的方式，对，是和其他`nodejs`服务，所以这里可以和我们的网络模型一样，组成星状结构、环形结构、网状结构。（没有真实的测试过超过两个端的连接，不能保证性能如何，也没有对此进行优化）
在刚开始的设想中，运作方式有两种：
1. 自己独立和多台手机通信
2. 找一台电脑作为独立服务器，其他人可以连该电脑，这样我们可以把多个数据都集中到一起，可以有人专门管理
pc端
是由Electron+React组成，选择这样的技术是因为electron的跨平台特性，同时React又是我比较熟悉的一种前端框架（React-native又是移动端的一种统一化方案）。技术内容没有什么特别的，有部分数据量多的列表会导致卡顿，这个需要做特别优化。
通信数据格式
分为3种类型：
- request-response模式，和我们最熟悉的http请求一样，不过是双方通信模式
- register模式，是注册-持续上传的模式，目前已经去除了注册这一步，会把所有数据一直持续上传服务端。
- 代理模式，是第三方服务端希望通过该服务端访问手机端，会把请求数据包装一层。这是纯粹服务端-服务端之间的通信格式。
总结
最初的想法是在debug版本和内测版本都应用该系统，统一收集和处理数据，对部分问题设置报警系统。多个pc端可以直连服务端，这样可以多人同时查看当前所有设备中存在的问题。就能够在上线前尽可能的覆盖各种网络、机型等情况，尽可能早的发现问题，避免上线后才发现bug。由于工作量大，性能也没有评估（node支持的并发数应该还是不错的，瓶颈可能会在带宽），对数据处理的方式也没有什么经验，所以现在还是停留在个人使用中。
有什么好的建议与意见，欢迎给我反馈。
网友评论