一个移动端开发者，对未来的思考，2024年你与字节跳动只差这份笔记

平常都在写技术类文章，今天写篇作为一个移动端开发者对过去一年的总结和思考吧，既是对过去的回顾，也是对未来的思考。

2019

===============================================================

这一年对于我来说，当然最多的时间还是花在工作上。对于移动端开发来说，2019年依然是动荡的一年，各种跨平台技术依然层出不穷，原生将死的论调依然在各大公众号热炒和营销。

这一年，随着工作经验的提升，自己对技术的看法和对未来的方向也发生了些许改变,分享一下自己这一年的总结与反思吧。

一. 这一年都做了什么？

=======================================================================

这一年还是挺忙碌的，不管是纯业务开发还是技术改造或者是对我们产线现有问题或者痛点的解决方案都有一些个人的输出，技术确实不能是半空建楼阁，依托具体的业务问题，以技术方案去解决，是更加良好的循环和沉淀，还有很多东西值得去提高去学习。

1.上半年产线中的几个复杂页面的流畅度在版本迭代中一直会由于开发的不注意导致频繁出现反复，分析下来根本原因是由于缺乏必要的监控以及可持续的优化手段，所以2019Q1在业务需求之外主要就是实现了产线内部对于用户流畅度的监控以及优化。

主要包括：debug下帧率的监控、上线前主流程流畅度的自动化测试、线上用户真实流畅度监控、实现耗时方法排查工具：MethodTraceMan、一些收益比较大的流畅度优化等，主要目标是从监控到排查问题工具再到卡顿解决形成一个闭环的方案。

https://github.com/zhengcx/MethodTraceMan

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

2.对于内存上的问题，我们产线其实很早之前就碰到了，线上爆出可观数量的OOM，当时我对我们app做了一次内存上的分析与优化，效果还是非常明显的，当时对分析和优化过程做了记录：

实践App内存优化：如何有序地做内存分析与优化

后续的几个版本中我们发现OOM的数量大幅度下降，但是依然会有少数的OOM上报，分析下来发现这部分发生OOM的机型大部分单应用最大可用的内存只有64M，也就是说有部分很老旧的机型内存实在小，所以我们最后上线了内存适配方案，也就是对不同内存大小的机型做不同的内存使用方案，比如对于一些老旧内存非常小的机型，选择适当去降低图片的质量，关闭一些花哨的动画，对于一些大内存的使用更加谨慎，更加及时的去做一些内存的回收等等，收到了不错的效果。

后面对于内存方面的优化一直没有补充到上面的那篇文章里，等有空了，补上后续的一些内存优化手段，供交流分享。

3.Google近年来对Jetpack进行不断的补充和完善，我也对Jetpack进行一定的学习和引进，特别是lifecycle组件等已经在我们产线中使用很久了，我们使用响应式的编程方式来组织或者重构问题代码，解决了一些我们产线现有的问题，提高了效率。

还是那句话，不应该以新或者旧来看待技术，而应该以他是否能提高你的效率以及解决你的问题的维度来看待他。

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

https://juejin.im/post/5c026915f265da615876e42e

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是怎么实现的呢？

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级安卓工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Android）

总结

最后为了帮助大家深刻理解Android相关知识点的原理以及面试相关知识，这里放上相关的我搜集整理的24套腾讯、字节跳动、阿里、百度2019-2021面试真题解析，我把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包知识脉络 + 诸多细节。

还有 高级架构技术进阶脑图、Android开发面试专题资料 帮助大家学习提升进阶，也节省大家在网上搜索资料的时间来学习，也可以分享给身边好友一起学习。

点击：《Android架构视频+BAT面试专题PDF+学习笔记​》

即可免费获取~

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

架构视频+BAT面试专题PDF+学习笔记](https://bbs.csdn.net/topics/618156601)​》**

即可免费获取~

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

2021年虽然路途坎坷，都在说Android要没落，但是，不要慌，做自己的计划，学自己的习，竞争无处不在，每个行业都是如此。相信自己，没有做不到的，只有想不到的。祝大家2021年万事大吉。