如何避免技术踩坑

一、导读

相信很多技术同学都会花费几个小时、一天甚至几天的时间去攻克一个异常情况后愤而发出“好坑啊”的无奈和抱怨，下面我就给大家讲讲这个问题以及我们该如何避免，

 

二、技术学习

       学习就是将自己不会的、或者不了解的变成会的、明白其机制的过程。在it行业，这种能力显得尤为重要，光语言就有上百种，按语言特点有面向对象的和面向过程的；按应用场景又分为前端、后台、客户端、脚本工具等。更不要说基于各种语言的开源框架，第三方库，技术平台，浏览器，操作系统等“重器”。组件化，微服务，容器化，云计算等各种新花样层出不穷，新技术新思维永远在路上，无尽头。

        技术学习的主要方式是阅读材料，读完材料，感觉像是懂了，知道了新的特点、用法和思路，其实这是一种错觉，距离真正的明白还相去甚远。下面我以实际工作情况中的三个案例来说明，由于之前从事安卓端的开发工作，所以案例基本来自于安卓

1、系统api熟悉了解

      比如面试经常会问的String，StringBuilder，StringBuffer，API里面不会告诉他们的区别和联系，需要你自己去发掘他们的异同，使用不当的话，在某些情况下还是会影响性能，甚至出问题

      比如Android 线性布局中的layout_weight属性，api和官方文档都没说其实这个属性依赖于layout 的 orientation和子view的顺序

      比如java list的循环过程中，有些容器不能随意删除，否则会引入异常

      如此等等。。。

 

2、性能优化工具使用

      做性能优化的时候，去网络上搜罗资料，大部分资料都会告诉你，首先需要定位耗时操作，可以利用系统提供的methed tracing 工具。

第一步：使用Debug.startMethodTracing和Debug.stopMethodTracing添加到运行代码两端

第二步：确保申请有sdk卡写权限

uses-permission android:name=“android.permission.WRITE_EXTERNAL_STORAGE”

第三步：坐等sd卡拿到trace文件，使用ddms工具打开查看

 

于是你按照资料说明的使用步骤将两行代码加载了代码执行逻辑的两端，编译运行，程序跑起来了，你哼着小曲坐等耗时元凶分分钟显现。但真实情况可能是：

     2.1、为何没有.trace文件，网上都是说可以的呀，十万个为什么跃然脑海，于是开始了千辛万苦的排查，试着去网上看看有没有类似的问题，直到你翻阅了源码，发现了下图中的逻辑，你才恍然大悟，原来系统会对context进行判空操作，如果不为空，系统将选择ExternalFilesDir作为trace文件放置目录，功夫不负有心人，直接去ExternalFilesDir去拿好了，小曲儿又被你哼起来了，马上就能破案了，能不高兴么。

     2.2、你去了ExternalFilesDir目录下一看，竟然还是没有，一个大大的问号挂在脑瓜上，算了还是去源码里面看看吧，你意外发现了还有一个buffersize，默认值8MB, 推测是数据超过了8MB , 于是，通过扩大buffersize等方式不断验证，终于成功生成了trace文件，至此，你再也没了刚开始的欢喜劲儿，被一波三折的折磨的没了心情，只想说一句“真坑”。

 

3、使用第三方库

     原本以为照着集成文档的步骤操作一遍不就行了么，但现实是：

     第三方库中的配置、依赖很可能和现有项目有冲突

     集成文档并没有说的很细致，比如某些步骤一定要在最开始的地方，而且要多次使用，否则会出现各种异常情况

     第三方库提供了多种集成方式，比如android sdk、 http api接口，可能现实中在某些情况下，你会在后台接入api接口，客户端集成sdk，但两者不能混用，不能针对一个事件操作两种接入方式

四、踩坑避坑分析

        以上种种，都不能简单的看看材料，看看书籍就能轻松搞定，外部的学习资料总不是100%适用于现实环境，现实总是更复杂，状况百出。于是乎，每个从业者都有一部自己的血泪踩坑史，“坑、真坑”的哀叹不绝于耳。当然了，踩的坑多了，自然踩出了经验，踩出了火焰金晶，学会了绕坑走，甚至还能给后来者指导一二。

        为什么我们会踩坑呢？有的同学会说，不熟悉呗，对，就是不熟悉。那是不是加强熟悉就行了，是这个道理。比如一个开车的人和一个造车的人谁对这个车的各个功能组件更熟悉呢？肯定是造车的人，因为开车的人只是会用汽车的功能，而造车的人则负责提供功能给用的人，一个是会用，一个是提供给人用。类似于下图，一个知识事物（我这边将上述的要学习的或者了解的技术知识统称为知识事物）分为核心区和边缘区，围绕知识事物的人可分为造物者和使用者，造物者是从内往外看，从核心区望向边缘区；使用者则是从外往内看，从边缘区望向核心区。造物者一般是一个合格的使用者，使用者则不全是合格的，合格与否去取决于深入到核心区的程度。

        回到刚开始讨论的问题，其实我们的目的就是要少踩坑，基于上图中的模型，我们该如何做一个合格的使用者。

两种方式：

    1、站在造物者的角度

    第一种方式很显然，我们直接以造物者的角度从核心区开始了解，直到变成一个也可以造出此事物的造物者，这是最彻底的方式，比如我们直接阅读api的源码实现，看底层实现原理，这种方式的时间开销特别大，而且比较辛苦。折中的方式是我们有时可以站在造物者的角度去分析有些功能能不能实现，比如虽然我是搞Android开发的，但是对于某些功能在前端后台领域能否实现，还是可以直接判断的，尽管从来没有搞过前端后台，但是计算机基本的运作方式还是了解的，这些就足够了。

    2、做善于使用效果反馈工具的使用者

    还有一种方式就是我们还是从使用者的角度去深入事物知识，这个时候就需要一个及时的效果反馈工具，比如打印日志，追踪调用堆栈，不同机型的兼容性测试，这种方式只能尽量逼近核心区这个黑盒，优势是时间开销相对小

    在现实情况下，这两种方式该用哪种呢？我觉得要看情况，甚至两种方式可以交叉使用。比如

    对于“系统api熟悉了解”，我个人认为，对于一个系统的核心api还是要使用第一种方式来学习，比如Android的整体架构，应用进程通信原理等，对于string、stringbuidler、stringbuffer的区别，则需要两种方式交叉使用，实际测测差别多大，再进去源码内部看看如何实现的。

    对于“性能优化工具使用”，我觉得开始就使用第二种方式进行，直到出问题了，再使用第一种方式解决。

    对于“使用第三方库”，还是以第二种方式进行，直到出问题了，再使用第一种方式解决，但如果源码未公开怎么办，那我们就退而求其次，以造物者的心态想象如果是自己封装了这么个库会如何实现，也许就能解决问题。

五、结语

    写这篇文章的目的其实是想让自己在后续踩坑的时候，不再说“坑，真坑”，而是会说“原来是这样啊”，变的更加从容淡定。明白自己的跳坑，其实是不合格使用者的表现，当然不排除造物者本身造出的事物就有瑕疵，容易让使用者陷入不合格的地步，但据我的经验，没有完美的造物者，没有完美的知识事物供我们随心所欲的使用而不出错。希望本文提到的“站在造物者的角度”和“做善于使用效果反馈工具的使用者”两种方式能带来帮助。