作为一名资深的Android 开发者。从2017年下半年开始,就听到各种言论,例如“Android 开发凉凉”、“移动端开发没出路了赶紧转行”、“要被XXX 替代了” 等等,充分反映了大家焦虑的心态。
移动端开发真的要凉凉了吗?也经常有粉丝私信我,在群里聊起这个话题,今天我决定写下自己的一些看法,供大家参考。
移动端开发的现状
移动端开发的现状是什么?我们可以从自己写的代码中寻找线索。以Android 为例,很多大公司的移动端开发者写的最多的代码是这样的:
LinearLayout layout = new LinearLayout; layout.addView(xxxx);
或者也许是这样的:
public class XXXView extends RelativeLayout { public XXXView(Context context) { this(context, null); } public XXXView(Context context, @Nullable AttributeSet attrs) { this(context, attrs, 0); } public XXXView(Context context, @Nullable AttributeSet attrs, int defStyleAttr) { super(context, attrs, defStyleAttr); initView; } private void initView { LayoutInflater.from(getContext).inflate(R.layout.xxxlayout, this, true); ... } public void setData(XXX xxx) { ... }
又或者是对着xml 标签做出各种骚操作——UI 开发。
没错,如今移动端技术栈已经愈发趋于成熟完善,对业务来说,就连大公司的工程师也是在做UI 的展示逻辑。大公司产品相对比较完善,后端管控了大部分业务逻辑,客户端做的就是取到后端的数据,然后通过setText(xxx)展示出来,然后通过接口返回的Boolean 值来判断View 显示还是隐藏。
我听到很多人说,工作几年感觉自己没什么提升,天天都在堆代码,随便找个刚毕业的学生也能分分钟替代自己,于是就很焦虑。那对于工作几年的人来说,要想尽可能不让自己过早的被替代、被淘汰,就需要选一个有潜力的有前景的领域深挖。
那么2020移动端开发的需要关注的技术有哪些?
1. Kotlin
Kotlin 通常被视为下一个 Java,它是由谷歌和 JetBrains(Android Studio 开发者)赞助的。Java 从一开始就一直是 Android 应用的首选开发语言,但近年来 Kotlin 迅速普及,如今在 10,000 种 Google Play 应用中有近 60%使用了 Kotlin 。虽说在少数需要访问底层原生代码的情况下,仍会继续使用 C++;但在其他情况下,Kotlin 都可以代替 Java。
Kotlin 的主要优势是与 Java 的完全互操作性,这意味着开发人员可以尽可能迁移旧代码,而不用完全重写整个应用程序。这两种语言兼容得很好,Android Studio 甚至可以自动从 Java 转换为 Kotlin。
这种兼容性,加上更简洁的语法和数百项细小改进,使 Kotlin 在 StackOverflow 的 2019 年开发人员调查中成为第四大“最受欢迎”和第五大“想要”的编程语言,在所有移动编程语言中排名最高。
迁移现有应用有一个好方法,就是在修改现有 Java 文件时将其转换为 Kotlin。虽然这意味着你要把经常编辑的文件转换过去,会增加代码审查的复杂度(比如会面临潜在的冲突),但由于转换后的区域能得到审查,因此可以确保任何问题都能被发现。
目前 Candyspace 中使用的 Kotlin 代码占 86%(并且一直在增长),其余的 14%是实用工具 / 转换代码,这些代码已经有些年头没改动过了。
2. Jetpack
谷歌的 AndroidX/Jetpack 库是一组实用工具,旨在简化常见的应用需求。例如用于设备上数据库的 Room ,或用来在底层数据更改时更新显示内容的 LiveData 。
有了 Jetpack 库,新项目就省掉了重新发明轮子的麻烦,也不必等待其他开发人员来开源他们的实现方式,现在每位开发者都能获取到那些基础要素了。这些库更新非常频繁,新功能不断推出,错误修复也会及时发布。由于这些库是为了协同工作而构建的,因此多使用 AndroidX 库有助于最大程度地减少应用中出现意外。
从开发工作起步开始就使用 Jetpack 库可以节省数百小时的时间,但我们也可以将已有的应用迁移到 Jetpack 库上面。虽然看起来很麻烦,但由于这些库非常流行,针对迁移工作的指南也很容易找到。至少,底层 Android 元素(视图、片段等)可以自动转换。
在 Candyspace,我们使用了 Data Binding 和 ViewModel,并可能很快加入 Room 和 Navigation。
3. 模块化设计
一直以来,应用都被构建为一个巨大的“应用”模块,其中包含整个应用所需的一切。尽管这样做确实能让资源共享起来更容易,但也意味着这个应用的某些部分无法为其他应用 / 开源项目所重用;更重要的是,对应用做出更改时必须重新编译整个代码库。
相反,如果应用由许多较小的模块组成,则只需重新编译做出更改的代码即可,从而大大缩短了构建时间。此外,模块化设计还为高级 Android 特性(例如即时应用——用户无需安装任何内容即可使用你的应用的部分功能,和动态特性——按需安装应用的各个部分)的应用打开了大门。
将一款现有应用拆分为多个模块可能会是一个很复杂的工作,因为会因此而发现之前隐藏的问题(“DateUtility 是什么东西?为什么每个类都需要它!?”);但是一旦改造完成,代码库就会进入一种更加健康的状态。另外,如果一款新的应用需要类似的功能,则可以快速重用已有模块,从而大大节省时间!
模块化应用架构的一个示例(来源:本文作者创建!)
虽然设计一个模块化架构可能是很复杂的任务,但我之前已经写过一些指导性原则,这些原则受到了 Nikits Kozlov 关于模块化和构建时间的文章的启发。Plaid 也写了一篇介绍他们向模块化设计迁移经验的文章。
在 Candyspace,我们的应用设计都是完全模块化的,以尽量减少构建时间对开发工作的中断影响。
4. App Bundle
使用传统的 APK 将应用分发到用户的设备时,必须安装针对所有设备准备的所有资源。这意味着每张位图图像可能会有 5 个副本(用于不同的屏幕精度),还要安装针对不同设备架构的多个库版本,甚至还得安装多组边距和填充值。
使用 App Bundle 分发一款应用时,用户下载的 APK 只包含他们实际所需要的资源。这样一来,平均的应用大小就会减少 20%,而未经优化的应用改换格式后应用大小将会得到更显著的缩减。
缩减应用大小的示例(资料来源: https://events.google.com/io2018/)
App Bundles 是 18 个月前刚刚诞生的,但已经有超过 25%的应用安装时使用了这种格式!这是谷歌推荐使用的格式,并且大多数应用几乎无需改动就能使用这种格式,只需在 Play 商店上处理一下 App Bundle 的签名即可。
在 Candyspace,我们正在迁移到 App Bundles 上,同时尽量避免破坏我们现有的工作流程(Slack、QAing 构建、非 Google Play 安装)。Alistair Sykes 的文章是一份很棒的迁移参考资料,文章考虑到了 CI 服务器、Slack 和 Google Play 内部应用共享等事项。
5. 测试
是的,测试。当然,测试并不是什么闪亮的新特性,也不是用户能看到的内容,但想要确保一款已有一定用户基础的应用的可靠性,就必须要彻底测试你的应用程序才行。由于崩溃率会直接影响你的 Play 商店评分(并且肯定会拖累评分!),因此应该设法将其保持在较低水平上。
测试金字塔(来源:developer.android.com)
Android 的三种最常见的测试类型分别是(降序排列):
单元测试,例如:我的平方根函数会返回平方根吗?
这些测试将构成你测试流程的大部分内容,它们用来确保特定的代码段(例如一个函数)能按预期正常运行。当你对一个部件建立起信心后,就可以将其用于…
集成测试。例如:我的数学模块可以与位置模块协同工作吗?
这些测试可确保你的各个代码区域(模块或层)可以正常协同工作。知道应用的组件可以正确相互通信后,你就可以添加…
自动化的 UI 测试,例如:用户可以在应用上标记一个位置吗?
在设备或仿真器上只会运行这些测试,它们能确保应用按预期提供完整的用户体验。这些测试通常比其他类型的测试要慢得多(并且运行起来更加不便)。
谷歌建议将测试的分布定为 70%的单元测试、20%的集成测试和 10%的大型测试,占比较小的部分需要更长的执行时间、维护时间和实施时间。
最好的测试资源是官方文档,因为它提供了所有测试类型的介绍,以及如何将其实现到项目中的教程。
在 Candyspace,我们将重点放在单元测试上,其占比要比谷歌建议的比例更大,以确保所有新类的行为都是可预测的。我们目前还在改进自动 UI 测试,以减少对手动测试的依赖。
在编程的任何领域,关于解决问题的最佳方法都会有一百种不同的意见;但 Android 有绝对优势:Android 拥有一个庞大的开发者社区,这意味着一个十分优秀的新技术会迅速在开发者中普及。当你在互联网上向陌生人寻求帮助时,如果你找的是“Jetpack LiveData”而不是“之前的开发人员从 Web 开发者朋友那里复制并转换的库”,成功获得答案的可能性就会大得多!