本文主要讲述一种系统思路，对于很多公司没有足够的技术人员来搭建一套完整的全链路日志系统情况下可以参考，对于细节实现方面，大家可以根据自己产品的特性来设计，如果还有疑问，可以发邮件到我的邮箱ufolca@163.com或者加我微信号【the51alien】备注一下“天梭”，第一次发文，如有不妥之处，还请指正
痛点
|任何一项技术的实施，如果不能解决某些或某个问题，那么它将没有任何价值
相信很多移动端开发人员会遇到一个问题，客服收到用户反馈，APP的某个页面打不开了，或者某个按钮点不了等等非崩溃性质的功能异常，在没有该用户全链路日志的情况下，我们一般会采取以下几种处理方式
1. 根据经验去代码中检查逻辑，看是否有边界情况没考虑到
2. 根据用户的场景描述，在测试环境模拟一份相同的数据看能否复现
3. 获取用户授权，使用登录令牌进入问题场景看能否复现（没有办法的办法，大部分用户都会拒绝）
如果上述几步都无法解决，相信很多人会是下面表情
那么有没有一种比较快速直接的方法来帮助勤劳善良的程序猿(媛)来解决这些问题，答案是有-利用巨人的肩膀
天梭系统流程图
大家会发现里面有三个巨人来支撑整个系统
巨人 | 职责 | 要求
云推送平台 | 对目标用户下发日志收集指令 | 到达率高，有联合唤醒功能
云资源存储平台 | 存储出现异常的某天APP链路日志 | 容量大，安全性高
热补丁分发平台 | 下发补丁 | 成功率高，实时性高，兼容性高
接下来我来一一介绍每个系统的任务和机制
●蓝线部分-客户端每天将用户的操作和网络日志有序,压缩,加密,追加的方式写入本地文件，可以手动埋点或者AOP自动化埋点，网络日志相信很多人都在使用okhttp,可以在拦截器里进行日志的写入，所有操作一定要在子线程里执行，文件名以["."+app名+"-"+用户id+"-"+日期(yyyy-MM-dd)]的隐藏方式,后缀采用jpg来伪装成破损图片
●黄线部分-从客户端开始，相信到技术人员这个节点都通俗易懂，最后到推送平台我采用的是推送tag，而不是推送id作为参数，也是考虑的市面上普遍存在的多客户端登陆情况，推送tag-推送id是一种一对多的映射关系，每个用户登录一台设备都会手动将该设备的推送id打上tag，我这里的tag就用的是用户id
●红线部分-APP会收到一条特殊json格式的推送，例如{"data":{"type":1024,"date":"2018-06-05"}}，客户端的推送系统捕获到这条指令后调用日志系统的上传方法，选择对应日期的日志上传的云存储平台，这样技术人员能够拿到这个日志，通过本地的工具，将文件内容读取，解密，解压缩出来，将问题相关的功能数据mork到APP里复现
●黑线部分-如图所示，相信很多人都会操作，就不过多阐述了
问题
理想是美好的，现实是残酷的
1.推送问题，相信这是android开发人员最头痛的问题，如果技术人员下发推送指令后十分钟内没有看到用户日志，那么也只能通过客服提醒用户再次打开APP，一般好的推送平台的离线推送会再触发一次
2.补丁问题，补丁修复的实时性和成功率决定了最后一步，否则只有发新版本了
3.日志系统建议只保留最近一周的日志，防止产生大量垃圾文件
后记
茶余饭后的谈资
天梭这个名字来源，是我脑补出的一个系统场景，像一个梭子在 用户手机+3个平台服务器的虚拟天网中来回穿梭
