IT数码 购物 网址 头条 软件 日历 阅读 图书馆
TxT小说阅读器
↓语音阅读,小说下载,古典文学↓
图片批量下载器
↓批量下载图片,美女图库↓
图片自动播放器
↓图片自动播放器↓
一键清除垃圾
↓轻轻一点,清除系统垃圾↓
开发: C++知识库 Java知识库 JavaScript Python PHP知识库 人工智能 区块链 大数据 移动开发 嵌入式 开发工具 数据结构与算法 开发测试 游戏开发 网络协议 系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁
 
   -> 移动开发 -> 2019一个移动端开发者的总结与思考,附Android面经 -> 正文阅读

[移动开发]2019一个移动端开发者的总结与思考,附Android面经

1、上半年产线中的几个复杂页面的流畅度在版本迭代中一直会由于开发的不注意导致频繁出现反复,分析下来根本原因是由于缺乏必要的监控以及可持续的优化手段,所以2019Q1在业务需求之外主要就是实现了产线内部对于用户流畅度的监控以及优化,主要包括:debug下帧率的监控、上线前主流程流畅度的自动化测试、线上用户真实流畅度监控、实现耗时方法排查工具MethodTraceMan一些收益比较大的流畅度优化等,主要目标是从监控到排查问题工具再到卡顿解决形成一个闭环的方案。

对于流畅度监控与优化归纳成文,有兴趣的可见:App流畅度优化:利用字节码插桩实现一个快速排查高耗时方法的工具

2.对于内存上的问题,我们产线其实很早之前就碰到了,线上爆出可观数量的OOM,当时我对我们app做了一次内存上的分析与优化,效果还是非常明显的,当时对分析和优化过程做了记录:实践App内存优化:如何有序地做内存分析与优化,后续的几个版本中我们发现OOM的数量大幅度下降,但是依然会有少数的OOM上报,分析下来发现这部分发生OOM的机型大部分单应用最大可用的内存只有64M,也就是说有部分很老旧的机型内存实在小,所以我们最后上线了内存适配方案,也就是对不同内存大小的机型做不同的内存使用方案,比如对于一些老旧内存非常小的机型,选择适当去降低图片的质量,关闭一些花哨的动画,对于一些大内存的使用更加谨慎,更加及时的去做一些内存的回收等等,收到了不错的效果。后面对于内存方面的优化一直没有补充到上面的那篇文章里,等有空了,补上后续的一些内存优化手段,供交流分享。

3.Google近年来对Jetpack进行不断的补充和完善,我也对Jetpack进行一定的学习和引进,特别是lifecycle组件等已经在我们产线中使用很久了,我们使用响应式的编程方式来组织或者重构问题代码,解决了一些我们产线现有的问题,提高了效率。还是那句话,不应该以新或者旧来看待技术,而应该以他是否能提高你的效率以及解决你的问题的维度来看待他。

对于响应式编程以及lifecycle组件的一些总结与看法: 响应式编程在Android 中的一些探索

4.这一年也对团队在代码规范和约束方面做了一些努力,在团队开发过程中这方面其实非常重要,如何保证代码质量以及稳定性直接影响了上线app质量,所以我们团队在挺早之前就建立了警告和报错的责任制,即上线前每个人要清掉属于自己的警告和报错,当然主要还是靠Lint。但是有一些Lint无法触及的团队内部的一些约定,这确实在版本迭代中由于开发的疏忽在线上引起几次问题,基于这个问题,主要的目标还是希望可以在开发阶段就能在编译器中对于团队内部约定的规则进行报错或者警告提示,于是我发起并实现了一个自定义Lint规则的项目,主要是对Lint的拓展,基于AST树,去实现一些探测器。比如可以配置禁止使用哪些类,哪些方法,同时提示解决方案,团队成员也不断的拓展和自定义规则,现在这些我们团队内部自定义的规则已经和Lint警告一起作为我们上线前需要清理的问题。

对于如何实现自定义Lint规则,其实网上有很多资料,有兴趣的同学可以看看

二. 技术深度 or 技术广度

一年是漫长的也是短暂的,这一年团队全面切到Kotlin开发,自己个人也关注学习了ReactNative和Flutter,同时对JS以及React等前端技术做了一些学习,技术上个人想法是争取往所谓的T型技术人上去努力吧,又是那个老生常谈的问题,技术是重深度还是广度,对于这个问题,这一年也有了更深的看法,技术就像是一棵树,在顶部叶子上各个领域看似毫不相干,但是在一个领域越往下深入,各个领域相互交错到的知识或者设计方式就越多,所以技术深度和广度并不是对立面,对技术深度的探索不仅有利于你在特定领域有更深理解,更加可以帮助你轻松切换到另一个领域,特别是像前端的各细分领域的工作,很多领域的知识背后都殊途同归,而技术的广度也不是有的人说的那样不堪,在有技术深度的基础上,去拓展自己的技术广度,其实大大有利于你对相关技术更深更饱满的理解。

技术广度方面,举几个小例子,比如做Android一直用的是java的时候你可能很能想象会有像Kotlin中拓展函数这种看起来像可以给类动态添加方法的功能,但是如果你对JS有一些的了解的话,利用原型其实JS一直就可以很方便的实现这种动态添加方法属性的功能,当然与Kotlin背后实现的原理完全不一样。再比如Android开发中我们实现异步的方式从回调方法到RxJava这种解耦的链式调用再到Kotlin协程这种看起来同步的代码效果,是不是和前端领域实现异步从回调方法到Promise再到aysnc await的历程挺像的。不断的对比和思考,更能够碰撞出不一样的火花,比如前端领域大火的响应式UI以及状态管理模式Redux,好在哪里,如果移植到原生开发会是什么样的形式,会有什么样的好处和效果,又有哪些差异和限制?学一样新东西时,或多或少慢慢的就会看到原来你已经掌握了的技术的影子,技术的广度可以帮助你对技术有更深的思考和理解。

技术的深度有利于你更轻易的切换到新的领域,对于我个人而言,这种例子有很多,比如在学习Binder的时候你会发现跨进程通信的本质就是在用户态的进程间无法共享内存实现通信,而在内核态却可以,也就是说在用户态每个进程就像是一个孤岛,联想到几年前团队在做app组件化的时候,解耦完后每个产线组件也像一个孤岛一样互不依赖,那最终是怎么实现通信的呢?我们把每个组件先在一个数据链表里注册,之后要通信,由router中间人先在数据链表找到对应的目标组件,然后调用目标组件里的方法实现通信。那么binder是怎么实现的呢?其实我觉得很相似的,只不过binder将这个所谓的数据链表维护在ServiceManager,当然binder要复杂的多,因为Client、Service、ServiceManager三者处在不同进程,所以两两之间每次通信都要经过将通信数据拷贝入内核态的biner驱动,在binder驱动的数据结构里找到目标进程的对应节点,然后将通信数据放入目标进程节点,之后唤醒目标进程,开始解析并处理,最后将结果返回给Client进程。这其中还涉及到一个点,每次一个进程将通信数据拷贝入内核态后,自己就会开启一个while死循环等待回复,那么这个和handle消息队列里的死循环设计是否一样呢,是否也是在没有消息的时候利用epoll实现阻塞呢?在对一个知识进行比较深入的学习时总是会时不时冒出其他知识的关联和疑问,也有了更多的思考。

当然以上都是我的个人看法,并不一定准确,都是基于个人的认知的基础上有感而发的,其中有认知上不对或者不认同的地方还望海涵。

三.解决方案 or 技术难点

这一年,对于技术的看法也发生了一点点改变,有时候做研发做技术会陷入技术怪圈,过分的追求或者陷在技术的难度上,而忽略有时候直接有效的解决方案才是最有价值的,解决方案是最终的目的,而技术只是工具。学会不仅仅是钻在开发角度看问题,跳脱出来,站在用户角度,站在产品角度,或许会有意外的收获,这一点我也在不断努力中

举几个小例子吧,比如早些时候在做一个主流程复杂页面的TTI(用户可交互)时间优化时,显然目的就是降低用户进入一个重要页面的等待时间,用户等待的时间越少相对来说转化率就越高。所以从技术角度可能马上就开始想:怎么提高Activity启动速度?怎么减少网络耗时?怎么优化UI渲染速度?这些做完还不够,还有没有黑科技?但是如果你跳脱出来,站在用户的角度,他只要我进来能最快的看到内容就行,他不关心你是什么高深技术优化,所以最终其实最有效的方案是在上一个页面加一个预加载,可以实现大部分用户进入下一页面可以直接看到内容,大大降低TTI时间(当然并不是所有页面都适合预加载,要自己平衡和评估,这里只是举个例子)。做个预加载,基本没有技术上的难度,但是对用户的实际体验帮助很大。当然技术上的难度是你需要具备的素质,这些知识到了优化瓶颈的时候都很有用,但是在另一维度也要明白解决方案才是根本,站在更广的地方看问题才能收获更多。

另一个小例子,相信很多团队都受困于线上的空指针异常问题,这些都是实实在在的崩溃,对你的用户可能造成很差的影响,很实在的损失。所以如果去规避屡禁不止的空指针异常呢?当然Kotlin空安全另说了,如果是java开发,各位一般都是怎么来规避这类问题的?我们团队从早些时候开始,建立了一个服务专门每天跑项目的Lint检查,跑完将警告汇总分配到对应的负责人身上,并邮件告知他,直到上线。几个版本下来,整个团队都养成了上线前清空警告的习惯,空指针异常基本没有再发生。这个方案基本和技术难度没有关系,看起来很简单的一个事情,但是实践下来很切实的解决了问题。

这是今年我对技术的一些思考吧,仁者见仁,智者见智,主要就是想说希望深入学习技术的同时有时候也要尝试跳脱出来,站在更多的维度上看问题。

四.原生开发 or 跨平台技术

最后:学习总结——Android框架体系架构知识脑图(纯手绘xmind文档)

学完之后,若是想验收效果如何,其实最好的方法就是可自己去总结一下。比如我就会在学习完一个东西之后自己去手绘一份xmind文件的知识梳理大纲脑图,这样也可方便后续的复习,且都是自己的理解,相信随便瞟几眼就能迅速过完整个知识,脑补回来。

下方即为我手绘的Android框架体系架构知识脑图,由于是xmind文件,不好上传,所以小编将其以图片形式导出来传在此处,细节方面不是特别清晰。但可给感兴趣的朋友提供完整的Android框架体系架构知识脑图原件(包括上方的面试解析xmind文档)

除此之外,前文所提及的Alibaba珍藏版 Android框架体系架构 手写文档以及一本 《大话数据结构》 书籍等等相关的学习笔记文档,也皆可分享给认可的朋友!

——感谢大家伙的认可支持,Free Download请注意:点赞+点赞+点赞!!!
的朋友!

——感谢大家伙的认可支持,Free Download请注意:点赞+点赞+点赞!!!
CodeChina开源项目:《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》

  移动开发 最新文章
Vue3装载axios和element-ui
android adb cmd
【xcode】Xcode常用快捷键与技巧
Android开发中的线程池使用
Java 和 Android 的 Base64
Android 测试文字编码格式
微信小程序支付
安卓权限记录
知乎之自动养号
【Android Jetpack】DataStore
上一篇文章      下一篇文章      查看所有文章
加:2021-09-05 11:07:57  更:2021-09-05 11:10:13 
 
开发: C++知识库 Java知识库 JavaScript Python PHP知识库 人工智能 区块链 大数据 移动开发 嵌入式 开发工具 数据结构与算法 开发测试 游戏开发 网络协议 系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁

360图书馆 购物 三丰科技 阅读网 日历 万年历 2024年11日历 -2024/11/23 16:28:39-

图片自动播放器
↓图片自动播放器↓
TxT小说阅读器
↓语音阅读,小说下载,古典文学↓
一键清除垃圾
↓轻轻一点,清除系统垃圾↓
图片批量下载器
↓批量下载图片,美女图库↓
  网站联系: qq:121756557 email:121756557@qq.com  IT数码