Android 技术的下半场

本文首发于小专栏《《亿级 Android 架构》专栏随谈》，更多Android架构文章欢迎关注《亿级Android架构》

移动端的下半场？

越来越多的人在提“移动端的下半场”、“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的张志东就提到：“没有能帮助到公司级的数据中台建设，我个人也蛮遗憾。”，自此腾讯也正式启动了“中台架构”建设。

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

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

《亿级 Android 架构》地址：https://xiaozhuanlan.com/topic/1934527806

专栏技术图谱

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

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

动态化专题
由于App获客成本不断提高，动态化是近年来越来越重要的技术架构，例如React Native、小程序、快应用等都在试图让App具备实时更新、随手可得。本专题会对各厂提出的动态化方案进行分析，如JsBridge；包括小程序方案的一些实现思路，比如多进程的H5容器架构；另外，还会分析一些适用于移动平台的动态化编程语言如Lua，Javascript等。
图片专题
对于亿级App而言，图片的任何优化都对于流量、体验等具有重要意义。比如Google+ App采用 WebP 图片格式后，每天节省了 50TB数据存储空间。因此，本专题会谈一下各大厂如腾讯、FB、Google等在图片优化方面提出过哪些方案，比如WebP vs SharpP；另外也会分析一些大家用的比较多的Glide、Fresco是如何做图片缓存、如何基于Dalvik/Art不同的内存结构来优化。
省流专题
上面谈到了图片的压缩，其实节省流量是一个永恒的话题，它不仅能改善用户体验，也能帮助减少用户流量开销，节省公司成本。因此，本专题会谈一谈如何监控Android流量；有哪些常用的Diff及压缩算法，比如Tinker里自研的Diff算法 vs Google提出的google-diff vs BsDiff等；如何选用数据通信格式如json、ProtoBuf；FastJson、Jackson各自的优势等等。
网络专题
大多数业务同学对网络的认识就是OkHttp+Json解析，实际上，网络这一块还存在非常多值得研究的技术点。一个优质的App，除了在网络良好的环境下运行，更重要的是，必须在弱网、网络劫持、网络慢等复杂环境下也要良好运行，而且还得快，这也就涉及到DNS加速、网络结果缓存等。
之前大厂都在提“页面秒开”的概念，页面打开速度很大程度取决于当下的网络环境，也对于用户体验和留存有非常大的影响。这个专题我们谈谈网络相关的技术点。
监控与日志专题
对于监控和日志，多数人的印象是集成一个第三方SDK，如Fabric、Bugly等。业务同学或许对日志了解不是特别多，但实际上日志是至关重要的，尤其是在排查复杂问题时。
本专题我们谈一下如何做到日志不丢失，如何后台上报且不影响App运行，最有意思的一点：如何利用长连接等技术，实时拉取任意用户的本地详细日志。
安全专题
安全专题就离多数比较远了，这里我们讲解一些常见的和业务相关的安全话题，具体后续补充。
高可用专题
后续补充
GC专题
后续补充

专题计划技术点列表

动态化专题
- 如何让JavaScript与App交互
- 如何实现“即点即用”之小程序、快应用
- H5容器之多进程架构
- 动态化编程之Lua
- ...等
图片专题
- 图片压缩之WebP与腾讯SharpP的实现机制
- 图片内存优化之Glide和Fresco原理篇
- png jpg等常用图片格式的内存、解压速度分析
- ...等
省流专题
- Android流量监控
- 文件压缩 zip 7z gzip等
- 增量更新之diff算法，案例：Tinker自研diff/patch算法
- 图片缓存技术
- WebView缓存优化
- 数据传输协议对比之ProfoBuf、FastJson、Jackson
- ...等
网络专题
- 可靠长连接的意义
- HTTPDNS DNS劫持
- 网络嗅探
- Http2/Https/QUIC协议对比
- CDN 削峰填谷
- 如何做全局网络限流，保证业务流量高优先级
- ...等
监控与日志专题
- mmap日志落地方式，开源项目Logan，xlog等分析
- 通过长连接动态拉取日志
- 如果长连接断开、通过短连接兜底拉取日志
- 日志上报，本地分片存储及后台上报策略
- ...等
安全专题
- 移动端的加密算法之对称与非对称，防篡改
- 常规编码方式一览 md5 base64
- ...等