Android团队的组建和管理

【

1、从面试谈起(看人的性格，内向还是外向。)

2、如今是卖方市场(要降低要求，一个强力的Team Leader，外加一些能干活的人就行了。在工作中培养人才，提升从业人员水平。)

3、名校论不适用无线开发（类似于搜索之类涉及复杂算法的软件行业，固然需要较高学历良好背景的人去研究。但对于App应用类软件而言，每天的开发工作大都是重复性画UI和调用MobileAPI获取数据，并无需名校出身。）

4、如何搞到更多的简历(和HR搞好关系，加入招聘组。)

5、面试时需要考察的几个点

{

主要考察3个方面：

(1)、技术水平，主要是候选人的编程技术水平。

(2)、领域知识，主要是候选人对业务的了解程度。

(3)、软件技能，包括沟通能力、抗压能力、性格。

     一般而言，有两轮最重要。第一轮是Team Leader面试，考察技术水平。第二轮是用人部门的负责人面试，考察领域知识和软件技能。

--->如何考察面试者的技术水平？对于App而言，分为3个方向：

(1)、应用类：共同特点是页面特别多，都需要频繁地调用MobileAPI获取数据，都涉及到支付流程，所以这类App的开发人员需要对UI、网络、登录、支付流程都非常熟悉。

(2)、手机管家类：这类App虽然也算是应用类，但是很少调用MobileAPI,它更多关注的是手机系统内部数据的读写，所以这类App的开发人员需要对ActivityManager、Service、BroadcastReceiver之类的知识很熟悉。

(3)、游戏类：必须对动画引擎很熟悉，比如说Cocos2d和Lua。

     此外，还有一类Android从业人员，是在华为、三星这样的硬件厂商做手机系统的二次开发，包括手机系统上自带的一些软件，严格地说，不属于App开发。

--->面试时经常考察的几个方面：

(1)、Activity的生命周期。

(2)、Activity的4的4种启动方式及使用场合。

(3)、做过的项目中，Activity是否有基类，如果有，封装了哪些共用的逻辑？

(4)、事件的各种使用方法及优缺点。

(5)、与HTML5页面的相互调用。

(6)、UI线程的阻塞与解决方案(Runnable 与 Handler)。

(7)、采用什么姿势调用MobileAPI并解析返回的数据？

(8)、怎样做列表的分页和刷新。

(9)、登录的实现，包括从哪里来，到哪里去的页面跳转机制，记住密码的逻辑设计。

(10)、性能调优，包括Layout调优、Activity中如何使用CONST常量、时间换空间策略、ViewHolder、图集的优化策略、数据缓存和图片缓存，等等。

(11)、全局变量过多怎么办？

(12)、写过UT没？

(13)、是否做过自动打包？Ant、Maven或gradle任意一种都可以。

     对于TeamLeader的要求会更高一些，包括如何检查内存泄漏，如何优化内存、多线程、自动打包、框架设计、版本管理等诸多方面。

}

6、无线团队必备的10份文档

{

     一个团队成熟与否的标志是文档。文档太多，就违反了敏捷的原则，但有几个文档是必须提供的：

(1)、新员工入职文档（这份文档包括：部门组织结构，新员工所在的团队和将要担当的角色；个人简介，用于群发给部门其他成员；要加入的公司邮件组，部门内部用于沟通的QQ群或微信群；Android项目的地址，权限申请；Bug管理工具及权限申请；测试环境和仿真环境的地址；产品需求的地址；WIFI设置、VPN申请、手机邮箱配置、打印机安装，等等。）

(2)、加强版新员工入职文档：(这是一份更适合Android团队的新员工入职文档：SVN或GIT的权限申请；Android开发常用软件下载；迭代的节奏；业务名词解释；Android App的项目结构；Android自动打包地址；模板<模范标准>页面。)；代码规范。

(3)、测试机清单（测试机型号、操作系统、使用人。采购测试机可以看友盟统计）

(4)、模块分工表：（把开发人员按照业务线<模块>进行划分）

(5)、页面逻辑流程文档

(6)、MobileAPI接口分布图：(一般用XMind思维导图来描述一款App所用到的MobileAPI接口。好处：定期检查IOS和Android在做同一功能时所使用的MobileAPI是否一致；每次MobileAPI发版上线，相关的测试人员，就可以根据这张图，找到这些MobileAPI接口改动影响了哪些页面和功能，需要进行相应的回归测试。)

(7)、版本管理策略文档：(无论是使用SVN还是GIT，都要制定一套发版流程。Android团队中要有专门的开发人员熟悉并遵守这套流程，包括:

     正常迭代的流程；开新分支做技术调研的流程；紧急上线流程。

流程一般有两种，要么是主干开发主干上线，要么是主干开发分支上线，无论是哪一种，都要落实文档，切记口口相传。)

(8)、框架设计文档：（当我们把AndroidLib这个业务无关的类库从App中抽象出来的时候，就该有一份框架设计文档了。）

(9)、发布流程文档：(Android要发布到各大市场，为此，需要修改清单配置文件中的友盟渠道号，才能统计各大市场的下载量。此外发布的apk包要混淆：渠道号是否正确？     代码是否混淆？   版本号是否正确？    是否release包(而不是debug包)？    临时决定关闭的功能是否露出来了？   是否可以支付、分享、扫描二维码？   升级安装是否会引起崩溃？

     鉴于以上各点，需要制定发布流程并形成文档，包括：

<1>、产品经理准备发版所需要的描叙文字、图片等材料。   

<2>、开发人员进行批量打包工作。   

<3>、测试人员要随机抽取一个apk包进行测试，包括功能点测试。

<4>、推广人员发布到各大市场，要有邮件持续跟踪各个渠道的版本更新进度。

<5>、在版本仓库上打Tag,合并分支上的代码到主干。  )

(10)、App启动流程图

     （如果要做App性能优化，最好的着手点是App从启动到进入首页的流程。大多数Android App的启动Activity并不是首页HomeActivity,而是一个叫做LaunchActivity的页面，它的UI就是简单的Splash动画，同时它肩负着更多的职责，如：

<1>、注册友盟、推送等等第三方组件。

<2>、加载Splash图，同时下载新的Splash图以便下次开启时使用。

<3>、如果是首次打开，则进入引导页。

<4>、友盟打点，统计激活数。

<5>、如果有消息推送到达，点击消息后想不经过首页而直接进入某个二级页面，其实在代码层面还是要经过LaunchActivity的，由它对推送消息进行分发，以决定该跳转到哪个二级页面。

     以上这些逻辑交织在一起，非常复杂，尤其是要区分升级版和全新安装版的时候，为此我们需要用Visio之类的软件绘制一个App启动流程图。在业界，我们将LuanchActivity称为Bootstrapper。LuachActivity把上述这些事情都做完，才会进去到首页HomeActivity。）

}

7、一对一沟通

{

     走简便流程，要求：

<1>、最近一个月做了哪些事情，有什么提高？

<2>、自身想要有什么提高？需要我帮助做些什么？

     经常反馈的有:

<1>、强烈要求团建。

<2>、有的程序员想转行做产品经理，想得到一些锻炼的机会。

<3>、初级程序员希望分配到一些更高级的Task。他们渴望新知识，而不是天天画UI。

<4>、有些程序员比较好学，希望团队有大牛，能学到东西。

<5>、渴望被表扬。

}

8、每周技术分享

{

     技术分享是提高团队技术水平的3个方法之一，另外两个是Code-Review和修复线上Crash。

技术分享关键在于坚持。技术分享并不是天马行空，不为所云的技术畅谈，要根据团队整体技术水平和实际项目需要，弥补团队短板。建议可以罗列Android或IOS必须掌握的若干技术点，然后发给大家给自己打分，每个技术点都是5分制。<完全不知道：0分      听说过：1分   看过介绍的文章：2分   亲手做过demo：3分  项目中使用过：4分    非常熟悉：5分>，把大家的自我打分收集上来进行汇总，对团队的整体技术水平就一步了然了。对于团队的技术短板，在每周的技术分享上，会安排团队成员进行讲解。

}

9、代码评审

{

     常规代码审核会出现一些情况，首先在我们是个互联网公司，App迭代的周期只有两周，所有的开发人员都疲于奔命做需求，哪有时间去审核别人的代码，会出现一些情况：

     <1>、能力强且责任心强的开发人员，一天大部分时间在审核别人的代码。

     <2>、能力强且责任心差的开发人员，看都不看直接审核通过了。

     <3>、技术能力弱的开发人员，要审核别人的代码也是心有余而力不足。

     另一个副作用是：因为每次请别人Code-Review都要等，所以开发人员倾向于每天下班前一次性提交所有改动，并没有遵守持续开发、持续提交、持续测试的持续集成思想。

===应变解决方案为:

     <1>、对老员工不再进行Code-Review。

     <2>、对新员工和实习生、应届生，要为他们每人指定一个Code-Review的老员工，至少3个月之内，对他们的Code-Review还是要严格执行的。

大致的标准为：看编码规范或看编码逻辑。

---->互联公司没有时间去搞太繁琐的流程，可以把Code-Review的策略改为，每周一下午，技术经理从上周提交的代码中找出10处写的有问题的代码片段，然后给大家进行讲解和讨论。在达成共识后，今后就再也不能写类似的代码了。

     那么对于有问题的代码，处理方式建议，对于首页、会员中心这种一级页面，不能改要保证稳定性。对于二级或三级页面，局部某个功能可以安排人员去修改。

     在进行Code-Review的同时，有一个东西可以顺便搞出来，那就是模板页面，即符合编码规范要求、可以作为编写其他页面的模板页面。对于Android应用类App而言，一个模板页是不够的，至少要提供Activity、Adapter、Entity、Fragment这4个模板页，其中Acitivity要包括对MobileAPI的调用。

     有了模板页，所有开发人员的编码就有章可循，单纯搞Code-Review和编码规范都太抽象，一定要有能落地的东西，那就是模板页。

}

10、对Android团队Leader的定位

{

     Android团队Leader要负责的工作罗列入小：

<1>、每次迭代把Tesk分配到具体的开发人员。

<2>、组织线上Crash的修复。

<3>、处理线上突发bug。

<4>、排查每日客人投诉的问题。

<5>、解决团队遇到的技术难题。

<6>、组织每周Code-Review。

<7>、组织每周例会。

     团队Leader一定要明确自己的职责，，注意以下两点：

<1>、不要给自己分配具体的需求开发，管理工作会消耗掉你大量的时间。

<2>、努力不要使自己成为瓶颈。很消耗时间的事情，及时分配到具体的开发人员。

     哪些工作是要尽早分配给具体的开发人员呢？

<1>、Android项目的打包。

<2>、代码混淆。

<3>、设计Android的Lib框架，交给框架组去做。

<4>、技术调研。

<5>、Monkey日志分析。

}

11、Android 应用开发所需技能自我评测

{

     从事Android应用的开发人员所需要精通的20个技能点，如下：

<1>、Activity相关。App应用开发，以Activity使用最多，涉及LaunchMode、onSaveInsatanceState、生命周期等技术。

<2>、Fragment相关技术。用的人不少，想明白是咋回事的人不多。

<3>、序列化技术。有Parcelable和Serializable两种。前者是基于Service的，后者是基于Bundle的，二者实现原理不同，但是达到的效果差不多。

<4>、ImageLoader的原理和使用。类似的还可以学习Fracebook新开源的Fresco,它对图片的处理会更好一些。

<5>、fastJSON或GSON的使用。做App不会用实体自动匹配JSON数据，相当于白做。

<6>、多线程相关。包括Handler、Looper、ExecutorService等。

<7>、Adapetr和ListView。这两个技术捆在一起，经常容易崩溃，尤其是分页的时候，要仔细研究深刻领会。

<8>、用户Cookie设计。需要把登录机制彻底搞清楚，包括在HttpRequest头中夹带Cookie来进行用户身份验证的技术。

<9>、网络请求封装。使用AsyncTask的网络底层封装，使用Handler+Runnable的网络底层封装。

<10>、Android与HTML5的 交互。包括Android调用HTML5的方法，以及HTML5调用Android的方法。

<11>、代码混淆。没用过ProGuard,不知道keep相关语法的，有待研究。

<12>、Android 打包机制。涉及Android SDK中的若干命令。对Android打包过程做的每一件事都很清楚。进一步是Android多项目依赖的打包技术。Ant、Gradle或者Maven,掌握其中任何一种打包机制即可。

<13>、线上Crash分析并修复。要具备通过分析Crash信息修复线上Crash的能力。

<14>、内存泄漏。包括内存优化、内存泄漏的场景、MAT工具的使用。

<15>、调试工具。包括DDMS、Eclipse或者Android Studio的调制功能。

<16>、Monkey机制。Android开发人员如何对一款App进行Monkey测试。

<17>、单元测试。这里指的是JUnit。对复杂的算法写过单元测试以保证其没有问题。

<18>、GIT的高级功能。如果项目使用的是SVN,那么要掌握SVN的版本管理策略。

<19>、插件化编程。哪怕知道一点DexClassLoader的概念也好。

<20>、设计模式。对常见的设计模式如工厂、生成器、适配器、代理、策略模式耳熟能详。

}

】