Android应用开发用Kotlin还是Java 好?

关于Android应用程序开发,新开的项目应该选择使用Java还是Kotlin作为其开发语言?关于新开的Android项目,我们到底应该如何去实施?

在今年7月份初我参与了一个新项目的研发工作,在研发过程中遇到了一些问题,我想从下面几个方面和大家分享下:

  1. 新开的项目应该选择使用Java还是Kotlin作为其开发语言?Google官方都已官宣Kotlin为Android应用第一开发语言了,我一定要使用Kotlin语言?
  2. 使用Kotlin作为开发语言 项目中用到的第三方开源库如何选择?
  3. 关于新开的Android项目,我们到底应该如何去实施?
  4. Android项目的整体架构如何选?
  5. 是否要实施组件化?

新开的项目应该选择使用Java还是Kotlin作为其开发语言?Google官方都已官宣Kotlin为Android应用第一开发语言了,我一定要使用Kotlin语言?

这个主要看参与项目开发的人员组成及主程(一般是Android团队的主管、小组长或能力突出者)的能力及其擅长的技能,我们分以下几种情况来看:

  1. Android团队主程技术能力好,有丰富的项目经验(从事Android应用开发工作5年以上) ,Kotlin语言基本掌握,建议使用Java语言或Java主导Kotlin选择性使用。
  2. Android团队主管(小组长)专业技能一般,擅长管理团队,非常认可组内主程的能力,主程技术能力好,从事Android应用开发工作5年以上,建议使用Java语言;
  3. Android团队主管(小组长)和主程是同一个人,使用Kotlin语言2年以上的,可以考虑使用Kotlin,否则使用Java语言。
  4. Android团队主管(小组长)和主程是两个人,在技术选型上若有分歧,建议听主程的。

综上所述,你可能也看出来了,现阶段若开新项目,我建议使用Java语言,Kotlin可先熟悉。除非主程对Kotlin语言有深刻的理解,可以考虑使用Kotlin。Kotlin语言是出来很久了,但是在国内的普及度还不够,很多人能用,但是不知道为什么可以这么用,彻底掌握的人不多。

使用Kotlin作为开发语言,项目中用到的第三方开源库如何选择?

关于在项目中使用到的第三方开源库,有人可能会想我们项目是以Kotlin语言为主的,同一个开源库若有Kotlin版本的,我就采用Kotlin版本的。到底是使用Java版的还是Kotlin版的?取决于开源库的Kotlin版本是否是该库的官方出的,后期是否会继续维护。开源库的选取,有以下几点:

  1. 亲自测评(团队里安排一个人),得出结论看是否满足当前的业务需求?遗留问题多少?可扩展性如何?该开源库的代码质量怎么样?
  2. 开源该库的作者,是否会继续维护,已经多久没维护了
  3. 能满足现有业务需求或稍微改动即可满足,半年内该库的作者是否有更新,遗留的问题不影响我们使用或者我们自己能修复。
  4. 至于是Kotlin版本还是Java版本,这个不重要,这个真的不重要。

关于新开的Android项目,我们到底应该如何去实施?

我们是搭建新的项目框架?还是使用以前成熟的项目框架?我们分一下几个方面讨论:

  1. 使用以前成熟的项目框架,好处:项目中常用的基础设施是完善的,由于项目整体架构导致的问题会比较少,毕竟经过了时间的考验。缺陷:可能该架构的理念陈旧,有些功能实现起来比较费事,对个人成长不利。
  2. 搭建全新的项目框架,好处:可以采用全新项目架构理念,比如使用基于Jetpack中的架构组件搭建MVVM架构,可以学习并在项目中实践最新架构理念,并作出比较判断,利于个人成长,利于项目后面维护扩展。缺点:需要在项目进行过程中填各种坑,不断完善打磨新的框架,需要团队成员学习新的知识,前期增加了项目的研发时间,增加了前期投入成本。
  3. 对于小团队,想要快速、低成本试错,建议使用以前成熟的项目框架;对于项目进度不是很赶的团队,可以考虑搭建新的项目架构。

综上所述,关于新开Android项目,我的建议是使用以前成熟的项目框架(能主导Android客户端开发的人,肯定是项目经验丰富的,手上一定有成熟的现成框架)。基于新的架构理念出现的新架构,可以在后面版本迭代过程中,那个版本时间充足的情况下引入,先拿小模块试错、填坑,成熟后后面新开的模块使用。

项目的整体架构如何选?

目前Android应用开发常用的架构有:MVC(默认)、MVP、MVVM和基于Jetpack中的 架构组件(AAC) 搭建MVVM架构,主要取决于主程(搭建项目基础设施的、解决疑难问题的、推动整个团队技术建设的)擅长的是那种架构 。不管是那种架构,掌握的熟练程度其实是最重要的。熟练就意味着项目整体框架中出现的问题,他能快速定位解决。

若前期时间相对充足的话,我建议试试使用基于Jetpack中的 架构组件(AAC) 搭建MVVM架构,或者学习官方提供的架构组件改善现有的项目框架。

是否要实施组件化?

需要先搞清楚组件化解决的问题是什么?

我们来看一个实际的业务场景,公司有一个3年以上的项目,这几年不断的增加各种功能,满足老板的需求。随着时间的流逝,项目越来越大,每次改动下重新编译一次需要几分钟,每次增加一个功能模块,测试团队都需要重新测试整个项目的功能(这是多大的测试工作量啊)。

今年我们公司又开了一个新项目,发现App版本升级、支付模块、分享模块都是一样的,把原来项目中的这几个模块Copy过来?

从上面的业务场景描述中,我们发现需要解决以下几个问题:

  1. 提升项目编译速度(开发工具已提供热更新,但是还是不能解决问题)
  2. 增加新的功能模块,其它功能模块不需要重新进行测试
  3. 现有功能模块的复用
  4. 现有功能模块的维护、扩展

组件化就是在出现超级App的情况下出现的解决方案,单一组件满足以下条件:

  1. 可单独开发、调试、维护、扩展
  2. 对外以接口形式提供其具备的功能,其他组件通过接口可以访问其提供的功能。

弄清楚了组件化解决的问题,对于是否要实施组件化开发,从以下几点我们分析:

  1. 从一开始团队成员就知道,将要研发的是一个大型项目,团队成员3人以上,建议从一开始就考虑引入组件话,有利于后面功能扩展、维护、增加人手等。
  2. 试错型或者中小型项目,团队1~2人,这种情况下是没必要引入组件化的。
  3. 想快速出版本,前期时间不是很充足,建议不要引入组件化。

一般情况下,不建议项目一开始就引入组件化。增加项目开发时间,属于吃力不讨好型,建议在需要时再引入比较合适。

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值