Android-事件体系全面总结+实践分析内容太过真实
Posted 古斯汀，流年
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Android-事件体系全面总结+实践分析内容太过真实相关的知识，希望对你有一定的参考价值。
开头
相信大多数互联网的从业者都有着这样一个梦想：进大厂，获得丰厚的薪酬，和更优秀的人一起共事，在技术上获得更快的成长。
**然而部分人其实一直都陷入了“穷忙”的困局，觉得自己每天白天黑夜都在工作，高强度输出，但是却并没有获得机会的眷顾。**久而久之，既不知道自己忙什么，也不知道怎么能停下来。
这并不是时间的过错，而是因为把解决方式过多押注在技术上，然后继续在工作上不断循环，这样的状态让你极度缺少另一个层面的思考。
如何去打破这种僵局呢？很多人建议多读书，但是从哪种类型的书开始看又该看谁的书呢?说实话，很多技术书写到最后大同小异。但是万变不离其宗，源代码以及参考手册需要多些钻研，扎根底层是程序员应有的素养。
现在互联网讯息如此便捷，学习资料从来不缺。硬盘里都是各种学习资源，上下班坐地铁，还要刷技术视频。但是泛看不如精看、精读。
这里我总结了一些Android核心知识点，以及一些最新的大厂面试题、知识脑图和视频资料解析。
需要的**小伙伴私信【学习】**我免费分享给你，以后的路也希望我们能一起走下去。
前言
自己在做SpEditTool：一个支持表情，@mention，#话题#等功能的EditText控件，这个项目的时候出现了一个很奇怪的问题
- EditText输入表情过多的时候,从中间开始删除表情,会出现非常卡的情况，而从最后开始删除则不会
对比微信的表情输入功能之后，发现微信这个浓眉大眼的也有这样的feature（微信都有的现象那能是bug嘛，大雾。。。）
不过自己写的东西有问题心里总归不爽，断断续续折腾一个礼拜终于把这个问题解决了，整个过程中自己感觉受益匪浅，记录下分享给大家
最初的实现
setOnKeyListener(new OnKeyListener() {
@Override
public boolean onKey(View v, int keyCode, KeyEvent event) {
if (keyCode == KeyEvent.KEYCODE_DEL && event.getAction() == KeyEvent.ACTION_DOWN) {
return onDeleteEvent();
}
return false;
}
});
private boolean onDeleteEvent() {
int selectionStart = getSelectionStart();
int selectionEnd = getSelectionEnd();
if (selectionEnd != selectionStart) {
return false;
}
SpData[] spDatas = getSpDatas();
for (SpData spData : spDatas) {
if (selectionStart == spData.end) {
Editable editable = getText();
editable.delete(spData.start, spData.end);
return true;
}
}
return false;
}
SpData中保存了表情对应的文本的开始位置和结束位置，直接使用Editable.delete()删除
问题定位
粗略定位
先打Log粗略定位下问题，把自己觉得可能会造成卡顿的地方都加了log，发现卡顿的罪魁祸首就是editable.delete(spData.start, spData.end);这一行
精确定位
再准备顺藤摸瓜找到卡顿的真正元凶，但是代码跳着跳着就到SpannableStringBuilder和TextView这两个超大的类里去了，在哪卡的还不知道自己就绕晕了，只能靠性能检测工具先具体定位到问题再进一步分析了
这里用到了androidStudio3.0自带的Android Profiler，具体的用法可以看AndroidStudio3.0 Android Profiler分析器
FlameChart
先通过火焰图看看最耗时的调用栈是哪一条
图上可知ChangeWatcher.onSpanChanged()->ChangeWatcher.reflow()->DynamicLayout.reflow()->StaticLayout.generate()这条调用栈最为耗时
CallChart
再看看调用顺序图
- ChangeWatcher.onSpanChanged()被调用了多次，会多次调用DynamicLayout.reflow()
- DynamicLayout.reflow()中会调用多次StaticLayout.generate()
有一点疑问，我看DynamicLayout源码，每次reflow()应该只会调用一次StaticLayout.generate()而且都是在主线程，CallChat却显示了多次，而且调用次数没看出啥规律，不知道有没有大神可以帮我解下惑
BottomUp
其实通过上面两步基本已经定位到问题了，再在BottomUp的表格中确认一下
StaticLayout.generate()中有这样一段代码,这下实锤了
if (spanned == null) {
spanEnd = paraEnd;
int spanLen = spanEnd - spanStart;
measured.addStyleRun(paint, spanLen, fm);
} else {
spanEnd = spanned.nextSpanTransition(spanStart, paraEnd,
MetricAffectingSpan.class);
int spanLen = spanEnd - spanStart;
MetricAffectingSpan[] spans =
spanned.getSpans(spanStart, spanEnd, MetricAffectingSpan.class);
spans = TextUtils.removeEmptySpans(spans, spanned, MetricAffectingSpan.class);
measured.addStyleRun(paint, spans, spanLen, fm);
}
问题分析
TextView这块相关代码比较复杂就不一行行分析了直接说结论
- ChangeWatcher实现了SpanWatcher接口，它是用来监听TextView中Span发生变化的
- 当从中间删除一个表情，被删除表情后面的所有的ImageSpan位置都发生了变化，每个ImageSpan变化都会触发一次
ChangeWatcher.onSpanChanged()->ChangeWatcher.reflow()->DynamicLayout.reflow()->StaticLayout.generate()这样的调用栈
这就是为什么要从中间删除才会卡顿，从最后删不会的原因
解决问题
通过以上的结论可以知道，要解决从中间删除表情卡顿的关键在于如何让ChangeWatcher.onSpanChanged()不多次调用
第一阶段方案
之前文章中提到过SpanWatcher继承于NoCopySpan接口,在产生一个新的Spannable对象时NoCopySpan不会被复制，而ChangeWatcher则实现了SpanWatcher,所以它也不会被复制，灵光一闪一个解决方案出来了
private boolean onDeleteEvent() {
int selectionStart = getSelectionStart();
int selectionEnd = getSelectionEnd();
if (selectionEnd != selectionStart) {
return false;
}
SpData[] spDatas = getSpDatas();
for (int i = 0; i < spDatas.length; i++) {
SpData spData = spDatas[i];
if (selectionStart == spData.end) {
Editable editable = getText();
SpannableStringBuilder spannableStringBuilder = new SpannableStringBuilder(editable);
spannableStringBuilder.delete(spData.start, spData.end);
GifTextUtil.setText(this, spannableStringBuilder);
setSelection(spData.start);
return true;
}
}
return false;
}
- 之前是直接删除
- 新的方案是先取出文本内容，复制给新的
SpannableStringBuilder,在设置到输入框之前删除表情，因为此时新的SpannableStringBuilder中并不包含ChangeWatcher所以不会多次调用ChangeWatcher.onSpanChanged() - 删除表情后再将
SpannableStringBuilder设置给EditText - 最后设置光标位置
完成这一系列操作之后demo一跑，删除果然变流畅了，当时心里那个高兴啊，竟然做个功能可以比微信实现的还好那么一点
输入法问题
然而总是帅不过三秒。没过一会就发现了新的问题。
- 百度输入法只能一个个删除表情，而不能长按一溜删下来（搜狗是可以的。。。）
刚战完微信又来个百度输入法，写个表情输入功能咋跟打游戏里的boss一样呢。本来自信满满要找出百度输入法的bug，但是从来没接触过输入法相关的开发工作，跑了跑google的输入法的sample还发现官方的输入法一样有问题，又挣扎了几下翻了翻源码，最终还是无功而返
虽然没解决输入法的问题，不过也不是完全没有收获
case DO_SEND_KEY_EVENT: {
InputConnection ic = getInputConnection();
if (ic == null || !isActive()) {
Log.w(TAG, "sendKeyEvent on inactive InputConnection");
return;
}
ic.sendKeyEvent((KeyEvent)msg.obj);
onUserAction();
return;
}
W/IInputConnectionWrapper: sendKeyEvent on inactive InputConnection连续删除时会出现这样的log，搜狗输入法也会出现，估计是百度输入法在出现这样的情况时就把删除按钮的触摸事件给中断了- 出现上面log的原因是因为InputConnection在
setText()时需要被重新创建,而第二次删除时InputConnection可能还没创建好或者IInputConnectionWrapper没处于激活状态
完全版的解决方案
跟输入法死磕几天未果正愁着呢，突然想到谷歌在android 8.0发布的时候推出了一个Emoji表情库，Emoji出现在TextView中逃不出也用的是ImageSpan，想看看谷歌会不会也有从中间开始删除表情卡顿的feature，就去找了下这个库的demo，一跑发现demo中不管从末尾还是从中间删都不会卡。顿时燃起了解决这个问题的希望，看完代码才发现解决方案如此简单
之前定位到问题在于ChangeWatcher，但它是一个内部类，自己想的法子都是在外部怎么避免ChangeWatcher.onSpanChanged()被调用，谷歌直接简单粗暴的用反射获取了ChangeWatcher的Class对象，在setSpan()的时候发现如果是ChangeWatcher就把它包装在新的WatcherWrapper中，所有的操作都通过WatcherWrapper中转，就可以随心所欲控制onSpanChanged了
自定义一个Editable.Factory
- 用反射获取了
DynamicLayout.ChangeWatcher的Class对象 - 将Class对象作为新的
SpannableStringBuilder的构造参数传入
final class ImageEditableFactory extends Factory {
private static final Object sInstanceLock = new Object();
@GuardedBy("sInstanceLock")
private static volatile Factory sInstance;
@Nullable
private static Class<?> sWatcherClass;
@SuppressLint({"PrivateApi"})
private ImageEditableFactory() {
try {
String className = "android.text.DynamicLayout$ChangeWatcher";
sWatcherClass = this.getClass().getClassLoader().loadClass(className);
} catch (Throwable var2) {
;
}
}
public static Factory getInstance() {
if (sInstance == null) {
Object var0 = sInstanceLock;
synchronized (sInstanceLock) {
if (sInstance == null) {
sInstance = new ImageEditableFactory();
}
}
}
return sInstance;
}
public Editable newEditable(@NonNull CharSequence source) {
return (Editable) (sWatcherClass != null ? SpannableBuilder.create(sWatcherClass, source)
: super.newEditable(source));
}
}
自定义一个SpannableStringBuilder
- 定义一个WatcherWrapper将ChangeWatcher包装起来，所有之前对ChangeWatcher的调用都通过WatcherWrapper完成
- 这里onSpanChanged就对ImageSpan特殊处理了，直接返回不调用ChangeWatcher.onSpanChanged
- 覆盖SpannableStringBuilder的相关方法
- 对和Span相关的方法特殊处理
贴上WatcherWrapper 的代码，自定义SpannableStringBuilder代码就不贴了，大家可以去项目里找com.sunhapper.spedittool.view.SpannableBuilder自己看
private static class WatcherWrapper implements TextWatcher, SpanWatcher {
private final Object mObject;
private final AtomicInteger mBlockCalls = new AtomicInteger(0);
WatcherWrapper(Object object) {
this.mObject = object;
}
@Override
public void beforeTextChanged(CharSequence s, int start, int count, int after) {
((TextWatcher) mObject).beforeTextChanged(s, start, count, after);
}
@Override
public void onTextChanged(CharSequence s, int start, int before, int count) {
((TextWatcher) mObject).onTextChanged(s, start, before, count);
}
@Override
public void afterTextChanged(Editable s) {
((TextWatcher) mObject).afterTextChanged(s);
}
@Override
public void onSpanAdded(Spannable text, Object what, int start, int end) {
if (mBlockCalls.get() > 0 && isImageSpan(what)) {
return;
}
((SpanWatcher) mObject).onSpanAdded(text, what, start, end);
}
@Override
public void onSpanRemoved(Spannable text, Object what, int start, int end) {
if (mBlockCalls.get() > 0 && isImageSpan(what)) {
return;
}
((SpanWatcher) mObject).onSpanRemoved(text, what, start, end);
}
@Override
public void onSpanChanged(Spannable text, Object what, int ostart, int oend, int nstart,
int nend) {
if (mBlockCalls.get() > 0 && isImageSpan(what)) {
return;
}
((SpanWatcher) mObject).onSpanChanged(text, what, ostart, oend, nstart, nend);
}
final void blockCalls() {
mBlockCalls.incrementAndGet();
}
final void unblockCalls() {
mBlockCalls.decrementAndGet();
}
private boolean isImageSpan(final Object span) {
return span instanceof ImageSpan;
}
}
设置EditText的EditableFactory
setEditableFactory(ImageEditableFactory.getInstance());
自己的demo一跑果然无论从哪个位置删都不会卡顿了
总结
- 性能分析工具可以帮助自己快速定位问题，对于android sdk这种不太好调试的代码更是事半功倍
- 解决问题的时候不要一味死磕，特别对于自己不熟悉的东西，有可能思路本身就是错的
- 对于一些私有的方法，用反射可以实现很多风骚操作~
最后
如果你觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言。一定会认真查询，修正不足。谢谢。
希望读到这的您能转发分享和关注一下我，以后还会更新技术干货，谢谢您的支持！
转发+点赞+关注，第一时间获取最新知识点
Android架构师之路很漫长，一起共勉吧！
以下墙裂推荐阅读！！！
- Android学习笔记参考（敲黑板！！）
- “寒冬未过”，阿里P9架构分享Android必备技术点，让你offer拿到手软！
- 毕业3年，我是如何从年薪10W的拖拽工程师成为30W资深Android开发者！
- 腾讯T3大牛带你了解 2019 Android开发趋势及必备技术点！
- 八年Android开发，从码农到架构师分享我的技术成长之路，共勉！
最后祝大家生活愉快~
学习交流
如果你觉得自己学习效率低，缺乏正确的指导，可以加入资源丰富，学习氛围浓厚的技术圈一起学习交流吧！
群内有许多来自一线的技术大牛，也有在小厂或外包公司奋斗的码农，我们致力打造一个平等，高质量的Android交流圈子，不一定能短期就让每个人的技术突飞猛进，但从长远来说，眼光，格局，长远发展的方向才是最重要的。
35岁中年危机大多是因为被短期的利益牵着走，过早压榨掉了价值，如果能一开始就树立一个正确的长远的职业规划。35岁后的你只会比周围的人更值钱。
如果你觉得自己学习效率低，缺乏正确的指导，可以加入资源丰富，学习氛围浓厚的技术圈一起学习交流吧！
[外链图片转存中…(img-N7EE2wGB-1623416741786)]
[外链图片转存中…(img-RfLYvuXx-1623416741788)]
群内有许多来自一线的技术大牛，也有在小厂或外包公司奋斗的码农，我们致力打造一个平等，高质量的Android交流圈子，不一定能短期就让每个人的技术突飞猛进，但从长远来说，眼光，格局，长远发展的方向才是最重要的。
35岁中年危机大多是因为被短期的利益牵着走，过早压榨掉了价值，如果能一开始就树立一个正确的长远的职业规划。35岁后的你只会比周围的人更值钱。
以上是关于Android-事件体系全面总结+实践分析内容太过真实的主要内容，如果未能解决你的问题，请参考以下文章