Android 架构师成长之路

前言

众所周知，当下流行的编程语言有Java、PHP、C、C++、Python、Go等。其中，稳坐榜首的仍然是Java编程语言，且在以面向对象思想占主导的应用开发中，Java往往成为其代名词。Java语言的背景强大，开发者众多，一直发展都不错。从普遍的企业的角度来看，存在的问题是：后台被认为是技术核心，客户端却被认为技术含量不高，甚至小企业会让后台人员顺便开发简单的客户端，或者让后台的架构师管理客户端几个人。事实上，客户端技术和后台技术的侧重点完全不同，连编程语言都不同（Android使用Kotlin编程语言的逐渐普及）。另外，后台的人跟用户相对离得太远，而客户端是直接面向用户的，与产品人员沟通更直接。所以，我认为企业产品真的是为了给用户用，那么选客户端背景的人员去做架构更好一点。

 

一、移动架构师职位介绍

（1）移动架构师公认的职位描述是什么?

事实上并没有非常准确的职位描述。不过我可以尝试给出了一个:

1. 设计当前架构。包括新技术方案的制定或评审。
2. 改进过去架构。根据业务的发展或者技术债务的原因,重构当前技术方案并且推进实施。
3. 前瞻未来架构。技术方案调研和分析,随时准备好对新技术的使用。
4. 推进技术方案实施。解决实施过程中具体的技术问题。
5. 技术分享和培训。推进技术交流和新技术的使用。
6. 人员的招聘。技术面试。

（2）移动架构师是否还要日常编码，如果需要，比例是多少?

虽然带有管理色彩，但仍然以技术为主。所以代码是必须要写的，架构师不写代码，就成管理了。写代码的比例应该至少是 40% 的工作时间以上。

（3）移动架构师的成长路线是什么样的?

可以先试着解决当前业务中的技术问题，然后再培养自己的技术前瞻性，为业务的未来储备技术。架构师立命的根本还是技术，所以在移动开发技术上研究的事情都要尝试去做。另外，技术人员通常不善于表达，而架构师的很多工作(例如技术分享,培训,面试,推进技术方案实施)都是需要沟通工作的。另外优秀的移动架构师能够对业界都有所影响。所以，作为一个移动架构师，锻炼自己的表达能力也是必要的一条成长路线。

（5）移动架构师是否需要学习前端、后端开发技术?

这等于问要不要扩展技术“广”度，而架构师标签之一就是“广”。不过是看个人的精力能够达到多大的广度和深度了。

（6）移动架构师是否需要设计整个 C/S 架构?

这点倒是夸张了，配合后台人员设计应该是可以的，总负责的话，挑战略大了一些。

（7）移动架构师如何进行团队沟通工作？

1、与CTO总监的合作。首先从思想上要认识到两者是利益完全一致的。总监为架构师拓展上升空间，而架构师将总监的规划切实落地。保证足够的沟通，可以约定一个固定沟通机制，比如每2周一次，让双方在思想上保持同步和一致。架构师应该带着方案和CTO沟通，讲清楚A、B方案的优缺点。可以让CTO根据从上层去考虑做决定，就算架构师本职的决策，也最好先取得CTO的认可。如果出现意见分歧，最好的方式是先搁置，等条件成熟了，很可能意见会趋于一致。如果不能等，只要CTO的意见不是太离谱，还是按照CTO的意见执行比较好。如果有十足把握，认为自己的方案很好，那么也要得到CTO的许可和谅解，否则千万不要擅自去做，因为最后的锅不是你一个人能背的。

2、与其他部门的合作。产品部门一般不懂技术，架构师的作用就是帮他解决这个问题，这个很好理解。在理解了产品需求后，进行技术可行性分析。在不改变整体方案目标的前提下，从技术的角度，提出改善意见，修改设计，目的是方便实现。与后台架构师搞好合作，从后台到前台，整条链路太长，一个人管不过来，需要两人好好合作，共同把好技术关。拉拢好测试部门，要当作开发的朋友看待，是自己人。如果关系够好，考虑让测试人员在“自测”阶段提前介入，帮助开发人员提供测试案例。运营部门的关系稍微远了一点，关键点是及早介入。防止临上线了，加入一堆的运营需求，就可能影响产品投放时间了。总之与其他部门以合作为主，挣取及早沟通，将风险消灭在反生之前。

3、与团队成员的合作。移动开发团队人数不多，但是部门和开发语言多。有IOS，android，还有JS和Java网关。如果一个部门超过3个人，应该设置一个Team-Leader，进行授权实现间接管理。对于自己擅长的技术亲自去实现，和兄弟们一起战斗，深入到团队中。思考团队提升和储备，应让中层人员在一线作战，高层人员作指导，初层人员打酱油学习。对于自己不擅长的技术，可以采用“结对编程”的方法，让两个开发者在一台电脑上开发，一个编写另一个观察，程序基本是相同的，还是能够理解和参与讨论的。与几个Leader，要重点在于沟通，在大方向上保证思想一致，给他们空间适量授权，并协助他们做出成绩。重点注意团队的正能量以及活跃的气氛，人不是机器，和谐的氛围比冰冷的制度和惩罚要好得多。记录团队的功绩和成果，提高团队成员集体荣誉感，将奋斗目标引导到“自我价值”上来。

（8）移动架构师项目新需求处理的注意事项

1、开发流程。新的产品方案从市场运营提出需求开始，再到产品经理制定新的功能需求，最后开发手里进行研发。

2、全局视野。在产品与开发首次会议时，首先从整个项目的全局出发，掌握需求的目的和意义和其他需求之间的关系。

3、完善补漏。向产品提出的需求的不足之处，从用户和开发的角度进行补漏完善，从而保证项目正常的运行。

4、接口数据。与后台数据接口开发人员定制数据在那个接口里给比较合理。

 

二、Android架构师技术介绍

架构与设计

• 设计模式
• 重构
• 网络编程框架
  • TCP格式三次握手与四次挥手
  • HttpClient
  • HttpURLConnection
  • Volley
  • OkHttp
  • Retrofit
• UI架构模式
  • MVC
  • MVP
  • MVVM

研发工具

• 集成开发环境
  • Android Studio
  • Sublime Text
• 版本控制系统
  • svn
  • git
    • gitlab
    • github
  • mercurial
• 调试工具
  • ADB
  • DDMS
  • Stetho
  • LeakCanary
  • ClassyShark
  • Postman
  • markman
• CodeReview工具
  • Gerrit
  • Phabricator
• 构建工具
  • Gradle
  • Buck
• 效率工具
  • 番茄钟
  • Markdown
  • WakaTime
  • Focus Matrix
  • evernote
  • Pocket

移动安全

• 代码和资源混淆
• 反编译
• 密钥管理
• 安全编码
• 应用加固

专项技术

• App 瘦身
• MultiDex
• 插件化
• 推送技术
• Crash 统计
• 函数式编程
• 启动保护
• 在线热修复
• AOP
• React Native
• Hybrid
• SDK化
• 依赖注入

软技能

• 知识管理
  • 团队Wiki
  • 团队论坛
• 时间管理
  • 四象限法则
  • 帕累托法则
  • 番茄工作法
• 目标管理
  • Smart 法则
  • 思维导图
  • 甘特图
• 项目管理
  • 边界思维
  • 过程思维（WBS）
  • 风险思维
  • 干系人思维
  • 整合沟通
• 团队管理
  • 招聘面试
  • 梯队培养
  • 技术规划
  • 团队规范
• 个人管理
  • 技术博客
  • 技术分享
  • 会议演讲
  • 领导力
  • 持续学习

周边技术

• 产品交互设计
• 后端技术
• HTML5
• iOS

移动测试

• 单元测试
  • JUnit
  • Robolectric
  • Mockito
• UI自动化测试
  • Monkey
  • MonkeyRunner
  • UIAutomator
  • Robotium
  • Espresso
  • Appium
• 持续集成
  • Jenkins
  • Travis CI
  • fastlane
• 静态代码扫描
  • CheckStyle
  • FindBugs
  • PMD
  • Android Lint
  • Infer

性能优化

• 启动优化
• 代码优化
• 内存优化
• 电量优化
• 布局优化
• 网络优化

编程语言

• Java
• C
• C++
• Javascript
• Groovy
• Kotlin

 

（本次更新时间：2019年02月21日19:05:16，未完待续，不定期补充内容）