Android 技术选型闲聊

来自:DreamWinter

许久没有写技术博客了,这些时间也一直亲近Android,就聊聊技术选型。
技术选型对于一个项目的发展非常重要,个人认为:

技术决定下限,品味决定上限。

技术好只能保证做出来的App不烂,品味好了才能将有限的技术发挥到极致,将所做App提升一个档次。

网络框架

Retrofit + RxJava + OkHttp
这似乎没啥可说的,已经是主流了,而且非常好用。

  • Retrofit充分利用注解的灵活性,以接口的形式配置来实现解耦。与后台沟通起来也非常方便,直接把api接口复制给他就成。

  • RxJava简直是回不去的一个伟大产物。Java的面向对象很科学,但多线程无穷回调真的要命,很简单的逻辑常常被弄得很混乱,RxJava很好的解决了这一问题。

  • OkHttp的优点我不是太了解,我只知道我用它之后没啥网络上的疑难,该有的都有,想做的都能做。

这里有个不错的Sample,对RxJava操作不太熟悉的同学可以了解下:
https%3A%2F%2Fgithub.com%2Famitshekhariitbhu%2FRxJava2-Android-Samples

热更新

一年前(2018),我在接热更新的时候还考虑过美团、阿里家的。现在我告诉你,全都pass,用Tinker。至于为什么,稍微关注下就知道哪些项目是骗业绩骗star的哪些是真正为解决问题用心维护的。

Tinker官方Wiki
为什么强推Tinker?首先,在我呆过的上家公司与现家,用Tinker发布过几十次热更新,没出过问题。Tinker基于bsdiff算法生成的差分包非常小,没涉及到文件资源添加的话,大都在30k以内。补丁包自动合成后会有回调,提示用户重启App即可生效。

使用Tinker有几点需要注意:

  • TinkerId非常重要,最好在App内某个地方显示出来;

  • Manifest.xml最好不要去改动,虽然某些改动生成的补丁包可以合成,但不是在所有设备上都能成功;

  • Tinker补丁是基于安装时全量包的TinkerId的,所以多次改动后可能会很大,建议过大时不再维护当前版本,而是发布一个新的全量包重新开始。(这段话比较拗口啊,慢慢理解)

  • 发布补丁时不要增加versionCode,尽管Tinker没有限制你,但是不要增加,否则会乱掉。versionCode是在全量发布apk时增加的。

架构

架构是个比较高大上的话题,因此经常装逼人士夸口聊。用MVP的同学看不起用MVC的,用MVVM的看不起用MVP的,用LiveModel的看不起用MVVM的。
但是我想说的是:

一味追求鄙视链顶端,就好像穿上一双不合脚的大鞋——徒增负担。

此外,我个人很不看好MVVM,Google那DataBinding太TM卡了,严重影响UI开发效率,而且增加了耦合性。

至于MVP,我觉得不如Fragment好用,同样是抽离,同样是拆分代码,Fragment可以做得更彻底,因为View可以跟着走。

至于LiveModel没用过,不做评价。但是有一个东西是真的好用——Lifecycles!这货专治内存泄露!原理很简单,就是观察者模式,监听页面的生命周期。牛逼之处在于Google将事件发布者集成到了Activity与Fragment,所以用起来非常方便。

总之,选架构之前一定要了解:

  • 这架构能解决什么问题?

  • 这架构又会带来哪些问题?

  • 扩展性怎样?

  • 会不会影响平均开发时长?

  • 对性能有没有影响?

“九层之台,起于垒土”,多花点时间思考与参照是非常有必要的。

UI适配

其实不在这范畴,但今天在首页看到一篇蠢文,所以顺带聊聊UI。

layout选择

我一般只用这几个布局:

  • LinearLayout:线性布局,直观的上下结构或者横竖结构,用它没问题。

  • FrameLayout:层叠布局,其实就是设计师眼里的“图层”,子控件之间没啥约束的优先用它。

  • ConstraintLayout:弹性布局,非常牛叉,适合约束比较复杂的页面。比如复杂的item我常用这个布局。RelativeLayout能做的它都能做,而且它自带比例控制。用好了它你才真正知道什么叫做“减少视图层级”。

  • CoordinatorLayout:我没叫过它中文名,也找不到好的译名,但在Android 5.0 Material Design兴起时,它是绝对的主角,沉浸式及一个漂亮的头部动画都离不开它,用好它的关键是理解Behavior。

文字适配

挑一台最具代表性的大众设备,以sp为单位适配好它就好。相同sp在不同设备,其物理大小是不一样的。比如同样是默认的14sp,同样是1080p,小米的会比华为的小一点,因为小米的dp/sp会小一点。

注意:

dp并非物理尺寸,屏幕多少dp*dp是由厂商定义的。

Google这样设计的好处是手机App可以直接适配电视。(想要验证上方论述很简单:在xml中画一个200dp*200dp的黑框,然后用不同设备预览)。

另外,dp尽量不要用小数(除非值很小,需控制误差),Google设计dp就是用来适配众多设备的,而不是丝毫不差用来适配设计稿的(因为大部分设计稿基于iOS设计)。如果真的是强迫每个设备上显示物理大小需要一致,那么直接用inch就行(少部分鸡贼厂商是没有给出准确inch的),也别用什么dp了(搬倒砖)。

刘海适配

三星之前的全面屏设备算长的了,都是没有刘海的,比例是18.5:9。
所以,可以得出最简单的规则:

boolean hasBang = 1f * longSide / shortSide > 18.51f / 9//记得浮点数

该规则不会漏掉市面上任何一台刘海屏手机。但是,它会把极少数非刘海屏手机识别为刘海屏:OPPO、Vivo家的较新旗舰机。如果要进一步精准的话,就把那几台特殊的设备型号统计出来,加以判断即可(其实不是太必要,因为那么长的非刘海手机被识别成刘海屏,上方留了点背景关系不大)。

版本选择

再聊聊各种版本选择,比如IDE啊,第三方库啊,Android buildVersion啊。

个人偏好:

  • 项目稳定性很重要的话,IDE尽量不要预览版(让别人去填坑吧)、各种库也是。

  • 第三方库之类的升级不要太着急,看看版本变动与issue。

  • 新开项目尽量用最新稳定版,不然以后还得适配api。

  • 现在是2019年了,Android 5.0已经发布5年了,App最低兼容到api21就行了(主要是5.0相比4.+变得太大了,过多的适配影响开发效率。实在要适配的话也只适配到api19,也就是Android4.4,占有率还是有一点的)。

  • 编译版本的话,新项目可以上Android X,我已经用了半年了,没啥问题。

尾巴

惯例,留个尾巴。聊得比较休闲,没打草稿,更多是一些个人偏好,如有技术上的错误,还请指正。

推荐↓↓↓
安卓开发
上一篇:Android 简单沉浸式弹出输入框 下一篇:你需要了解下Android View的更新 requestLayout 与重绘 invalidate