Android架构师素养

为了系统能以小的代价开发，以高效的方式运行，以较低的成本运营和维护，Android架构师需要具备什么样的素养呢？为什么说Android架构师那么艰难呢？
1、专业的设计能力

1、 基础
      
      Android系统是基于java系统，基于linux而设计的开发语言，那么这些基础系统的专业性，对android本身的素养是必须的，我们知道java程序不是每一个程序人员都使用的，而android也是基于嵌入式系统而设计的，早期的嵌入式系统都是基于c语言而开发，在很多c程序员眼里，java是低效的（我不赞成，他们在iphone系统低硬件，高效率而更加认为此观点），现在的android程序员，以java开发转过来的为主，而基于linux而进行c语言开发的程序员以设备维护开发为主（驱动或者系统维护），这样跨领域的后果是，java开发是pc上或者服务器上的开发人员，他们在系统的性能，系统的开销代价上概念较弱，而传统的c开发程序员难有面向对象的思维方式。很多同行人士在这方面的认识还是不足，特别是转行业，跨专业的设计上面，认为不外乎就是一门语言，其实不是这样，专业的长期使用，才能培养在某个专业某个领域内的优于其他同行的能力，这些能力，才能开发优秀的程序，很多同行在这方面吃亏不小，设计的程序都是按照原来自己使用的方式。     这方面我就见过他们犯下的错误，以linux和c出身写的程序，他们使用传统的socket方式，在服务器上使用传统的socket的方式对接，没有使用http协议，他们认为这样的效率更高，我看过他们程序的运行结果，界面比普通的android更慢，关键是项目周期之长。而另外我也见过java出身写的程序（某一大型集团），他们将所有的资源集成在一个apk中，同时系统开机进行了漫长的初始化，系统在内存使用上毫无节制，导致的结果是运行的系统性能很低。程序设计的思想决定程序设计的效果，长期的专业素养，养成了思维习惯和设计习惯。

2、Android自身的特性

  Android本身有其自身的设计，比如四大组件，还有view技术，比如aidl，比如jni等等，这些自身特性的掌握，是非常艰难的，下面简单举例：

• 如andoid提供的content provider技术，其中系统会将系统中所有的音频资源，图像资源等文件路径等信息存储在数据库中，当用户拷贝一个jpg文件进入android的文件系统的时候，就会在数据库文件中自动更新，这样，我们程序设计的时候，就可以不必要去浏览所有的文件路径，去寻找系统所有的音乐或者图片，如果我们不熟悉这些，就不能进行程序设计，更谈不上好的架构。在这里也有很多程序员有一个误区，那就是认为数据库的功能太弱或者太简单，很容易掌握，其实在程序设计中，特别是android的程序设计中，充分利用数据库的功能，程序性能更加高效，如LoadManger的自动加载功能，就可能降低xmpp和IM的聚合性，让接口更加独立。
• 又如android提供的view技术，为什么很多人强调要阅读android内核代码，就是让您了解android的内部实现，如view功能，在android系统中，基于view的源代码几乎占了系统接口部分的大部分，要了解这么多代码及内部原理，那是艰难的事情。android因为开源，因为灵活，这样他们在接口上就不会很傻瓜，我也在想一个问题，我在view上面花了接近1年的时间，去了解，去理解它，而当时学delphi，也就1个月的时间就用得滚瓜乱熟，后面在知道，原来的android思想，就是让你干你随心所欲的事情。稍稍举例说明，比如设计的界面框架，当我们需要统一风格，那么底部和头部就应该一样，甚至界面的很多部分都一样，那么传统的类似于delphi的就限定死了，提供了一个窗口供你使用，而android是让你设计一个基类，将头部和底部包含在基础类中，然后在子类中填写中间部分的界面，同时具体化头部和底部的显示和操作信息，当然，这种使用，是基于view的布局思想，view本身是一张大图，这些大图能够接受所有的事件驱动，viewgroup也是一种view，所有的布局都是都是基于viewgroup，而布局的嵌套，xml的嵌套，都是基于view的机制，所以设计界面，只要是高质量的界面，都需要了解和深入理解android的framework源代码。好在，很多同仁在阅读后给我们提供了很多高质量的书籍或者博客，让我们在探索过程中少了一分艰难！
• andoird的系统层面的技术，这些包括AndroidManfest配置的四大组件，application属性配置，系统权限，初始化操作（如处理系统崩溃的crashHandler的配置和操作），另外，比如推送消息的处理，系统常驻服务的书写，系统窗口之间的互相调用等。
• aidl技术，为减少系统的耦合度，系统架构基于aidl的设计让系统调用更加合理，在某大型集团，设计完之后，他们想让我将me电子市场这个系统快速独立出来，成为独立的apk或者jar包，结果这种独立根本无法进行，首先，其他系统需要调用其提供的app info model类，需要调用其提供的downloadmanager程序，而它调用外边的程序，也是需要import大量的类，系统之间的聚合度太紧密了，独立出来真不容易，最后，系统就按照原来的样子运行，这也是一个相对失败的架构，虽让整个系统能正常的运行和上线，但是，系统的可维护性太差了，如果当时使用AIDL的方式，将很多import系统进行封装，仅仅提供数据方面的接口。
• 异步通信处理，Android的业务表现是ui方式，而与后台的通信或者大型数据处理（如图片压缩）等需要在后台处理，这样，异步 Handler机制或者 AsnyTask类就产生了。
  

3、服务器外部的接口

     我们知道，android是一个终端，那么这个终端是需要服务器进行支持的，我们可能需要自己进行部分服务器的部署，如何评估和设计服务器，可不仅仅是后台服务器开发人员的责任，让一个做终端的人去评估和了解后台系统，确实很难！举例说明：

• 不需要后台服务器开发人员的参与：  比如我们书写的图片资源下载系统，可能就不要服务器端的应用程序，当我们需要将缩略图通过本地工具进行处理，上传到缩略图的文件夹下，将真实的大图放在另外的文件夹下，同时将目录文件存放在xml中，但是，这些图片资源如果我们需要保护，比如，不允许，未经登录或者授权的人员进行下载，那么，就需要进行登录管理，了解登录的后台操作，如何评估这些更改给后台造成的工作量，那就要懂一些后台知识。
• 简易的后台开发操作：比如以交易码识别的后台服务响应程序，包括登录，程序更新，简易业务处理，系统日志崩溃记录等。
• 中型的服务器系统：比如xmpp的部署，xmpp的服务程序书写。
• 大型的服务器系统：超过百万级的用户信息，或者业务操作比较复杂的系统，如大型集团系统的业务管理系统，需要后台复杂的业务操作，前台的业务请求也较为频繁或者比较复杂。
  

4、外部的咨询信息

    目前的开发人员，又两种情况，一种是不依赖于外部咨询，很少使用外部咨询信息的，另外一种认为外部咨询是万能的，所有程序都架设在外部来源的代码。其实后一种更加容易成功,但是，也要小心的使用外部程序。
    Android是一个开源代码，这样的结果是，几乎您可以找到各式各样的程序，在github上，在csdn上，甚至在apkbus上，这么庞大的咨询系统，如果我们不使用这些系统，我们式丧失了多么好的资源，但是，如何界定和判定这些资源的可用性，还有更关键的，这些东西从其他地方来的东西，很多是研发性质，没有进入到生产系统中的代码，其bug的总量，很可能超过自己书写的程序，另外，因为专业性的问题，很可能他们在那个领域的专业程度很深，我们无法更改和调试他们书写的程序，这样造成的后果是系统没法维护（另外，更可能的情况是，由于咨询本身的局限性，可能获得的a的东西是半成本，而实际上b的东西已经可以量产）。这些都是困难的因素，这些甚至超过系统本身的工作能力。
    我给出咨询信息使用的如下方式，这也是我的经验总结：

• 评估是否使用外部组件，如通信系统，是自己架设或者使用外部的，比如im系统，一般就会使用xmpp协议，那么网络上的ack因为大家评价比较高，就选择这种呼声较高的，这里引用山寨手机公司老板的决策来形容我们的选择：一般的老板，不会使用那些没有量产的方案设计整机，否则基本上全亏，包括芯片一样，贸然的当人家的小白鼠，那可不是明智的选择，所以评估使用外部组件的时候，要了解到这个是在什么项目上来的，大家的使用程度。
• 基于平台得思想去处理技术问题，平台是开发者的基础，那么，外部信息资源得平台咨询就非常重要，在处理平台得搭建过程种，评估平台很重要，如后台系统复杂业务使用spring，简单业务就直接使用servlet一样，前端的平台要仔细搭建，在咨询选择上面，除了征询上面的原则外，还要有验证和demo评估。
• 小型咨询组件，尽量获得源代码，没有源代码的程序不要使用，源代码尽量读懂它们，并加上自己的注释，按照自己的编程风格进行改编。
  

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、业务的分工和技术的架构

     业务是有分工的，而计算机的程序可能根据业务进行分工，也可能按照程序本身的架构进行分工，举例来说，人事管理系统和财务管理系统，业务运行系统之间从业务逻辑上来说，主要是内部数据的交流，而从技术架构层次上来说，也可能会设计成不同的业务处理，然而，更复杂的是，技术架构可能决定其更基础的公共部分（或者平台部分，android本身也是一个平台），如何让业务处理的apk 开发人员不会过多的设计到平台关注上，或者说，如何让平台的操作更加简单，某大型集团公司在产品设计之前，需要写测试用例，那么架构师在业务开始之前，是否需要写一个平台的操作手册，让平台本身能够被程序员使用，即便这个平台本身还没有被建立起来，这样，可以让架构师更加关注平台，让程序员在平台上投入更少的精力。
     更具体的说，平台可能包括如下内容：系统日志与运行日志，通信平台，系统的公共库（如文件操作，图像缓存，编码系统，加密解密），第三方平台或者组件（widget)，甚至系统书写的自身公共组件。
     系统并不是简单的按照业务分工进行搭建，而是需要按照积木方式进行开发，系统的基础部件越完善，接口越简单，系统的业务处理能力就越强，业务操作能力仅仅是架构的一部分。

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

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

3、其他

1、项目的周期和平台

     我们上面说了，要建设平台供应用业务处理，而一般搭建系统架构的时候，可能一行代码都没有，要平台很多库都来源于系统的精简与优化，而项目周期很紧，所以系统第一次搭建的时候，都可能先考虑业务实现而未过多的考虑平台方面，毕竟投资人特别是不懂技术的投资人，期望一个新人给他展示的是业务处理的进度，而不是你告诉他这样做更合理，而一旦您按照这样的方式操作，会发现系统的后续维护性太差，以至于后续接手的架构师或者开发经理会将你的“成果”评价未负。
     所以我们遭遇系统初始化控制的时候，将部分程序员放在可以分配具体开发工作或者研发工作的平台上，让部分程序员先进行业务开发，也许是不错的选择，业务与平台共同进行的好处是，平台的测试需要业务来操作，业务需要平台来简化其操作。

2、项目的人力资源协调

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



3、项目的决策

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