昨天被问到一个内存泄漏问题，正好近期在录制性能优化相关的课程，用我讲的方法来分析问题😯
有时候内存泄漏真是措不及防，潜伏的很深，不用工具的话压根感知不到，往往只有在错误日志里才看得到，不过那个时候也已经晚了。
先上个LeakCanary的warning图
从图上来看，很直观，MainActivity泄漏了，持有的是MyLinkMovementMethod，还是个static变量。
这么看起来很容易解嘛，在MyLinkMovementMethod里把context引用去掉不就好了么，有什么好问的。
然而看了代码，我也有点懵逼，大家也来瞅瞅。
这个MyLinkMovementMethod类中只有一个成员变量TouchableSpan，并没有持有context呀，我被误导的去翻了它的父类LinkMovementMethod，发现并没有任何成员变量。那这个锅只能是TouchableSpan来背了。
说来也是诡异的很，当我要TouchableSpan类的截图时，对方给我的是这样的：
wtf, 这span没有持有context呀，为什么会泄漏？这不科学。onClick(View)也没有泄漏的可能。于是我又让对方发TouchableSpan类给我
好吧，我也不知道问题出在哪了，被对方牵着走了一路，没线索了。后来他一直在纠结widget.getContext().startActivity(intent)要不要换成applicationContext，这又是另外一个故事了。。。不管用什么context，这里都不存在泄漏。
最后没辙，好歹我也撸了相关课程，连个内存泄漏的原因都找不到，我不甘心啊。。
于是我让他把相关代码都发给我。。。看了代码内心都是崩溃的
内部类。。。内部类。。。非静态内部类能持有外部的引用啊。心塞。
我们再把整个泄漏的过程梳理下。
需求是textview能局部点击，整体的onClick事件无法满足，所以需要ClickableSpan来标记。
于是自定义一个TagTextView，在TagTextView中有个内部类Span来监听局部点击，但Span是如何知道自己被点击的呢？用MyLinkMovementMethod来处理textview的onTouch事件。解决方案是对的，但是代码写的有点渣。
MyLinkMovementMethod为单例，TouchableSpan一旦被实例化出来，除非手动置为null，否则不会释放，而由于它是TagTextView的内部类，所以持有这个TextView的引用，TextView是被MainActivity创建出来的，最终导致MainActivity无法被回收。
MyLinkMovementMethod->TagTextView.TouchableSpan->TagTextView->MainActivity
现在再来看LeakCanary的warning
刚好能对应上了吧，有个工具能帮你做分析挺好的，不然review代码都不一定能找出来。
至于怎么解决？方法倒是很简单的：
- TagTextView.Span变为static，静态内部类不持有外部类的引用，就像Handler要用static一样。
- MyLinkMovementMethod中不能有Span这个成员变量，让Span引用只存在于某个方法的作用域中。
- 当TagTextView的TouchEvent为UP时，应手动将Span置为null。
这算是一个比较有代表性的内存泄漏了，如果你对内存泄漏的概念与成因还不够熟悉，可以参考Stay录制的性能优化合辑，从java角度去讲内存泄漏你肯定能看懂。
另外有一点需要改进的，tag的点击事件应该传递到外部去，不应该由Span自己处理跳转到另外一个activity中去，这不符合设计原则，如果某个Tag跳转的activity不是固定的怎么办呢？自定义View的职责应该是单一的，只负责接收事件，解析事件，具体的解决事件应该由上层来处理，不然就没法复用了。
