2022年终总结-Androider的成长之路

5,227 阅读30分钟

「回顾2022,展望2023,我正在参与2022年终总结征文大赛活动

2022年已经到了尾声,后半年度过的太漫长了,也是自己这两年来成长速度最快的一次了(后文揭晓) 今年的年中总结链接

上半年我沉浸在读各类技术书籍中,但是后半年的我几乎放弃了读书,转而投身到另外一个学习渠道上:

之前的年中和年终总结写的大体是参加了多少次活动,白嫖了多少礼品。但是这次我不想写平台的东西了(后半年的时间几乎很少花费在参与活动上面了,因为时间给了更重要的事情)

我想写的更多是关于自己成长方面的。总结下自己这后半年的成长

关于通用力的成长

在写完年中总结后的不久,得知我们可以访问腾讯的学习平台后,浅浅试听了几节课程,完全颠覆自己的认知。于是一发不可收拾,后半年的时间除了工作睡觉吃饭几乎都是泡在学习平台中

先放出自己的成果吧:

image.png

起步阶段

十四万字的整理看起来字数不怎么多,但是花费了我巨多的时间:比如沈奕斐老师的社会爱情思维课我花费了八个小时来记录两个小时的老师的干货输出;奇葩说中的老师演讲大部分也在两个小时时间短的我可能花费了五个小时,时间长的我整整花费了三天时间去理解转换记录到文档中.....

这些老师的课程虽然时间很短暂只有两个小时左右,但是对于一个小白的我来说,是打开了一个新的世界,在记录和总结中我的思维和认知也有了潜移默化的变化...

这里主要大致整理下不同的方向,jym如果想要提升自己的话可以从这几个方面去找资料:

  • 知识管理法
  • 高效时间管理,GTD时间管理法,生活黑客的时间管理
  • 思辨能力,独立思考,系统式思维能力
  • 创新思维SIT
  • 第一性原理,逆向思考力 .......

推荐书籍

  • 《经验的讲解》
  • 克里斯坦的《创新者窘境》
  • 《了不起的我》
  • 《坏比好厉害》
  • 《吾心可鉴-澎湃的福流》
  • 《指导生活的算法:人类生活中的计算机科学》
  • 《忧郁的热带》
  • 《规模》
  • 《必然》
  • 《决策思维》
  • 《心理资本》
  • 《赋能》
  • 《认知觉醒》
  • .......

有很多知识即便你知道了,你理解了,你也不能将其运用,因为你么有合适的场景。记录这些并不代表我真的都懂这些了(也不可能哈哈),而是希望自己以后碰到问题碰到场景的时候可以快速定位到文档,找寻一些其他的解决方案,并且更新自己不同时间段的不同理解

迷茫阶段

从上面的图中可以看到11月中下旬的时候已经没有更新了。经历了三个多月的疯狂记录和整理,我发现了一个神奇的现象(同样也是在课程中学到的):

人类的不同的问题放到不同的场景当中起成了不同的名字,这些名字中被积累的经验被人提取了出来变成了不同的学科。只不过这些问题在不同的行业经历的时间的长短不一样,每个领域发展出了自己的解决方案,形成了自己的专业术语。很可能不同领域的专业术语都在解释同一件事情,只不过是他们起了不同的名字,形成了我们所谓的人为的壁垒

没错,这个现象就是听得多了之后你会觉得自己也懂了,背后解释的现象和本质都是一样的,于是听到后面的时候老师讲出一句话我就会习惯性的把他进行分类,得出一个原来不过如此:

image.png

沸点链接,现在才明白了那句话成长就是孤独。 image.png

纸上得来终觉浅,绝知此事要躬行

听得多了,看的多了,绝知此事要躬行,碰到问题的时候先沉默两三秒想想自己以前有没有总结过类似的解决方案或者思路。在运用的过程当中我猜估计很多人也会和我碰到一个棘手的问题:什么时间下用,什么场景下用?我是不是每次碰到这类问题都要这么思考?

比如今天告你一句掉在地上的东西不能吃,但是父母还是吃了。你和他解释这样的危害和为什么不能吃有用吗?没有用。正如奇葩说中的某位老师说过我们这些知识和思维是好刀用在刀刃上,而不是一刀切。

记录完之后进行实践总结或者定期回顾得出新的灵感,记录到Flomo中,不用太在意这些有什么用处,慢慢的养成习惯后他自然而然就变成你的一部分了。

关于通用力的总结就先到这里告一段落,在十一月份就已经把方向切换到了技术方向,接下来我们来看看在技术方向的一些学习成长吧

关于技术的成长

果然大厂的技术课程还是很丰富的,以前喜欢上网找视屏,找博客资料有一个很大的痛点就是信息收集不全/不准,导致看了很长时间依然没有什么进展,几乎很多时间都浪费了,效率太低

这个是学习时间最长的一周,不得不说我很佩服那最后白分之五的人

image.png

这里推荐一个学习组织: Bagutree每周免费分享

腾讯会议分享,分享结束后大家可以自己提问题聊聊天,氛围超棒(链接内有群二维码)

技术成长的文档总结没有个人成长多,刚起步嘛哈哈=O=

image.png

这点真的是太赞了,自己以前理解的很多误区和好多疑难点几乎在视频里面都会提及到,年底面试的时候把在里面学到的技术吹了一波哈哈,效果不错

技术成长记录并没有开始多长时间,后续会花费大部分时间记录这部分文档。等到明年的年中总结再来回顾吧哈哈

加入酱酱们的下午茶

今年下半年还有一个重要的事情就是成为了 酱酱们的下午茶 主理人之一,正如个人介绍中那样:小小的我,发现优质的你。在整理技术文章的时候,也收藏了不少很多有干货的文章,也算强制自己去阅读掘金优秀文章,从中也成长了不少。

酱酱下午茶账号每天都会发布最近1-3天出现的优质文章,内容涉及前端后端和移动端。加入下午茶之后还认识了很多有趣的小伙伴:

  • Ylimhs:摸鱼王-宁姐,正如介绍所说:是一个长期活跃于沸点的最佳摸鱼手
  •  丘山子 :老岳,是比我大一岁的哥哥
  • 帅气的法医:法医哥的读书群很棒,也是读书圈的主理人,大家喜欢读书的可以私信法医哥进读书群哦
  • 战场小包:群里总能看到包总和南方者的打情骂俏哈哈
  • 南方者:包总的好基友
  • 有出路:航哥这个名字有出路 也经常告诫自己努力一定会有出路的
  • 船长:当然忘不了还有每天催我们交稿的船长(狗头),给我们的福利也很nice,由于疫情我把东西船长发的东西都发往家里了,就不能拍照给jym看了
  • 刚哥:刚加入我们的小团队,一起努力把账号做大做强

目前酱酱们的下午茶还缺人,想来的jy可以私信船长哦,加入下午茶还有福利可以拿,我们一起做大做强

关于工作

工作的情况不太好,由于我把大量的时间都用来泡在学习平台里面(因此每周四的学习周报里面学习时间都稳定在40个小时左右),所以加班时间和周末时间都没有忙公司的事情,领导觉得不怎么满意,年中的绩效又是给的我差,不出意外年终还是差哈哈,年终奖估计只能拿两个月工资(大佬们勿喷,我的base很低很低)

我并不后悔,年轻嘛,要把时间花在提升自己身上,不要因小失大

上半年的重构完成之后,下半年都只是一些业务上的小修小改并没有太多需求。也是想办法在做一些优化,大部分的时间还是花在优化上面了。12月初的时候接到一个任务,还是去写一个sdk预计是一个月,估计这个月会很忙,其中的成长和结果也得等到明年的年中才能看到了

关于生活

我这个人生活并没有那么要求,只要有个睡得地方能点到外卖就好,平常的周末时间宅家泡在学习平台上(周六晚上八点泡在Bagutree上),晚上下班后的时间依旧是泡在那里,几乎无社交。

在网上新交了个朋友:武师叔,大二学生,比我小一岁,由于自己没有上过大学,很好奇也很憧憬大学生活是什么样子的,师叔满足了我的这个好奇心。由于我们差不多的是同龄人,所以生活上的一些问题我们也会一起互相交流,这个年龄的我们都很迷茫,但是也都充满理想和希望

总结

后半年语雀知识库更新总字数:250154

语雀热力图:

image.png

可以看到我这后半年的时间主要是用于泡在提升通用力上了,技术方面的提升几乎也没有最近这一个月才开始拾起来。

找工作得话,如果大厂不好面或者进不去,最好找大厂下面的合资公司或者子公司,这样大厂的学习平台你是可以白嫖到的,大厂的学习平台都会花钱请很厉害的大咖来内部分享,我觉得这是一个不错的成长机会

看到运营推荐了这篇文章,感觉自己写的太少了有点不配这个推荐,于是在记录下这一年的收获吧

金句分享

生活金句

1.可难道我们生命中做的每一件事不都是为了被爱得更多一点吗

2.这不只是一种对承诺的恐惧,也不是我缺乏关心和爱的能力,因为我做得到,只不过,老老实实讲。我想 我宁愿为了某件我擅长的事,我能表现的出色的事去死,也不愿仅仅为了一段美好贴心的感情去死

3.他这一生 时间都用在考虑他的事业和工作,他那时五十二岁,他突然意识到,他还从来没有真正付出过自己,他的一生没有为了任何人或任何事,他说这话的时候,他差点哭了

4.如果世间有魔法,一定存在于理解别人和分享的尝试之中谁在乎呢?可是,说真的,答案一定就在尝试之中

5.时间就那么多,怎么选择。各个阶段有各个阶段的疑惑,也有不同的答案

看到大家都已经走上了职业发展的正轨,我很害怕,看到这句话的时候释怀了

6.经历反哺普世知识,普世知识拓展预测经历,没有经历和反思过得东西必然索然无味,自己的想法和别人提到的信息如果只是记录的话,没什么用处因为没有经历所以觉得不重要,没有实际的用处必然不会深刻领悟其主旨内涵,一切的智慧都是通过经历体现的,而所谓的学习可能只是让你有了大概了解,对于真正的懂你还差的还远

感情的金句

沈亦斐老师的小粉丝,以下是老师的一些摘录。如果因为我的某些总结而引起您情绪的变化,请放心一定是我的错而不是老师。没有对应的上下文环境进行铺垫这些话听起来确实很容易引起情绪波动

1.现代人会思考会有人爱我吗?使得进入爱情更加谨慎,进入爱情风险更高,进入到爱情就会遇到一种困境,要不断地衡量我的价值是不是足够,我把自己放在竞争的位置上很难受,所以算了 不参与竞争不育保平安。也就不会有人来评判我是不是值得。

2.很多年轻人逃避爱情是在逃避什么?因为好的爱情是促进你的,为什么不愿意进去是因为你会发现是要拿自己出来碰的。

3.为什么会碰到奇葩男,是因为介绍人认为你们两个人的价值是相匹配的,才把他介绍给你。要让自己承认和奇葩男一样是很难受的,所以就叫人家奇葩,这样就可以把我的低价值给载出来

4.忠诚和承诺更为复杂,在当代他还包括这样一种意味:爱情是一种持续进行,永无休止的“验证过程”:即对一个人自身的个体性和价值的重复确认

5.被拒绝和被背叛意味着自我价值感大厦的倾覆:我的那个自我还不够好,价值不够高,不值得被爱;

6.男性的自我向外扩张,征服世界,所以男性不会内化这些东西,他的重点是外部也就很少听到奇葩女。

女人的自我内向审视,需要认同,所以会叫对方奇葩男

现代爱情变得越来越难以持续是因为男女对自我的追求南辕北辙

7.爱情对于两性的意义是不同的:

  • 对于男性:性资源的获取和男性气质的彰显
  • 对于女性:独特自我的发现,个体价值的赋予

8.男性的自我强调自我实现:修饰齐家治国平天下,女性的自我强调自我救助:不完善的自我需要爱情来修补

9.在婚姻市场上男性被进一步要求提供更为强大的经济基础,女性在追求经济独立的过程中,却被消费注意进一步“物化”

10.今天这个时代,做选择本来就是很不容易的。

11.爱情是个勇敢者的游戏,在未来,爱情不是所有人能拥有的东西,是个奢侈品。爱情恰恰跟钱没关系,有钱就一定能买到爱情吗?

是个奢侈品是因为你一定是勇敢的,你得面对挑战,你要去摘那个最美的果子,你就要把自我拿出去,这恰恰是成长路上最重要的一步。

职业的金句

1.首先要有积极乐观的心态和做事态度,能正确认识自身的不足并保持学习,面对困难能抗压。

在遇到问题时要勇于挑战,在解决问题的途中积累经验,发现自身需要补足的漏洞,通过不断的学习,拓宽技术广度,培养系统设计思维,对前沿性的课题保持好奇心,敢于接触和使用新技术。

具体的就是要有高于标准的技术深度、开发能力和解决技术难题的能力,在工作过程中对自己负责的模块重点深挖,不断优化,对于复杂问题从多角度出发,利用发散思维寻找解决办法

同时面对各种繁杂的问题,要能找出共性,发现隐患,合理解决问题的同时也要减少未来的问题提高技术广度,对不同领域都要有清晰的认知,培养大局意识,从系统设计的思维出发,对于项目未来技术发展有预判,能通过这种方式规避可能的风险;

2.多做笔记,多总结,多复盘。

凡事有交代,件件有着落,事事有回音。

在空闲时间持续学习,保持对技术和游戏的热情,多看看游戏开发领域的前沿方向,培养举一反三的能力,发现复杂问题之间的共性,在解决问题的同时,发现可能存在的隐患,避免或减少未来可能出现的问题。

树立一个清晰的目标,可以职业成长围绕这一个点去积累经验,围绕职业目标方向这个核心,才能构建竞争力,形成核心竞争力。只要方向明确,哪怕走得再慢,也可以比那些走弯路的人走得快。

坚持不懈,更加有效地投入时间

遇到无法预判的情况时,保持冷静思考,通过理智分析,从多个角度寻找解决办法,同时也要总结经验,多复盘,这样才能对突发事件有足够的预见性。

3.毕玄:我在阿里的十年技术感悟

4.《技术成长之路》精华回顾

5.优秀复盘:先介绍问题背景,提出问题给出问题的定义(让大家对问题有个具象化的理解),提出常见解决方案和这些解决方案的缺点,提出自己的观点(自己的突破点是什么)论证自己的观点,综合起来说效果

技术

系统

1.Android系统优化的那10年

2.如何判断dexopt失败?

dexopt是可以判断出来失败的,校验一下这个dexopt是否完成(校验方法是loadDex这个dex里面的类看他能不能load进来)

出现dexopt失败问题:1. 空间不足(转换之后的opt信息已经写不进去了),2.安装时空间不足(读apk的时候读不进来)

3.关于meminfo的值介绍

PrivityDirty=应用自己本身使用的内存,不包含Davilk的共享内存

HeapAlloc=Privity Dirty(应用本身自己使用的内存)+Davlik进程的内存(预加载资源+预加载类)

DavlikHeap的PSS Total=Privity Dirty+(Davlik进程内存/App个数)

运行dumpsmeminfo的时候有可能会让当前虚拟机进行一次GC

(也可以使用dumpsys meminfo --local不进行GC),如果对meminfo的结果不太满意想进一步分析,就使用smaps(/proc/< pid >/smaps)分析

smaps可以吧mmaps映射那些文件可以详细的列出来,主要消耗内存的地方主要是: dex,so,jar,apk

4.内存碎片指标分析:

表现:PSS和PrivatedIPrity还有HeapFree都有了很大的提升,但是HeapAlloc却没有什么变化

原因就是内存碎片的产生,分给你的空间还是那么大,之前的内存页都满满当当用完了,但是现在有了临时数据产生所以需要的页也多了,由于临时数据,所以GC完成后Heap Free也有很大的增长

5.Davlik Other和mmaps构成:

Davlik Other构成:

  • 这个类加载进来之后有哪些成员变量成员函数以及指向这些成员函数的指针
  • 基本上和载入类的数目是相关

mmaps构成:

  • 存储了类信息的结构,从映射dex结构中读进来的
  • 编译之后的字节码也是从mmaps部分读进来的
  • 包括字符串常量数据等等都是映射在这里面的
  • 基本上也是随着载入的class数量增加而增加的

6.new一个对象对于虚拟机来说需要执行这两个步骤:

第一部分是loadclass,内存增长分为两部分区域:

  • dexmmap:从.dexmmap里面读这个类的信息,会使dexmmap增加
  • 解析读到的数据之后,虚拟机会在linaerAlloc和aux里面存储一些类的信息和指针之类的

第二部执行 new Instance,内存增长分为三部分:

  • dexmmap:又会去从dexmmap里面找这个类的构造函数(为了执行这块代码虚拟机也要把这块代码加载进内存
  • davlik-heap:加载进内存执行之后才会在真正在dalvik-heap真正分配对象真正实际占用的内存
  • davlik-bitmap和jit-code-cache:还是会分配到davlik-other里面分配些内存辅助进行运行

渲染

7.渲染发展史:

  • Android1.6:渲染采用Skia软件绘制SF层合成采用OPengles1.0和copybit

  • Android3.0:**渲染非默认采用HWUI(2.0)**可以手动开启属于实验室项目

  • Android4.0:渲染只要你target的api大于4都是用的HWUI,也可以手动开启Skia。移除CopyBit(拷贝比较快,4.0之后的手机都有GPU了,所以被舍弃了)SF使用的还是opengles1.0

  • Android4.1:黄油计划(顺滑)

  • Android4.3:延时的DisaplyList,渲染开始支持ES3.0(ES3.0此时并没有为UI使用,主要是为游戏使用)HWUI用的ES2.0,游戏用的3.0

  • Android4.4:SF使用ES2.0合并图层贴出来

  • Android5.0:引出了一个新的线程RenderThread渲染线程(之前做绘制和渲染都是在主线程的)现在主线程救就是主线程以前即是主线程也是UI线程。UI线程是RenderThread,渲染支持3.1(此时用于UI)

  • Android6.0之后:支持Vulkan(哇卡)用于取代OPENGL的新的图形API,比OPENGL更加榨取GPU的渲染能力

8.SKIA

Skia软件渲染流程:

  • SKCanvas对应于java层的canvas
  • SKCanvas持有着SKDevice设备
  • SKDevice持有着SKBitamap(Surafce其实就是一个缓冲区,通过Bitamp吧这个缓冲区的指针封装起来)

canva通过androidRuntimeGNI接口吧数据参数给到SKCanvas的draw调用skiadevice最终会调用到skDraw(最后的drawpath,drawXXXapi最后都会到SKDraw中),SKDraw通过SKRasterizer把他画的东西进行光栅化,然后调用SKBliiet的blit方法传输到Surface的缓冲区中(blit是一个快传输),接着SF进行合成

这里面每一步都是CPU在参与,所以它的光栅化是CPU进行的,但是SF是基于GPU合成的(一开始就是用的1.0)

在4.1之后Skia也支持了硬件加速(GPUCanvas,gpudevice,glcontext【gpu的context】),通过gl接口硬件加速画出来而不是之前软件渲染通过bitmap一个一个像素去渲染

9.skia也使用硬件加速的功能,为什么安卓还要在实现一套?

渲染模式差异

渲染一般有两种:

  • 立即模式:APP维护场景【里面东西变了你需要调用图形库的一些方法反映到屏幕上绘制出来】,通过调用渲染库的api上屏,每次发生变化都需要CPU调用生成图形给到GPU

  • 保持模式:场景由图形库自己维护,图形库跟踪或者更新变化。APP是调用的图形库的方法构建图形库里面的场景,如果场景发生变化,图形库会吧这个场景转换成会绘制命令了给GPU执行上屏(对于细微变化不需要CPU重新生成图形,只需要告知变化给GPU,GPU自己维护的图像做了变化就可以用

保持模式的每一帧都是从GPU到VRAM(GPU和显存之间非常高速的)。不像立即模式通过bus总线传输(和CPU沟通的话受bus总线带宽影响)立即模式的瓶颈在bus的带宽(如果io占用了bus就会有瓶颈)

矩阵变化旋转位移透明度都属于细微变化都不需要去重新加载场景,继续操作显存里面的场景进行变化(这个时候应用程序完全不需要重绘只需要告诉变化)

可以看到由于GPU需要维护场景,所以需要额外的内存(具体看屏幕大小),因此如果对View开启硬件加速(View.setLayerType)的话要有两个前提:

1.第一个是要求能做是复杂的View操作(维护的场景无法重用,只能重新调用onDraw生成DisplayList再通过总线传输给GPU);

2.第二个要求是内存如果紧张的话不能使用硬件加速(需要额外的内存保存场景)

10.黄油计划

  • 4.1开始三缓冲减少卡顿: GPU你慢可以,但是你需要吧慢的那帧给缓存起来。显示就不只是GPU渲染完哪个就显示哪个了,而是GPU上一次渲染的图像。总结就是两个卡顿变成一个卡顿,减少卡顿 N缓冲也无法避免卡顿,因为有时候你的cpu就是很卡需要处理或者GPU很慢

  • rendernode对displaylist的属性进行了封装

4.1之后displalist会生成一份对于修改自己的属性,对于简单的变化是操作displaylist的属性之前的话不管是不是复杂简单都会重新生成diaplaylist

表现:属性动画在黄油之后会更快,因为这些属性都对应到displaylist中的属性了,不需要调用ondraw方法了只需要进行修改displaylist属性就好了不用view在inviladeta了

待考证:但是如果调用inviladeta的话还是会去重新调用OnDraw生成DisplayList

  • DeferredDisplaylist

安卓渲染慢,有部分原因是浪费在了opengl的上下文切换:不同的上下文做的事情是不一样的(绘制背景,绘制位图,绘制文本),其次指令数量没有经过整合

在优化之后经过重新排序后吧相同类型的操作放到一块(减少切换上下文次数),同时指令数量会减少【两个三角形需要两次绘制,但是现在可以执行一次就行合并是通过合并顶点数组和纹理数组实现的,可以看成多张图变成一张图】

  • Shared Atlas共享纹理集

以前是把内存里面的位图加载到显存里面。进程之间是无法共享的,所以每个APP按需往GPU里面加载纹理(如果多个APP都是用同一个纹理那么并不会共享重新加载gpu是不知道的,会加载相同的纹理)。用那些就把那些传到GPU的显存里面

共享纹理集:把系统的资源拼起来拼成一张大图(不超过模拟的最大尺寸就行)上传到显存里面里面有很多纹理集,用的时候通过坐标去取。

大图是维护在SurfaceFliger这边用的时候像SF拿就行。

通过SF进行统一纹理集,应用像SF拿到操作纹理集的句柄(显存对内存的映射指针),就能拿到显存里面的纹理。

应用的drawable文件夹也会进行同样的上传操作,到时候进行上传(这个解决的倒不是共享纹理集的优化,而是解决了内存碎片)每次用的时候不是直接加载而是提前加载纹理集到显存中,这个时候会做内存碎片的整理。文件夹特别大就会有多个纹理集

  1. 软件渲染和硬件渲染的一些总计:

软件:
当ondraw方法调用后会立即渲染图片(每个view的ondraw完成就会绘制),cpu使用skia立即渲染模式去生成图片,由于是cpu去做的渲染图片的操作所以效率不是特别高。

有一个注意点是 当需要invliadate指定矩形区域时,如果脏区和其他view有相交区域的话,其他view也会进行刷新(这算是一个bug,本来做的只是这个view的重绘结果其他view也重绘了)

硬件:
引入displaylist,每个virw都有一个rendernode,其中维护的是一个displaylist。
ondraw方法调用不会立马去渲染而是记录操作到displaylist中,每一个rendernode都包含当前的displaylist和子view的rendernode。整个视图渲染完成后把displaylist交给renderthread去做渲染(opengl操作利用gpu)

注意点:

1.有些自定义view的绘制操作并不支持硬件加速可能产生不了效果,所以需要看情况是否禁用。

2.脏区绘制更新哪怕和其他view有相交也不会绘制其他view

区别:
1. 软件绘制的inviladate方法会重新调用所有view的ondraw,但是硬件渲染会去在displaylist中标记不需要更新的view,只需要更新重绘调用ondraw生成displaylist方法。

2.对于简单的操作来说(对displaylist的属性进行修改),硬件加速不需要重新调用ondraw方法只需对displaylist的属性更新就可以生效

属性修改可以直接生效不需要调用onDraw,属性动画性能大大提高

对于复杂操作还是需要调用ondraw重新生成displaylist,gpu重新绘制。

3.对view开启硬件加速后,软件是绘制成bitmap,硬件是采用displaylist(属性更新性能会提高)但是对于频繁复杂的view操作由于不能利用GPU维护的场景(也就是纹理)因此还是需要调用ondraw重新生成displaylist,gpu重新绘制性能较差

12.图形性能调优的一些方法论:

  • OverDraw去除冗余渲染
  • Profile Rendering:根据竖线不同颜色来优化
  • HardWare layers updates:动画开始之前给view设置的硬件加速的layer,渲染到纹理上下次用的时候直接从纹理拿非常非常快不需要重新渲染(没有总线的开销),播放结束之后设置为NONE默认的layer。因为需要连续播放会受bus总线带宽限制

如果在动画播放过程中内容发生变化,则会有个绿色的蒙层在闪,如果在闪说明内容一直变化。说明不适合开启硬件加速变化太频繁(一直需要内存upload到显存中一直在load很耗时还不如不开按正常方式构建displaylist渲染,不用纹理

  • 开启OpenGl trace:不同级别的日志,可以看到swap和drawXXX还有上传纹理到显存等不同的级别

所有的插件化,插件启动干得事情都是一模一样的(classloader,资源,上下文,loadedapk),只是插件框架的初始化不一样

推荐书籍:
  • 《建筑模式语言》
  • 《分析模式:可复用的对象模型》
  • 《企业集成模式》
  • 《反模式》
  • 《面向模式的软件架构》五部曲

此外最有收获的就是看了掘金的关于职业发展的直播,希望掘金以后能多举办这种活动,大佬们的成功是有方法可循的,我们可以借鉴大佬的做法事半功倍,沸点链接,截图如下:

image.png

技术成长

部门组长很厉害,给了我很多指导和帮助,也是我的偶像(代码写的那叫一个优雅)。刚进组里,组长就罗列了一大堆技术清单,想看懂我的代码,必须要懂这些,然后又开始了我的学习之路。

技能清单如下(感兴趣的jy可以自行学习):

1.gradle apk打包流程

2.gradle Transfrom 方案

3.AOP 面向切面编程思想

4.字节码增强技术方案,比如ASM,JAVAASSIST

5.JAVA 源码生成技术方案 javapoet

6.Application,Activity,Service,BroadcaseRecive,ContentProvider启动原理

7.apk解析安装过程

8.Classloader类加载机制

9.代理等设计模式

说说我这今年的技术成长吧; 看的技术书籍和笔记(用的软件叫当当云阅读):

当当云想法截图
a6c9adca-4c03-480d-8fd3-b64d1d2ce625.jpg5a37cddc-8fc3-4bdd-88bc-c094d93a0148.jpg
9436c0f4-0a27-47e2-90fc-ec962118a5de.jpg~~~

我的学习方式在今年年终的时候我才觉察过来效率太低,总的而言我喜欢研究一些自己感兴趣的东西但是回报比并不高的东西上,比如图形渲染,我花了整整两个月的空闲时间去研究,但是回报对于业务来说几乎没有。我好像花了很多的时间在研究同事说的无用的东西上

看了很多人的年终总结,大家对一年的学习方式都有思考,其中我觉得让我心安的是这篇文章《2020:非适应性完美主义、存在主义哲学、架构、基金翻倍、有效休息|掘金年度征文

其中 标题《错误地理解了“基础”的意思;解决:深究的心》中写到的 :一定要切记,打基础,是和工作任务相关的基础,而不是整个计算机行业的基础。 妄想把 编译原理、Linux底层、操作系统 都掌握,这是不可能的。 对现在的我最有感悟

研究一个东西的时候会发现底下有很多基础知识牵动着,你要想理解上层的做法必须先把底层搞明白,但是底层需要你花费大量时间而且太广,回报周期太长而且不感兴趣的东西我是不会去浪费时间到上面的

今年把计算机网络的大致流程看了一下,对于数据结构和算法依然没有动静,设计模式倒是在项目里用上了,操作系统和机组也是大致过了下,博主的一段话点醒了我:这样,很容易把时间投入在无任何产出的基础上。浪费时间,还让自己产生一种虚幻的很强的错觉,既不利于能力提升,也会让自己心态失衡。

So 技术成长是有道路的,你要学的就是那些东西,根据技术清单查缺补漏。但是我并没有列出我的技术图谱进行查缺补漏,没有进行体系化的总结,只是对自己喜欢的进行了细致的研究,我也不打算整理技术图谱了,反正都是不感兴趣与其看与业务无关的东西还不如多立足与业务出身,进行优化SDK

技术总结

半年里收获的一些技术

图形渲染&opengl

输出专栏:渲染专栏

  • 设计模式
  • 四大组件启动流程
  • 计算机网络相关知识

输出专栏:计算机网络

gradle的生命周期和可以新增简单task逻辑

输出专栏:Gradle

计算机组成原理

输出专栏:计算机科学

Android源码笔记,输出专栏:Android源码系列

待加强:

  1. 计算机网络
  2. 安卓开发必会的一些操作系统知识
  3. 数据结构(这个一定要开始看了)
  4. 继续加强设计模式方面的能力
  5. 关注性能方面的知识