写点什么

Android 技术的下半场 (1),android 开发书籍下载

用户头像
Android架构
关注
发布于: 刚刚

Android 技术的下半场

文 | wingjay (转载请注明出处)


关注公众号:wingjay


同名微博:@iam_wingjay



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


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


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


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


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


Android 技术的下半场?


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


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


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


《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开:qq.cn.hn/FTe 免费领取
复制代码


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


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


有的同学会问,我平常都在写业务代码、写页面、调用 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. 动态化专题


  • 如何让 JavaScript 与 App 交互

  • 如何实现“即点即用”之小程序、快应用

  • H5 容器之多进程架构

  • WebView 全面加速方案

  • 动态化编程之 Lua

  • ...等

用户头像

Android架构

关注

还未添加个人签名 2021.10.31 加入

还未添加个人简介

评论

发布
暂无评论
Android 技术的下半场(1),android开发书籍下载