许久没有写技术博客了,这些时间也一直亲近Android,就聊聊技术选型。
技术选型对于一个项目的发展非常重要,个人认为:
技术决定下限,品味决定上限。
技术好只能保证做出来的App不烂,品味好了才能将有限的技术发挥到极致,将所做App提升一个档次。
Retrofit + RxJava + OkHttp 这似乎没啥可说的,已经是主流了,而且非常好用。
这里有个不错的Sample,对RxJava操作不太熟悉的同学可以了解下: RxJava2-Android-Samples
一年前(2018),我在接热更新的时候还考虑过美团、阿里家的。现在我告诉你,全都pass,用Tinker。至于为什么,稍微关注下就知道哪些项目是骗业绩骗star的哪些是真正为解决问题用心维护的。 Tinker官方Wiki 为什么强推Tinker?首先,在我呆过的上家公司与现家,用Tinker发布过几十次热更新,没出过问题。Tinker基于bsdiff算法生成的差分包非常小,没涉及到文件资源添加的话,大都在30k以内。补丁包自动合成后会有回调,提示用户重启App即可生效。
使用Tinker有几点需要注意:
架构是个比较高大上的话题,因此经常装逼人士夸口聊。用MVP的同学看不起用MVC的,用MVVM的看不起用MVP的,用LiveModel的看不起用MVVM的。
但是我想说的是:
一味追求鄙视链顶端,就好像穿上一双不合脚的大鞋——徒增负担。
此外,我个人很不看好MVVM,Google那DataBinding太TM卡了,严重影响UI开发效率,而且增加了耦合性。
至于MVP,我觉得不如Fragment好用,同样是抽离,同样是拆分代码,Fragment可以做得更彻底,因为View可以跟着走。
至于LiveModel没用过,不做评价。但是有一个东西是真的好用——Lifecycles!这货专治内存泄露!原理很简单,就是观察者模式,监听页面的生命周期。牛逼之处在于Google将事件发布者集成到了Activity与Fragment,所以用起来非常方便。
总之,选架构之前一定要了解:
“九层之台,起于垒土”,多花点时间思考与参照是非常有必要的。
其实不在这范畴,但今天在首页看到一篇蠢文,所以顺带聊聊UI。
我一般只用这几个布局:
挑一台最具代表性的大众设备,以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啊。 个人偏好:
惯例,留个尾巴。聊得比较休闲,没打草稿,更多是一些个人偏好,如有技术上的错误,还请指正。