Android 开发工程师自述:2年的开发,我总结了7条经验

全文共3547字,预计学习时长11分钟

Android 开发工程师自述:2年的开发,我总结了7条经验

来源:wap.anzow.com

“纸上得来终觉浅,绝知此事要躬行。”

“没有调查就没有发言权。”

“实践出真知。”

古今中外,无数名言警句都告诉我们实际去做一件事的重要性。

Android 开发工程师自述:2年的开发,我总结了7条经验

笔者从最初对安卓开发萌生兴趣到现在已有两年之久了,期间做过几个项目也开发过别的,今天就跟大家分享一下这段时间里笔者亲身总结的7条经验。

1.第三方库:找到正确的平衡点

Android 开发工程师自述:2年的开发,我总结了7条经验

Android Arsenal上的一些库

在开始第一个项目时,所有的操作笔者都想从零开始,然后几乎是把第三方库打入了冷宫,本想着自己可能以这种方式会学到更多的东西。

兴许是第一个项目,不用第三方库也行,但这通常是不可取的。最后无非是浪费大量的时间“造轮子”(指业界已有公认的软件或库),所以千万别这样。

有了第一次的经验,笔者开始使用开源库。任何情况下都会有免费的库,这点非常好。所以就添加了一个库,结果根本停不下来。

猜猜后来怎样了?笔者的项目到最后就是杂七杂八的第三方库扭为一体。所以及时止损吧,好好选库。不是所有的都靠谱,况且不一定好上手。

笔者的建议就是寻找平衡点。如果在开发的过程中遇到难题,而这个难题恰巧是别人用某个库完美解决的,那就这个库没错了。要是需要HTTP客户端,选它—— Retrofit。

Android 开发工程师自述:2年的开发,我总结了7条经验

如果下载和管理的图像很多的话,就用 Glide,这些库绝对好用,还稳定,谁人都知道。

但记住不是所有的库都会这么美好。最好每次都查查这些库出自何方神圣,有时间的话再研究一下开源代码,看看问题是如何解决的。

Android Arsenal几乎动用了所有可用的安卓库来维护大型数据库。

2.从一开始就选对架构

你听说过类似于MVC、MVP、MVVM这样的缩略词吗?它们代表不同的软件架构,而且都是需要了解的。

很多小白是在activity类中敲代码,刚开始这样似乎行得通,但相信我,这件事没这么简单。

项目越大,代码就会越复杂还高度耦合,使得后续的测试、维护、新功能的研发变得非常棘手。

所以才推荐大家从一开始就选用一目了然的软件架构。如上文提到的这些架构各有千秋,下面是迄今为止谷歌推荐的App架构:

Android 开发工程师自述:2年的开发,我总结了7条经验

安卓开发员推荐的App架构

从图中可以看出,每一个部分仅由下部与其相连的组件决定。

这样就会带来一致的用户体验,不仅考虑到了关注点分离(separationof concerns),还针对测试和可扩展度进行了优化。很显然,任何架构都有不完美的时候,就像谷歌说的一样:

根本不存在一个架构能满足任何软件的情况。言外之意,对于大多数软件和工作流,从一开始就使用推荐的架构会是好的开端。

由于不是本文的重点,笔者不会对该架构展开过多的解释,但会给大家列举一些有用的资源:

l app架构的指南

l 安卓架构组件的基础样本

3.重要的事情说三遍:测试测试测试

Android 开发工程师自述:2年的开发,我总结了7条经验

你曾多少次想过:“在手机上测试app,发现成功了!”

其实并不够,简单的测试可能会在开发时让你少费几天功夫,但做起来可就要搭上好几周的时间了。

产品发布前,做足测试可以帮助我们检查系统的鲁棒性、操作性以及可用度。

那该如何测试app呢?这个问题可就太宽泛了,测试类型五花八门,各个都有自己的使命。

Android 开发工程师自述:2年的开发,我总结了7条经验

安卓开发员提供的测试等级

在了解上图的基础上,可以将测试分为以下三类:

l 单元测试:一次使用一个类来验证性能类别。

l 集成测试:验证模块内不同层次堆栈间的交互以及相连模块的交互。

l UI测试:验证用户界面和用户流

基于app的用例,需要自行决定进行多少种不同测试。

谷歌的经验法则建议---将测试分为70%的小测验(单元测试),20%的中等测试(集成测试)和10%的大型测试(UI和端到端测试)。

l 在安卓平台上测试应用:这里讲了测试应用所需的所有东西

l 在安卓上测试驱动开发(TDD):Google I/O 2017的关于TDD的视频会议

4.Android Studio ,我们的好伙伴

无可厚非,我们已经利用了IDE(集成开发环境),但真的其物尽其用了吗?

Android Studio里内置了很多有助于软件开发的工具,下面列举了一些笔者最常用到的:

l 设备模拟器可以对不同设备上、各种安卓版本的应用程序进行测试。

l 安卓PK分析器可以通过对APK大小的检测分析出程序的大小。

l 实时性能分析器(Realtime Profilers)可以对CPU、内存和网络使用情况进行实时统计分析。

l Firebase助手可以将应用程序与其联系起来,只需几步操作即可将所有Firebase服务都添加上。

l Vector Asset Studio可以帮助给每个密度(密度指磁盘存储数据的可用空间)创建新的位图图像。

你知道Android Studio还有一个功能是将PC变成“烤炉”吗?

Android 开发工程师自述:2年的开发,我总结了7条经验

更多介绍和功能请参见Android Studio

5.简单清晰的用户界面(UI)

如果在一家大型企业当安卓开发员,UI和UX的设计就是设计者的事了,程序员们大可不必担心。

不过要是初创企业或是私人项目,可能就得费些心思设计UI和UX。相信我,好的界面会锦上添花,而糟糕的界面会毁了一个好项目。

“用户界面就跟笑话一样,你若解释它,就证明它还不够好。”——马丁·勒布朗(Martin LeBlanc)

过去笔者常犯的一个错误就是用户界面上放的东西太多,元素过多只会给用户带来困扰,还会让别人觉得没有美感。建议大家从简,简单且清晰。

特别是不擅长设计的人更要避讳这一块,尽量做用户一看就懂的基础界面。成形后可以进行改进使其更美观,这样用户会留下更深的体验印象。

记住通过不同大小的显示器和DPI来测试UI,不要用固定的测量单位,比如px;多用动态的单位,比如用dp(或测试文本的sp)。

l Dribbble:里面汇集了各路神仙,不知道从哪下手,可以在这上面寻找灵感。

l 材料设计语言(Google Material Design):该系统适应性强,为设计最佳用户界面提供了指导、组件和工具系统。

l 《设计心理学》(The Psychology Of Everyday Things):唐·诺曼写的这本书讲了日用品的可用性设计,值得一看。

6.发布清单(Release Checklist)

Android 开发工程师自述:2年的开发,我总结了7条经验

来源:Pexels

现在觉得自己的应用程序可以发布了?真的吗?你怎样肯定呢?这个时候,千万不可草率行事,最好问自己几个问题:

l 是否移除了所有纠错代码?

l 测试足量吗?

l 在构建Gradle时,是否更新了名称和版本代码?

l 是否启用了Proguard 来混淆APK代码?

l 是否对应用程序进行了本地化操作?

l 是否在Google Play上准备了开发者账户?

如果答案都是“嗯”,那就可以继续自己的计划了。笔者建议大家做一个Android App Bundle (aab)来优化应用程序的大小和资源,而非APK。

在 Google Play发布应用程序后,要不断查看用户的反馈和所有的分析数据。这对程序的改进有非常大的帮助。

这是安卓开发员提供的检查清单,不容错过。

7.要用Git

Git是版本控制系统(VCS),它最基本的两大作用:一是追踪文件的变动,二是简化由多个开发员参与的大型项目中的工作。

我也不知道自己为何会用Git,其实直接给项目进行备份也可以。——来自三年前的我

现在笔者知道了。

并且告诉大家:程序员们需要Git,它对工作流的帮助简直妙极了。(这句话要是三年前有人跟我说就好了)。

Git妙在何处?理由如下:

l 资源代码安全地储存在云端,随用随取。

l 所有以往的代码版本都可使用,可以检测旧版本,而且出现错误时可以回到以前的版本。

l 团队工作得到了简化。每个开发员都可以在并行分支上进行工作,有需要时合并更改。

l 能开发数以千计的开源项目。

l 有GitHub和BitBucket这样的平台,创建并展示自己项目的介绍也可以实现。

理由千万条,而笔者希望这些足以传递一条信息:认为自己不需要Git,是错的。

GitHub和BitBucket指南帮你上手Git

Android 开发工程师自述:2年的开发,我总结了7条经验

来源:Pexels

今天,笔者分享了一些自己在安卓开发期间亲身学到的东西,但肯定有更多的知识有待探索。

如果大家有其他宝藏级建议,尤其是适合初学者的,请在下方踊跃留言哦。

Android 开发工程师自述:2年的开发,我总结了7条经验

Android 开发工程师自述:2年的开发,我总结了7条经验

留言点赞关注

我们一起分享AI学习与发展的干货

如转载,请后台留言,遵守转载规范

相关推荐