public boolean dispatchTouchEvent(MotionEvent ev) {
if (mInputEventConsistencyVerifier != null) {
mInputEventConsistencyVerifier.onTouchEvent(ev, 1);
}
// If the event targets the accessibility focused view and this is it, start
// normal event dispatch. Maybe a descendant is what will handle the click.
if (ev.isTargetAccessibilityFocus() && isAccessibilityFocusedViewOrHost()) {
ev.setTargetAccessibilityFocus(false);
}
boolean handled = false;
if (onFilterTouchEventForSecurity(ev)) {
final int action = ev.getAction();
final int actionMasked = action & MotionEvent.ACTION_MASK;
// Handle an initial down.
if (actionMasked == MotionEvent.ACTION_DOWN) {
// Throw away all previous state when starting a new touch gesture.
// The framework may have dropped the up or cancel event for the previous gesture
// due to an app switch, ANR, or some other state change.
cancelAndClearTouchTargets(ev);
resetTouchState();
}
// Check for interception.
final boolean intercepted;
if (actionMasked == MotionEvent.ACTION_DOWN
|| mFirstTouchTarget != null) {
final boolean disallowIntercept = (mGroupFlags & FLAG_DISALLOW_INTERCEPT) != 0;
if (!disallowIntercept) {
intercepted = onInterceptTouchEvent(ev);
ev.setAction(action); // restore action in case it was changed
} else {
intercepted = false;
}
} else {
// There are no touch targets and this action is not an initial down
// so this view group continues to intercept touches.
intercepted = true;
}
// If intercepted, start normal event dispatch. Also if there is already
// a view that is handling the gesture, do normal event dispatch.
if (intercepted || mFirstTouchTarget != null) {
ev.setTargetAccessibilityFocus(false);
}
复制代码
是不是瞬间没有任何兴趣了?请注意我还没有全部都复制上来,就只是一小段而已。
再看KunMinX大哥的精简版伪代码:
是不是瞬间就豁然开朗了。
写文档也是这样,如果我是审查者看到上来就贴项目内部的源代码的设计文档,对不起,我会直接打零分,贴源代码的设计文档,像极了初中的时候为了凑八百字而生硬的加排比句的作文一样,看起来很丰满,其实都是骨头没有肉。当你自己想钻研技术的时候,一行行的研究源码是没毛病的,但是如果你是要分享给他人的时候,千万别直接复制粘贴。
完成要求
这个环节也不多做介绍,这是和公司/产品内部的需求有关系。比如你做结构的修改,做完之后是否会影响到原有的开发流程,如果有,是否会严重的影响,这些都是需要列出来的。
现有架构和建议架构
一提到架构,很多人都会觉得很虚,感觉无从下手。其实在这方面,流程图和组件通信图都是很好的帮手。有时候可能自己会觉得无从写起,但是其实只要把流程图/组件通信图一画,其实就豁然开朗了。
这里我以我司的一个最近刚刚开源的移动开发框架 Amplify(aws.amazon.com/cn/amplify/)为例。
假如我在我的最新设计中提议使用这么一个新的框架,那么首先我得阐明这个框架是做什么的(PS:这是我自己总结的,和公司文案无关):
Amplify Mobile sdk 给客户端提供了一套离线应用解决方案,它包括了离线存储,和服务端数据增量更新,还有身份验证,日志发送等等移动端所需的功能。该框架以GraphQL语言为基础,通过WebSocket保持和服务器端的实时连接,还有基于时间戳的增量/全量更新保持客户端和服务端的数据一致。
好了,那你们组的高级工程师可能会问,那这个Amplify Mobile SDK内部是大概怎么实现离线还有和服务器端数据一致性的呢?
这个时候组件通信图就派上用场了。话不多说,先上图 (这里我们用 arcentry.com/app/ 来做示范,这个工具提供了很多AWS相关的服务组件图,比较好上手)。
同时,让我来以一个设计者的角度来说明这个架构图大概内容:
- 在Amplify Android SDK的架构设计上,每当用户在客户端进行数据操作(CRUD)的时候,Amplify都会通过Data 组件把用户本地的数据先进行修改(Model DataBase),在修改数据的同时,会把每一次CRUD操作进行序列化,存储在另一个Mutation数据库里面。
- Amplify Android SDK的Engine组件通过Observer模式,注册了一个数据源变化的观察者,如果有新的Mutation,Engine就会从Mutation数据库将Mutation取出并发送到API组件,API组件再将其封装成一个GraphQL的Mutation 请求发送至后端
- 图中的左边的区域为客户端,右边为后端
有了组件通信图,描述架构就变成了看图说话,小学四年级咱就学过了,非常轻松!
从以上的图和描述中,我们队友们就应该知道,数据存储在Sqlite 数据库内,同时保存了数据本身和对数据操作的序列化对象,并且他们也会有更多的问题,比如说
- 既然有Model数据库,我们怎么定义客户端的model,model长啥样,是Amplify有工具自动生成,还是必须我们手写?
- 既然是先写入数据库再和服务端更新,万一网络连接暂时不可用怎么办?Amplify怎么处理数据不一致?
这些都是文档阅读者在阅读完你写的简明易懂的架构简介之后会问的问题,是一个顺其自然的事情,当他们问到这里的时候,你应该感到高兴而不是紧张害怕,因为这说明大家把你的文档读进去了,而不是敷衍和不耐烦。能让阅读者和作者产生互动的技术文档,是好文档!
有了架构图,再加入一个流程图,就更棒了。这里我会用 www.plantuml.com/ 作为师范工具来构建流程图。
还是以Amplify为例子。既然我们决定使用Amplify了,那使用Amplify前后我们的代码和架构会发生很大的变化么?
假如我们的产品是一款点餐的软件,我们的Model(数据模型)是一道一道的菜,同时菜本身可以修改相应的元数据,比如辣的程度,是否加入了配菜等等。每当我们把菜加入到购物车的时候,不同设备同一账号的软件的购物车应该出现相同的菜品。
在使用Amplify之前,我们都是手动存入自己设置好的数据库,然后马上发送给服务端,来更新购物车的。
在使用Amplify之后,我们不需要存进自己的数据库了,而是直接面向Amplify的Model编程
如果大家觉得对比还明显,咱再来一个一刀切式的对比,把两幅图放在一起,再使用中间切割的方式:
通过上面这个对比图,阅读者可以很清晰的看到,在现有的设计中,我们完全没有修改Adapter和View之间的通信方式和流程顺序,仅仅是修改了Adapter和数据源的操作,从原来的Adapter修改本地数据库和发送网络请求两手一把抓,变成了现在仅需向Amplify SDK修改模型Model数据。
配上组建通信图和流程图,可以让你的文档不只是有枯燥的文字,使阅读者有更大的想象空间,加上和原有架构的对比,高级工程师看了也会直呼你是老司机。
开发时间线
开发时间线一般需要和产品经理协商,但是一个很重要的小技巧是,当你设计你的开发时间线的时候,最好是通过功能/产品发版的时间进行倒推,算时间线。
比如,我要2020年10月一号正式发版,那么假设我们Beta内测需要两个周,Beta bug修复一个周,QA测试内测版release两个周,那么我们开发的Code Freeze日期就定下来,大概是八月26号左右。有了Code Freeze日期,设计,开发周期就有了:
开发项目 | 日期 |
---|---|
正式发版 | 10/01/2020 |
Beta bug修复 | 09/24/2020 |
Beta QA | 09/10/2020 |
Beta 发布 | 08/27/2020 |
Code Freeze | 08/26/2020 |
开发 | 07/26/2020 |
设计/文档 | 07/15/2020 |
技术选型调研 | 07/01/2020 |
其他可选架构
有时候,对于同一个项目,同一个功能,还有其他的第三方类库或者结构可用,那么最好也要列举出来,同时比如各自的优劣势,这是给你选用的架构的很好的背书。这里就不列举例子了。这个环节也可以参考之前讲过的架构描述方法。
最后。。。。
其实写文档就像写作文一样,是一件非常消耗时间,并且需要积累的过程。我记得大二考雅思和GRE的时候,写作都是拿最低分的一part,当时的大学英语老师和我说,写作就是一个输入和输出的关系,你需要有100%的输入,才可能有10%的输出。要看很多,练很多,才可能有你练和看的那10%的成果,是一件非常辛苦的事情。但是在公司里面,写好了文档真的是一件对职业发展非常有利的事情。在谷歌的朋友曾经和我说,他在Android Support Libray组工作(现在是AndroidX了),因为support library太复杂,而且需要很强的backward compatible(向后兼任)的设计,所以经常性的是改几行代码,写1000字的文档和申请,在谷歌,写文档成了高级工程师常规操作,我相信大部分大厂也都是一样的。所以希望大家都能多写,多练,多拿反馈,不要害怕一开始被人批评或者吐槽,这些都是你的垫脚石。
作者:qing的世界
链接:https://juejin.im/post/5f0b4cab5188252e62285bcb
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)
建议
当我们出去找工作,或者准备找工作的时候,我们一定要想,我面试的目标是什么,我自己的技术栈有哪些,近期能掌握的有哪些,我的哪些短板 ,列出来,有计划的去完成,别看前两天掘金一些大佬在驳来驳去 ,他们的观点是他们的,不要因为他们的观点,膨胀了自己,影响自己的学习节奏。基础很大程度决定你自己技术层次的厚度,你再熟练框架也好,也会比你便宜的,性价比高的替代,很现实的问题但也要有危机意识,当我们年级大了,有哪些亮点,与比我们经历更旺盛的年轻小工程师,竞争。
-
无论你现在水平怎么样一定要 持续学习 没有鸡汤,别人看起来的毫不费力,其实费了很大力,这四个字就是我的建议!!!!!!!!!
-
准备想说怎么样写简历,想象算了,我觉得,技术就是你最好的简历
-
我希望每一个努力生活的it工程师,都会得到自己想要的,因为我们很辛苦,我们应得的。
-
有什么问题想交流,欢迎给我私信,欢迎评论
【附】相关架构及资料
内含往期Android高级架构资料、源码、笔记、视频。高级UI、性能优化、架构师课程、NDK、混合式开发(ReactNative+Weex)微信小程序、Flutter全方面的Android进阶实践技术
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门即可获取!
往期Android高级架构资料、源码、笔记、视频。高级UI、性能优化、架构师课程、NDK、混合式开发(ReactNative+Weex)微信小程序、Flutter全方面的Android进阶实践技术**