关于Android应用程序开发，新开的项目应该选择使用Java还是Kotlin作为其开发语言？关于新开的Android项目，我们到底应该如何去实施？
在今年7月份初我参与了一个新项目的研发工作，在研发过程中遇到了一些问题，我想从下面几个方面和大家分享下：
- 新开的项目应该选择使用Java还是Kotlin作为其开发语言？Google官方都已官宣Kotlin为Android应用第一开发语言了，我一定要使用Kotlin语言？
- 使用Kotlin作为开发语言 项目中用到的第三方开源库如何选择？
- 关于新开的Android项目，我们到底应该如何去实施？
- Android项目的整体架构如何选？
- 是否要实施组件化？
新开的项目应该选择使用Java还是Kotlin作为其开发语言？Google官方都已官宣Kotlin为Android应用第一开发语言了，我一定要使用Kotlin语言？
这个主要看参与项目开发的人员组成及主程（一般是Android团队的主管、小组长或能力突出者）的能力及其擅长的技能，我们分以下几种情况来看：
- Android团队主程技术能力好，有丰富的项目经验（从事Android应用开发工作5年以上） ，Kotlin语言基本掌握，建议使用Java语言或Java主导Kotlin选择性使用。
- Android团队主管（小组长）专业技能一般，擅长管理团队，非常认可组内主程的能力，主程技术能力好，从事Android应用开发工作5年以上，建议使用Java语言；
- Android团队主管（小组长）和主程是同一个人，使用Kotlin语言2年以上的，可以考虑使用Kotlin，否则使用Java语言。
- Android团队主管（小组长）和主程是两个人，在技术选型上若有分歧，建议听主程的。
综上所述，你可能也看出来了，现阶段若开新项目，我建议使用Java语言，Kotlin可先熟悉。除非主程对Kotlin语言有深刻的理解，可以考虑使用Kotlin。Kotlin语言是出来很久了，但是在国内的普及度还不够，很多人能用，但是不知道为什么可以这么用，彻底掌握的人不多。
使用Kotlin作为开发语言，项目中用到的第三方开源库如何选择？
关于在项目中使用到的第三方开源库，有人可能会想我们项目是以Kotlin语言为主的，同一个开源库若有Kotlin版本的，我就采用Kotlin版本的。到底是使用Java版的还是Kotlin版的？取决于开源库的Kotlin版本是否是该库的官方出的，后期是否会继续维护。开源库的选取，有以下几点：
- 亲自测评（团队里安排一个人），得出结论看是否满足当前的业务需求？遗留问题多少？可扩展性如何？该开源库的代码质量怎么样？
- 开源该库的作者，是否会继续维护，已经多久没维护了
- 能满足现有业务需求或稍微改动即可满足，半年内该库的作者是否有更新，遗留的问题不影响我们使用或者我们自己能修复。
- 至于是Kotlin版本还是Java版本，这个不重要，这个真的不重要。
关于新开的Android项目，我们到底应该如何去实施？
我们是搭建新的项目框架？还是使用以前成熟的项目框架？我们分一下几个方面讨论：
- 使用以前成熟的项目框架，好处：项目中常用的基础设施是完善的，由于项目整体架构导致的问题会比较少，毕竟经过了时间的考验。缺陷：可能该架构的理念陈旧，有些功能实现起来比较费事，对个人成长不利。
- 搭建全新的项目框架，好处：可以采用全新项目架构理念，比如使用基于Jetpack中的架构组件搭建MVVM架构，可以学习并在项目中实践最新架构理念，并作出比较判断，利于个人成长，利于项目后面维护扩展。缺点：需要在项目进行过程中填各种坑，不断完善打磨新的框架，需要团队成员学习新的知识，前期增加了项目的研发时间，增加了前期投入成本。
- 对于小团队，想要快速、低成本试错，建议使用以前成熟的项目框架；对于项目进度不是很赶的团队，可以考虑搭建新的项目架构。
综上所述，关于新开Android项目，我的建议是使用以前成熟的项目框架（能主导Android客户端开发的人，肯定是项目经验丰富的，手上一定有成熟的现成框架）。基于新的架构理念出现的新架构，可以在后面版本迭代过程中，那个版本时间充足的情况下引入，先拿小模块试错、填坑，成熟后后面新开的模块使用。
项目的整体架构如何选？
目前Android应用开发常用的架构有：MVC（默认）、MVP、MVVM和基于Jetpack中的 架构组件（AAC） 搭建MVVM架构，主要取决于主程（搭建项目基础设施的、解决疑难问题的、推动整个团队技术建设的）擅长的是那种架构 。不管是那种架构，掌握的熟练程度其实是最重要的。熟练就意味着项目整体框架中出现的问题，他能快速定位解决。
若前期时间相对充足的话，我建议试试使用基于Jetpack中的 架构组件（AAC） 搭建MVVM架构，或者学习官方提供的架构组件改善现有的项目框架。
是否要实施组件化？
需要先搞清楚组件化解决的问题是什么？
我们来看一个实际的业务场景，公司有一个3年以上的项目，这几年不断的增加各种功能，满足老板的需求。随着时间的流逝，项目越来越大，每次改动下重新编译一次需要几分钟，每次增加一个功能模块，测试团队都需要重新测试整个项目的功能（这是多大的测试工作量啊）。
今年我们公司又开了一个新项目，发现App版本升级、支付模块、分享模块都是一样的，把原来项目中的这几个模块Copy过来？
从上面的业务场景描述中，我们发现需要解决以下几个问题：
- 提升项目编译速度（开发工具已提供热更新，但是还是不能解决问题）
- 增加新的功能模块，其它功能模块不需要重新进行测试
- 现有功能模块的复用
- 现有功能模块的维护、扩展
组件化就是在出现超级App的情况下出现的解决方案，单一组件满足以下条件：
- 可单独开发、调试、维护、扩展
- 对外以接口形式提供其具备的功能，其他组件通过接口可以访问其提供的功能。
弄清楚了组件化解决的问题，对于是否要实施组件化开发，从以下几点我们分析：
- 从一开始团队成员就知道，将要研发的是一个大型项目，团队成员3人以上，建议从一开始就考虑引入组件话，有利于后面功能扩展、维护、增加人手等。
- 试错型或者中小型项目，团队1~2人，这种情况下是没必要引入组件化的。
- 想快速出版本，前期时间不是很充足，建议不要引入组件化。
一般情况下，不建议项目一开始就引入组件化。增加项目开发时间，属于吃力不讨好型，建议在需要时再引入比较合适。