“纸上得来终觉浅,绝知此事要躬行。”
“没有调查就没有发言权。”
“实践出真知。”
古今中外,无数名言警句都告诉我们实际去做一件事的重要性。
笔者从最初对安卓开发萌生兴趣到现在已有两年之久了,期间做过几个项目也开发过别的,今天就跟大家分享一下这段时间里笔者亲身总结的7条经验。
1.第三方库:找到正确的平衡点
AndroidArsenal上的一些库
在开始第一个项目时,所有的操作笔者都想从零开始,然后几乎是把第三方库打入了冷宫,本想着自己可能以这种方式会学到更多的东西。
兴许是第一个项目,不用第三方库也行,但这通常是不可取的。最后无非是浪费大量的时间“造轮子”(指业界已有公认的软件或库),所以千万别这样。
有了第一次的经验,笔者开始使用开源库。任何情况下都会有免费的库,这点非常好。所以就添加了一个库,结果根本停不下来。
猜猜后来怎样了?笔者的项目到最后就是杂七杂八的第三方库扭为一体。所以及时止损吧,好好选库。不是所有的都靠谱,况且不一定好上手。
笔者的建议就是寻找平衡点。如果在开发的过程中遇到难题,而这个难题恰巧是别人用某个库完美解决的,那就这个库没错了。要是需要HTTP客户端,选它——Retrofit。
如果下载和管理的图像很多的话,就用Glide,这些库绝对好用,还稳定,谁人都知道。
但记住不是所有的库都会这么美好。最好每次都查查这些库出自何方神圣,有时间的话再研究一下开源代码,看看问题是如何解决的。
AndroidArsenal几乎动用了所有可用的安卓库来维护大型数据库。
2.从一开始就选对架构
你听说过类似于MVC、MVP、MVVM这样的缩略词吗?它们代表不同的软件架构,而且都是需要了解的。
很多小白是在activity类中敲代码,刚开始这样似乎行得通,但相信我,这件事没这么简单。
项目越大,代码就会越复杂还高度耦合,使得后续的测试、维护、新功能的研发变得非常棘手。
所以才推荐大家从一开始就选用一目了然的软件架构。如上文提到的这些架构各有千秋,下面是迄今为止谷歌推荐的App架构:
安卓开发员推荐的App架构
从图中可以看出,每一个部分仅由下部与其相连的组件决定。
这样就会带来一致的用户体验,不仅考虑到了关注点分离(separationofconcerns),还针对测试和可扩展度进行了优化。很显然,任何架构都有不完美的时候,就像谷歌说的一样:
根本不存在一个架构能满足任何软件的情况。言外之意,对于大多数软件和工作流,从一开始就使用推荐的架构会是好的开端。
由于不是本文的重点,笔者不会对该架构展开过多的解释,但会给大家列举一些有用的资源:
lapp架构的指南
l安卓架构组件的基础样本
3.重要的事情说三遍:测试测试测试
你曾多少次想过:“在手机上测试app,发现成功了!”
其实并不够,简单的测试可能会在开发时让你少费几天功夫,但做起来可就要搭上好几周的时间了。
产品发布前,做足测试可以帮助我们检查系统的鲁棒性、操作性以及可用度。
那该如何测试app呢?这个问题可就太宽泛了,测试类型五花八门,各个都有自己的使命。
安卓开发员提供的测试等级
在了解上图的基础上,可以将测试分为以下三类:
l单元测试:一次使用一个类来验证性能类别。
l集成测试:验证模块内不同层次堆栈间的交互以及相连模块的交互。
lUI测试:验证用户界面和用户流
基于app的用例,需要自行决定进行多少种不同测试。
谷歌的经验法则建议---将测试分为70%的小测验(单元测试),20%的中等测试(集成测试)和10%的大型测试(UI和端到端测试)。
l在安卓平台上测试应用:这里讲了测试应用所需的所有东西
l在安卓上测试驱动开发(TDD):GoogleI/O2017的关于TDD的视频会议
4.AndroidStudio,我们的好伙伴
无可厚非,我们已经利用了IDE(集成开发环境),但真的其物尽其用了吗?
AndroidStudio里内置了很多有助于软件开发的工具,下面列举了一些笔者最常用到的:
l设备模拟器可以对不同设备上、各种安卓版本的应用程序进行测试。
l安卓PK分析器可以通过对APK大小的检测分析出程序的大小。
l实时性能分析器(RealtimeProfilers)可以对CPU、内存和网络使用情况进行实时统计分析。
lFirebase助手可以将应用程序与其联系起来,只需几步操作即可将所有Firebase服务都添加上。
lVectorAssetStudio可以帮助给每个密度(密度指磁盘存储数据的可用空间)创建新的位图图像。
你知道AndroidStudio还有一个功能是将PC变成“烤炉”吗?
更多介绍和功能请参见AndroidStudio
5.简单清晰的用户界面(UI)
如果在一家大型企业当安卓开发员,UI和UX的设计就是设计者的事了,程序员们大可不必担心。
不过要是初创企业或是私人项目,可能就得费些心思设计UI和UX。相信我,好的界面会锦上添花,而糟糕的界面会毁了一个好项目。
“用户界面就跟笑话一样,你若解释它,就证明它还不够好。”——马丁·勒布朗(MartinLeBlanc)
过去笔者常犯的一个错误就是用户界面上放的东西太多,元素过多只会给用户带来困扰,还会让别人觉得没有美感。建议大家从简,简单且清晰。
特别是不擅长设计的人更要避讳这一块,尽量做用户一看就懂的基础界面。成形后可以进行改进使其更美观,这样用户会留下更深的体验印象。
记住通过不同大小的显示器和DPI来测试UI,不要用固定的测量单位,比如px;多用动态的单位,比如用dp(或测试文本的sp)。
lDribbble:里面汇集了各路神仙,不知道从哪下手,可以在这上面寻找灵感。
l材料设计语言(GoogleMaterialDesign):该系统适应性强,为设计最佳用户界面提供了指导、组件和工具系统。
l《设计心理学》(ThePsychologyOfEverydayThings):唐·诺曼写的这本书讲了日用品的可用性设计,值得一看。
6.发布清单(ReleaseChecklist)
来源:Pexels
现在觉得自己的应用程序可以发布了?真的吗?你怎样肯定呢?这个时候,千万不可草率行事,最好问自己几个问题:
l是否移除了所有纠错代码?
l测试足量吗?
l在构建Gradle时,是否更新了名称和版本代码?
l是否启用了Proguard来混淆APK代码?
l是否对应用程序进行了本地化操作?
l是否在GooglePlay上准备了开发者账户?
如果答案都是“嗯”,那就可以继续自己的计划了。笔者建议大家做一个AndroidAppBundle(aab)来优化应用程序的大小和资源,而非APK。
在GooglePlay发布应用程序后,要不断查看用户的反馈和所有的分析数据。这对程序的改进有非常大的帮助。
这是安卓开发员提供的检查清单,不容错过。
7.要用Git
Git是版本控制系统(VCS),它最基本的两大作用:一是追踪文件的变动,二是简化由多个开发员参与的大型项目中的工作。
我也不知道自己为何会用Git,其实直接给项目进行备份也可以。——来自三年前的我
现在笔者知道了。
并且告诉大家:程序员们需要Git,它对工作流的帮助简直妙极了。(这句话要是三年前有人跟我说就好了)。
Git妙在何处?理由如下:
l资源代码安全地储存在云端,随用随取。
l所有以往的代码版本都可使用,可以检测旧版本,而且出现错误时可以回到以前的版本。
l团队工作得到了简化。每个开发员都可以在并行分支上进行工作,有需要时合并更改。
l能开发数以千计的开源项目。
l有GitHub和BitBucket这样的平台,创建并展示自己项目的介绍也可以实现。
理由千万条,而笔者希望这些足以传递一条信息:认为自己不需要Git,是错的。