Android架构师素养

2008年9月23日,第一款 Android 手机 HTC Dream(也称 T-Mobile G1)面世,到现在十年时间过去了,如今的 Android 已成为当前最流行的移动操作系统,但Google 仍然在积极地优化、更新Android,那么Android架构师需要具备什么样的素养才能跟得上步伐?

一、专业的设计能力

1.1 基础

Android系统是基于Java系统、基于Linux而设计的开发语言,那么这些基础系统的专业性,对Android本身的素养是必须的,Java程序不是每一个程序人员都使用的,而Android也是基于嵌入式系统而设计的,早期的嵌入式系统都是基于C语言而开发,在很多C/C++程序员眼里,Java是低效的,现在的Android程序员,以Java开发转过来的为主,他们在系统的性能,系统的开销代价上概念较弱,而传统的C开发程序员难有面向对象的思维方式。程序设计的思想决定程序设计的效果,长期的专业素养,养成了思维习惯和设计习惯。

1.2 Android自身的特性

Android本身有其自身的设计,比如四大组件,还有View技术,比如AIDL、JNI等等,这些自身特性的掌握,是非常艰难的,例如Andoid提供的Content Provider技术,其中系统会将系统中所有的音频资源,图像资源等文件路径等信息存储在数据库中,当用户拷贝一个jpg文件进入Android的文件系统的时候,就会在数据库文件中自动更新,这样,我们程序设计的时候,就可以不必要去浏览所有的文件路径,去寻找系统所有的音乐或者图片,如果不熟悉这些,就不能进行程序设计,更谈不上好的架构。在这里也有很多程序员有一个误区,那就是认为数据库的功能太弱或者太简单,很容易掌握,其实在程序设计中,特别是Android的程序设计中,充分利用数据库的功能,程序性能更加高效,如LoadManger的自动加载功能,就可能降低XMPP和IM的聚合性,让接口更加独立。

又如Android提供的View技术,为什么很多人强调要阅读Android内核代码,就是让您了解Android的内部实现,如View功能,在Android系统中,基于View的源代码几乎占了系统接口部分的大部分,要了解这么多代码及内部原理,那是艰难的事情。Android因为开源,因为灵活,这样他们在接口上就不会很傻瓜,Android思想,就是让你干你随心所欲的事情。比如设计的界面框架,当我们需要统一风格,那么底部和头部就应该一样,甚至界面的很多部分都一样,Android是让你设计一个基类,将头部和底部包含在基础类中,然后在子类中填写中间部分的界面,同时具体化头部和底部的显示和操作信息,当然,这种使用,是基于View的布局思想,View本身是一张大图,这些大图能够接受所有的事件驱动,Viewgroup也是一种View,所有的布局都是都是基于Viewgroup,而布局的嵌套,xml的嵌套,都是基于View的机制,所以设计界面,只要是高质量的界面,都需要了解和深入理解Android的Framework源代码。好在,很多先行者在阅读后给我们提供了很多高质量的书籍或者博客,让我们在探索过程中少了一分艰难!

Andoird的系统层面的技术,这些包括AndroidManfest配置的四大组件,Application属性配置,系统权限,初始化操作(如处理系统崩溃的CrashHandler的配置和操作),另外,比如推送消息的处理,系统常驻服务的书写,系统窗口之间的互相调用等。

AIDL技术,为减少系统的耦合度,系统架构基于AIDL的设计让系统调用更加合理,将很多import系统进行封装,仅仅提供数据方面的接口。异步通信处理,Android的业务表现是UI方式,而与后台的通信或者大型数据处理(如图片压缩)等需要在后台处理,这样,异步 Handler机制或者 AsnyTask类就产生了。

1.3 服务器外部的接口

我们知道,Android是一个终端,那么这个终端是需要服务器进行支持的,我们可能需要自己进行部分服务器的部署,如何评估和设计服务器,可不仅仅是后台服务器开发人员的责任,让一个做终端的人去评估和了解后台系统,确实很难!举例说明:不需要后台服务器开发人员的参与:比如我们书写的图片资源下载系统,可能就不要服务器端的应用程序,当我们需要将缩略图通过本地工具进行处理,上传到缩略图的文件夹下,将真实的大图放在另外的文件夹下,同时将目录文件存放在xml中,但是,这些图片资源如果我们需要保护,比如,不允许,未经登录或者授权的人员进行下载,那么,就需要进行登录管理,了解登录的后台操作,如何评估这些更改给后台造成的工作量,那就要懂一些后台知识。

  • 简易的后台开发操作:比如以交易码识别的后台服务响应程序,包括登录,程序更新,简易业务处理,系统日志崩溃记录等
  • 中型的服务器系统:比如xmpp的部署,xmpp的服务程序书写
  • 大型的服务器系统:超过百万级的用户信息,或者业务操作比较复杂的系统,如大型集团系统的业务管理系统,需要后台复杂的业务操作,前台的业务请求也较为频繁或者比较复杂

1.4 外部的咨询信息

目前的开发人员有两种情况:一种是不依赖于外部咨询,很少使用外部咨询信息的,另外一种认为外部咨询是万能的,所有程序都架设在外部来源的代码。其实后一种更加容易成功,但是,也要小心的使用外部程序。

Android是一个开源代码,这样的结果是,几乎您可以找到各式各样的程序,在Github上,在CSDN上,甚至在apkbus上,这么庞大的咨询系统,如果我们不使用这些系统,我们式丧失了多么好的资源,但是,如何界定和判定这些资源的可用性,还有更关键的,这些东西从其他地方来的东西,很多是研发性质,没有进入到生产系统中的代码,其Bug的总量,很可能超过自己书写的程序,另外,因为专业性的问题,很可能他们在那个领域的专业程度很深,我们无法更改和调试他们书写的程序,这样造成的后果是系统没法维护(另外,更可能的情况是,由于咨询本身的局限性,可能获得的A的东西是半成本,而实际上B的东西已经可以量产)。这些都是困难的因素,这些甚至超过系统本身的工作能力。

评估是否使用外部组件,如通信系统,是自己架设或者使用外部的,比如IM系统,一般就会使用XMPP协议,那么网络上的ACK因为大家评价比较高,就选择这种呼声较高的,这里引用山寨手机公司老板的决策来形容我们的选择:一般的老板,不会使用那些没有量产的方案设计整机,否则基本上全亏,包括芯片一样,贸然的当人家的小白鼠,那可不是明智的选择,所以评估使用外部组件的时候,要了解到这个是在什么项目上来的,大家的使用程度。在咨询选择上面,除了征询上面的原则外,还要有验证和Demo评估。小型咨询组件,尽量获得源代码,没有源代码的程序不要使用,源代码尽量读懂它们,并加上自己的注释,按照自己的编程风格进行改编。

1.5 设计思想

我们在讨论后台的时候,经常看见它们使用MVC的设计思想,使用JSP作为页面设计View部分,使用Java selvert作为control部分,而使用m作为model部分,后面还发展了ssh等更优化的设计思想。Android的前端设计,也可以考虑使用MVC的方式,m是model部分,可以是表示角色和操作的业务类,可以与数据库打交道,被View 的Adapter作为cursor使用或者以表单的方式展示,而View则是Activity 组成的包括 View、xml、fragement、widget等综合信息, Android是一个前端程序,与用户打交道为主要功能之一,所以 View 是重点,而control之重点就是view与model打交道,比如Handler机制,通信处理等,那么我们划分系统目录(设计不同的系统包)的时候,也可以更具mvc的操作不一样, 划分为activity, fragemnt,adapter,model,widget等具体业务部分,平台部分另外存放。

Android 划分了包之后,后续的类的划分也期望在程序开发之前先行定义(当然,这个工作不能一个架构师做完,要让程序员参与),一旦类定义完毕,则后续的程序开发就相对比较简单。

二、业务处理能力

2.1 业务的展示与技术的接口

我们熟悉了面向对象的设计方法,很多时候使用UML工具来设计需求,将角色和角色的行为,用需求的方式展示出来,这样,架构设计的时候就将这些需求转化为不同的Model,并根据业务流程而实现相关的调用机制,然而,业务的展示并不直观,所以业务人员还需要UI或者产品人员将流程或者UI展示出来,供架构人员参考进行设计。这些都没有错,都是正常的,但是,业务设计的时候,会使用很多高仿真原始的操作模式,而计算机表现的是逻辑或者顺序的东西,所以复杂的系统,如何转化为计算机系统,举例来说:聊天处理界面,需要通过不同的气泡表示是谁说的话,中间可能用图形表示,可能用语音表示,可能调用照相,自拍传输照片,我们看到的越简单的东西,在计算机中实现就更加困难,让用户使用方便,就是对程序员的更大挑战,业务人员,UI和产品设计人员,架构师如何沟通设计出更符合用户需求的产品,是系统的终极目标!

2.2 业务的分工和技术的架构

业务是有分工的,而计算机的程序可能根据业务进行分工,也可能按照程序本身的架构进行分工,举例来说,人事管理系统和财务管理系统,业务运行系统之间从业务逻辑上来说,主要是内部数据的交流,而从技术架构层次上来说,也可能会设计成不同的业务处理,然而,更复杂的是,技术架构可能决定其更基础的公共部分(或者平台部分,Android本身也是一个平台),如何让业务处理的APK 开发人员不会过多的设计到平台关注上,或者说,如何让平台的操作更加简单,可以让架构师更加关注平台,让程序员在平台上投入更少的精力。更具体的说,平台可能包括如下内容:系统日志与运行日志,通信平台,系统的公共库(如文件操作,图像缓存,编码系统,加密解密),第三方平台或者组件(widget),甚至系统书写的自身公共组件。

系统并不是简单的按照业务分工进行搭建,而是需要按照积木方式进行开发,系统的基础部件越完善,接口越简单,系统的业务处理能力就越强,业务操作能力仅仅是架构的一部分。

2.3 业务的初建和后续可维护性

一般情况下,业务的初建是比较麻烦的,原始数据的模拟或者导入都需要架构师考虑,初始化的性能处理很关键,第一次初始化可以耗时1分钟以下,而以后每次进入系统原则上不超过5秒钟,系统可能为保障这样的性能,会将部分子系统的初始化放在子系统内部进行,另外,系统在运行过程中,可能会产生很多临时的缓存文件日志文件,系统可能在小量或者中量数据的时候运行可靠,而一旦系统超过业务的临界值,就会出现崩溃的情况,所以在设计系统的时候,需要考虑业务系统的数据量,并将这些业务数据量反馈在通信系统,界面系统中,不能让系统崩溃。

三、项目能力

3.1 项目的周期和平台

要建设平台供应用业务处理,而一般搭建系统架构的时候,可能一行代码都没有,要平台很多库都来源于系统的精简与优化,而项目周期很紧,所以系统第一次搭建的时候,都可能先考虑业务实现而未过多的考虑平台方面,毕竟老板或投资人特别是不懂技术的资方,期望一个新人给他展示的是业务处理的进度,而不是告诉他这样做更合理,而一旦您按照这样的方式操作,会发现系统的后续维护性太差,以至于后续接手的架构师或者开发经理会将你的“成果”评价未负。

所以遭遇系统初始化控制的时候,将部分程序员放在可以分配具体开发工作或者研发工作的平台上,让部分程序员先进行业务开发,也许是不错的选择,业务与平台共同进行的好处是,平台的测试需要业务来操作,业务需要平台来简化其操作。

3.2 项目的人力资源协调

Android除了架构师具备上面说的专业技能之外,而其程序设计人员所配备的能力,其实也不会比架构师懂得少多少,目前的Android高级人员还是比较紧缺的,Android程序员的执行能力,是架构师所迫切希望的,很多公司的现实情况是,不能或者不愿意在这方面进入这样的投入。还有就是后台的沟通,后台要了解前台的设计的合理性,前台要理解后台的工作量或者工作计划,需要后台提供相关的测试数据。

3.3 项目的决策

Android架构师很多时候面临的决策问题是平台的决策问题,A公司搭建的平台不一定适合B公司,C业务系统并不需要复杂的平台,可以直接使用系统提供的功能,杀鸡不用牛刀,杀牛不能用水果刀,从复杂到简单的系统,评估出合适的系统或者依赖或者设计合适的平台,是简化开发,适应业务发展的决策之重。

四、番外篇

说说关于学习的番外篇:

4.1 好奇心比雄心走得更远

很多人对未来空有满腔的雄心壮志,往往不如对技术要有一份好奇心,一份探索欲,再加上一份执着的人。

4.2 要有OPEN的心态

曾经的我也只是把自己的所思所得都放入自己的有道云笔记,很少整理,这其实不利于个人的技术发展,好在这个事情正在改变,经常觉得不错的点就拿出来写成博客,我认为这是对能力的又一层提升。另外,在低头做技术的同时,还应该有空抬头看世界,不能闭门造车。

4.3 天道酬勤

学历只能代表过去,能力代表现在,潜力代表未来! 不把自己逼一把,压根不知道自己有多优秀,只要努力去学习,去挖掘潜力,进而提升自我技术修为,未来不再是梦!共勉之!

4.4 解决问题的方式

遇到问题,一定要先尝试自己解决,解决不了再请教他人。这是对自己的一个锻炼,也是对他人的一个尊重,可以有多种途径自行搜索:

  • 百度一下,很多时候还是能有所帮助的,不要过分强调Google,完全抛弃百度,毕竟中文看起来比较快
  • 先中文关键词Google一下,再英文关键词google一下
  • stackoverflow.com、知乎等技术问答网站内直接搜索
  • 查看官方文档
  • 如果有源码,尝试直接看源码,看能否解决
  • 有空可以多逛逛Github,多关注社区,定会收获不少

当然,最最重要的是能静得下心,持之以恒地专研技术。