卡团 CTO 曹雪竹：互联网＋物流的性能优化实践分享

[cloudwise]

“电子商务在蓬勃兴起推动着我国物流行业进入发展的快车道，以顺丰为代表的专业快递公司和依附于电商巨头的菜鸟网络不断倒逼传统物流企业，传统仓配体系依靠成本价格竞争的粗放式发展模式难以为继，在后电商时代，电商仓储、城乡配送、大件物流、智慧化物流等都将成为物流发展的重点，物流行业进入互联网＋转型的风口浪尖。”

卡团物流是业内互联网＋物流创新企业，公路货运无车承运人、长途货运行业的 Uber 是对卡团的最好描述，卡团通过自媒体平台“卡团”公众账号汇聚近 10 万卡车车主作为运力池的最好储备，通过移动互联网手段将运力整合，为第三方物流企业及生产制造企业的运输需求提供更加高效、更低成本、更为透明的长途干线运输服务。面对飞速增长的业务需求，卡团是如何确保移动端 APP 应用性能体验的呢？

下面是卡团 CTO 曹雪竹先生针对互联网＋物流行业特点，为我们带来的性能优化经验分享。

大家好，我是曹雪竹，现在在卡团负责技术方面的工作。首先先简单做一个自我介绍，我本科和研究生先后毕业于南开大学和中国科学院，专业是计算机。在做卡团这个项目之前，我在人人网工作，负责过人人网主站的 LBS 和移动部门相关技术开发。后来内部转岗到了糯米网，就是现在的百度糯米，负责订单相关的工作，也就是说大家在糯米网下的每一单都是由我们提供技术保障的。

去年在克强总理的感召下，我从百度糯米离开出来创业，一直在互联网物流这个领域发展，第一个项目很快就死掉了，卡团是我的第二个项目。卡团是从去年年底开始的，虽然时间不长但发展很快，所以对技术的需求和挑战也很大，而移动互联网要的就是一个快字，所以不可能所有东西都自己做，相信做互联网行业的都有了解。





>>>>
卡团性能监控的选择

我们的移动互联网的监控分为两部分，一部分是对外的监控，就是卡团发出去的移动端， Web 页， H5 等前端的监控；另一部分是对内的监控，包括对卡团服务器的运行状态， cpu ，内存，网络，存储，网络端口等基础设施，还有各种服务，数据库，缓存，队列，配置中心这些。

对内监控因为服务器、存储和各种应用服务都在云上，而大多数的云厂商都提供了基本的监控告警，所以不需要太多关注。当然，如果有条件还是要自己部署一些监控宝这样的第三方监控，毕竟各家云平台宕机事件也是时有发生，不过这不是今天讨论的重点。

透视宝主要解决的是我们外部的监控的问题，因为 APP 发给渠道，安装到用户手机之后，有些数据我们可以自己通过埋点统计到，比如接口性能监控这些，但是有些是无法很方便监控到的，比如用户的地域分布，运营商分布，网络分布，还有用户操作等等。这些功能如果自己做至少要花 3 个人月，时间和成本就是个大问题，而用外部工具，一下子就搞定了。

有人说数据安全问题，这个早些年确实是问题，但是在现在这个时代我觉得不是问题。如果单单从安全的角度来讲，那当然是越安全越好，但是大家也都明白一个道理，那就是没有绝对的安全。而且在当今的互联网时代，如果单纯地被抓一些访问就盗走核心数据的话，那我肯定会怀疑这个 APP 本身的商业价值了。

卡团上线的时间虽然不长，但是透视宝还是让我们看到了一些亮点，比如它的用户地域分析，这个可能跟我们的业务有关。因为我们是做互联网物流的，所以发展运力对我们就很重要。如果一个地方的用户多了，而我们还没有在这个地方开展运力的话，那么我们的线下团队就要立马跟上了。当然，我相信很多的互联网应用都有类似的场景，而且很多公司自己会开发相应的功能。不过还是那句话，这是一个投入产出比的问题，我觉得对于初创期的公司来讲，用透视宝还是能立竿见影的。

还有一个就是用户行为流程的分析，做 APP 的都知道，产品设计时都会设定了一个用户操作的主流程，但是用户是不是真的按照产品设计的流程来用呢？很多时候我们并不知道，所以透视宝这个功能相当于帮助我们实现了一个沙漏模型。

最后说说性能优化这块儿，我们关注的主要是移动端的性能，用透视宝可以看到哪个页面加载慢，在什么网络条件和地域下加载慢。上线以来我们也做过一些例子，比如说我们城市列表的加载，发现在某些机型和情况下就会很慢，再有就是因为 CDN 的一些问题和网络节点问题导致 APP 很慢。

关于崩溃也是一个很重要的点。对于 APP ，尤其 Android 系统来说，崩溃是太高频的事件了，所以透视宝能完整地记下崩溃日志及相关机型和环境，这对我们来说是十分有用的。



>>>>
不同业务关注不同的性能表现

我们都知道，不同的业务应该关注不同的性能点，所以技术在做性能监控的时候一定要牢记这一点。比如在人人做社交，关注的是用户刷新鲜事儿、刷 feed 之类操作的性能。这是非常关键的，因为这是人人用户非常高频的一个动作，而且是主要的用户流量入口。

到了百度糯米，关注的主要是团单，包括订单的列表、订单的单品页，尤其是下单过程的性能。因为团购都会有各种优惠券、各种红包，用户在选不同订单组合的时候、选不同份数的时候，我们对优惠券、红包的计算是比较关注的，如果长时间不能算出一个价格来，或者让用户等三秒钟才出来一个价格。那肯定好多用户就去下别的单子了。尤其是在糯米搞打折促销和秒杀活动的时候，对用户体验和性能要求就更高，因为用户一两秒种都加载不出秒杀页面的话，会有两种情况，要么用户流失，要么用户疯狂的点击，给服务器造成更大的压力。

而对于互联网物流，这个用户群体跟我之前做过的其他的产品的群体有很大差异，其他产品的用户群都偏年轻化，对移动互联网的接受程度比较高。而卡车司机这个群体，他们的手机性能比较低，不会关注团购那种秒杀场景，也不有社交 APP 的刷新场景，他们只关注自己的生意。

当网上有一个新订单，卡车司机去抢这个订单，那么他肯定希望点一下就立马告诉他是否抢单成功。如果你没有反应，或者是一直在那转，那么卡车司机疯狂的点两下以后，可能就一边儿骂这个产品，一边就把 APP 给卸载了，这就是卡团用户群体的特性。

而且，作为长途运输有些特殊场景，比如卡车在途的位置监控，因为卡车司机的手机流量比较少，比起性能他们更关注省流量，那么我们根据货主要求上报他们的位置的同时，要帮他们尽量节省流量，同时还要节省耗电量，这是卡团跟做其他业务不一样的地方。



>>>>
有哪些做性能优化的小技巧？

性能优化这块儿我目前主要关注服务端，觉得几方面需要大家注意：

首先，你自己的代码逻辑性要清晰，要尽量减少消耗，包括对存储的消耗，对网络的消耗，对计算性能的消耗等等。

另外一个就是接口的设计。比如我们能用一个接口解决的事情绝不使用两个接口。我们的客户端都做的非常轻，我们很多工作都封装在服务端。保证我们前后端之间用最小的流量、最少的开销，完成一个页面的加载和一次请求。

代码优化上队列的使用也很重要，比如我们用队列来降低接口的开销，后端大量使用缓存，降低数据库的操作。我们很多的临时数据、非必要都是放在缓存里，只有一些必要的数据才会写入数据库。

其实每一种技术都有很多性能优化的小技巧，我们用 redis 、 mysql 、 mongodb 、 nosql 都有相应的优化的技巧，这里就不一一详述。



问：你们使用透视宝，对 APP 中的每个线程中的关键方法怎么监控?

答:从两方面来解决，透视宝的用户行为监控粒度是以 view 视图来监控的。另外，如果线程是跟服务器有交互的，你可以从网络请求看出线程相关的性能问题。
目前我们是没有监控线程，因为我们是做互联网＋的， APP 不是特别复杂。如果是做游戏或者是其他交互性强的业务，那种情况下 APP 的内部功能要比我们的复杂很多，需要进行深度监控。

问：假设我按下一个按钮，后面有很多步操作，有些在线程里，最后以主线程的回调结束。由于跨线程，可能上一个 trace 未结束，下个又来了，我想监控这类类操作的性能，该如何做？

答：目前透视宝是针对崩溃、 ANR 卡顿现象发生时会抓取所有线程堆栈信息。我们也在分析崩溃日志的时候，下载过崩溃日志，从里面看到过崩溃的时候都有哪几个线程，线程的堆栈都有哪些。

问：对于 Android 6.0 以上系统的 ANR ，你们怎么解决？

答：我们没有专门做 6.0 以上的卡顿问题，是因为卡车司机的手机版本还没有这么高，主要集中在 4.4-5.0 之间。

这里有些通用的方法。比如我们卡顿的地方主要是耗时操作，而卡团耗时的操作并不多，主要是上传照片的时候。首先从接口上和其他接口不一样，是先拿地址再传照片，有了地址照片可以异步传输。而且我们的业务场景是即使照片传不成功，对主要业务也没有影响。 所以我们从业务上和接口上，把这个问题规避了。

而且很多时候安卓系统的卡顿除了一些程序上的问题，更多是启动时要加载很多东西。这时候我建议你在启动的时候做个欢迎界面，给你的页面加载再留出一定时间。这是从用户体验的角度上来讲。

从纯技术角度来讲，我觉得是耗时操作和易崩溃操作都不要放在主线程中操作，可以做成异步的或多线程池，用 Handle 来处理这个工作线程，安卓通用的几个方法都可以做。

最后感谢大家的聆听，今后大家有什么想交流的可以随时加我的微信，想了解卡团的话也可以在各大安卓市场搜卡团下载，卡团的货主端、卡团的司机端都有。不过我们的产品目前不提供开放注册，需要邀请码，所以大家想要邀请码的话可以线上找我。