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，多关注社区，定会收获不少
当然，最最重要的是能静得下心，持之以恒地专研技术。