2024年最全Android 技术的下半场，阿里巴巴二面被血虐

最新推荐文章于 2024-11-02 10:50:29 发布

2401_84520215

最新推荐文章于 2024-11-02 10:50:29 发布

阅读量877

点赞数 29

分类专栏：程序员文章标签： android

本文链接：https://blog.csdn.net/2401_84520215/article/details/138554367

版权

程序员专栏收录该内容

181 篇文章 0 订阅

订阅专栏

最后送福利了，现在关注我可以获取包含源码解析，自定义View，动画实现，架构分享等。
内容难度适中，篇幅精炼，每天只需花上十几分钟阅读即可。
大家可以跟我一起探讨，有flutter—底层开发—性能优化—移动架构—资深UI工程师 —NDK相关专业人员和视频教学资料，还有更多面试题等你来拿

录播视频图.png

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

读者们，早上好，我是 wingjay。

越来越多的人在提“移动端的下半场”、“Android 开发的焦虑”之类的，也有人在喊“技术天天在变，学也学不完”，“昨天 Kotlin 今天 Flutter”。其实我却认为，如果你技术达到了一定程度，你无需太过在意这些。

移动端真正进入下半场了吗？于我看来并没有，最多说“Android 技术的探索”进入了下半场，而整个市场还是乐观的。以前是 BAT 的天下，而近两年出来越来越多的独角兽：头条、抖音、拼多多、快手、小猿搜题等，这些公司的业务都在移动端上，他们需要招聘更多的移动端人才。如果真要说下半场，只能说很多小型创业公司在退出市场，这确实会导致很多入门工程师失业，但这也说明了这个行业在更加规范。

而且，对于 Android 工程师而言，这更是个好的时代。互联网下沉，那么下沉市场里的用户是使用 Android 多还是 iOS 多，大家都清楚。

那么，对于工程师而言需要做什么才能存活呢？很简单，要么转行，要么提高。我相信，一个技术不错的工程师，不但无需焦虑，而且在这个时代，能够拥有稳定的职业生涯和丰厚的收入。

Android 技术的下半场？

要说下半场，我更愿意说是“Android 技术的下半场”，随着这几年大量的工程师和公司投入研发，Android 技术已经从最早的简单页面，到越来越复杂的交互，再到动态化、插件化等新技术和黑科技，这个领域的深度在不断加深。

如果想成为优秀、不担心淘汰的工程师，绝不是一味跟风新技术，今天学 Kotlin、明天学 Flutter，疲于奔命；而应该持续努力去完善自己的知识体系，保持一定的技术深度。

因此，本专栏希望在大家做UI、界面开发之余，分享一些 Android 架构方面的知识和技能。

希望且相信这些技能能够让读者真正摆脱技术焦虑，最终找到自己的方向和竞争力。

业务同学需要了解架构吗？

有的同学会问，我平常都在写业务代码、写页面、调用 SDK，有必要去了解架构吗？答案很简单，业务是表，架构是里。变化万千的业务背后都是大同小异的架构。时代更迭，业务变迁，理解架构的技术人员可以处变不惊，而非疲于奔命。

因此，本人建议业务同学在繁重的业务开发之余，可以多去研究一些底层库原理，而非停留在花式调用 SDK 的阶段，这会让你具备更强的技术竞争力。

架构孵化于业务，服务于业务

不少公司的架构同学和业务同学都存在一种矛盾：架构与业务互相独立，导致输出的技术总是不能很好的满足业务需求，导致的结果是：架构同学有心无力，业务同学有苦难言。

实际上，真正好的架构是从业务中孵化出来的，而且能服务于更广阔的业务形态。

举几个例子大家就清楚了。

大家都知道阿里主营电商业务，而电商是强运营的，所以对于动态化有非常强的需求，也就是希望 App 尽可能像网页一样，能够随时更新页面内容。于是，阿里内部孵化出了 Weex，通过远程开发部署js代码，即可实时更新页面内容；

另外，手淘 App 对于整个阿里集团的战略意义非常大，它不仅是盈利怪兽，而且是整个集团的流量入口（手淘 DAU 自 2015 年即达 1.1亿）。这也就是阿里曾提出的“航母策略”：手淘如一座航母，集团内各种业务形态如飞猪、闲鱼、天猫等都可坐落在其上。于是，Atlas 诞生了，所有App 都可以轻松集成到手淘上，享受流量滋养。

类似的例子还有很多，比如大家熟知的微信，需要保证消息在任何复杂网络下都能有最高的到达率。因此微信自研了一套跨平台长连接方案，提出智能心跳方案、多种弱网应对策略如多级超时等，最终推出了 Mars，保证了全国各种网络环境下的用户都能稳定的收发消息。

有些同学可能了解阿里 15 年提出的“大中台，小前台战略”，搭建集团数据中台、技术中台，帮助各种前台业务快跑前进；这样的技术架构和组织架构帮助阿里快速孵化出各种新的业务，比如 18 年初的淘宝特价版，据朋友了解整个 App 从启动到上线只用了短短一个多月的时间。今年，腾讯组织架构调整，担任 CTO 的张志东就提到：“没有能帮助到公司级的数据中台建设，我个人也蛮遗憾。”，自此腾讯也正式启动了“中台架构”建设。

所以说，不同的业务形态，能孵化出特有的架构。

架构是根，扎得越深，业务才越能开枝散叶。

专栏技术图谱

闲话说了不少，下面正式谈一谈本专栏会覆盖的一些技术点吧。这些技术点会基于本人日常的工作积累，同时结合各大厂开源的技术体系，（当然对于阿里闭源的会尽量规避掉，线下可以做一些技术探讨）。

下面，我把后面专栏会覆盖到的技术点列出来，当然在写作的过程中还会逐步调整。

\1. 动态化专题

由于 App 获客成本不断提高，动态化是近年来越来越重要的技术架构，例如 React Native、小程序、快应用等都在试图让 App 具备实时更新、随手可得。本专题会对各厂提出的动态化方案进行分析，如 JsBridge；包括小程序方案的一些实现思路，比如多进程的 H5 容器架构；另外，还会分析一些适用于移动平台的动态化编程语言如 Lua，Javascript 等。

\2. 图片专题

对于亿级 App 而言，图片的任何优化都对于流量、体验等具有重要意义。比如 Google+ App 采用 WebP 图片格式后，每天节省了 50TB 数据存储空间。因此，本专题会谈一下各大厂如腾讯、FB、Google 等在图片优化方面提出过哪些方案，比如 WebP vs SharpP；另外也会分析一些大家用的比较多的 Glide、Fresco 是如何做图片缓存、如何基于 Dalvik/Art 不同的内存结构来优化。

\3. 省流专题

上面谈到了图片的压缩，其实节省流量是一个永恒的话题，它不仅能改善用户体验，也能帮助减少用户流量开销，节省公司成本。因此，本专题会谈一谈如何监控 Android 流量；有哪些常用的 Diff 及压缩算法，比如 Tinker 里自研的Diff算法 vs Google 提出的 google-diff vs BsDiff 等；如何选用数据通信格式如 json、ProtoBuf；FastJson、Jackson 各自的优势等等。

\4. 网络专题

大多数业务同学对网络的认识就是 OkHttp+Json 解析，实际上，网络这一块还存在非常多值得研究的技术点。一个优质的 App，除了在网络良好的环境下运行，更重要的是，必须在弱网、网络劫持、网络慢等复杂环境下也要良好运行，而且还得快，这也就涉及到 DNS 加速、网络结果缓存等。

之前大厂都在提“页面秒开”的概念，页面打开速度很大程度取决于当下的网络环境，也对于用户体验和留存有非常大的影响。这个专题我们谈谈网络相关的技术点。

\5. 监控与日志专题

对于监控和日志，多数人的印象是集成一个第三方 SDK，如 Fabric、Bugly 等。业务同学或许对日志了解不是特别多，但实际上日志是至关重要的，尤其是在排查复杂问题时。

本专题我们谈一下如何做到日志不丢失，如何后台上报且不影响 App 运行，最有意思的一点：如何利用长连接等技术，实时拉取任意用户的本地详细日志。

\6. 移动****高可用专题

高可用是近年来阿里等大厂在不断追求的，所谓高可用，就是尽最大可能提高 App 的可用性，保证网络、内存、CPU 等资源资源在可控范围内，严格监控客户端的运行性能、卡死、闪退、内存开销、流量电量开销等全方面因素，并要在客户端发生问题的第一时间，以配置即时下发、动态修复、安全模式、线上监控报警等多种方式进行实时修复，从而保证客户端的高可用性。

\7. 安全专题

安全专题就离多数比较远了，这里我们讲解一些常见的和业务相关的安全话题，具体后续补充。

专栏技术点列表

\1. 动态化专题