Android 技术选型闲聊
code小生,一个专注 Android 领域的技术平台
公众号回复 Android 加入我的安卓技术群
作者：DreamWinter
链接：https://www.jianshu.com/p/25cf7ce0d8d0
声明：本文已获DreamWinter授权发表，转发等请联系原作者授权
许久没有写技术博客了，这些时间也一直亲近Android，就聊聊技术选型。
技术选型对于一个项目的发展非常重要，个人认为：
技术决定下限，品味决定上限。
技术好只能保证做出来的App不烂，品味好了才能将有限的技术发挥到极致，将所做App提升一个档次。
网络框架
Retrofit + 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有几点需要注意：
架构
架构是个比较高大上的话题，因此经常装逼人士夸口聊。用MVP的同学看不起用MVC的，用MVVM的看不起用MVP的，用LiveModel的看不起用MVVM的。
但是我想说的是：
一味追求鄙视链顶端，就好像穿上一双不合脚的大鞋——徒增负担。
此外，我个人很不看好MVVM，Google那DataBinding太TM卡了，严重影响UI开发效率，而且增加了耦合性。
至于MVP，我觉得不如Fragment好用，同样是抽离，同样是拆分代码，Fragment可以做得更彻底，因为View可以跟着走。
至于LiveModel没用过，不做评价。但是有一个东西是真的好用——Lifecycles！这货专治内存泄露！原理很简单，就是观察者模式，监听页面的生命周期。牛逼之处在于Google将事件发布者集成到了Activity与Fragment，所以用起来非常方便。
总之，选架构之前一定要了解：
“九层之台，起于垒土”，多花点时间思考与参照是非常有必要的。
UI适配
其实不在这范畴，但今天在首页看到一篇蠢文，所以顺带聊聊UI。
layout选择
我一般只用这几个布局：
文字适配
挑一台最具代表性的大众设备，以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; //记得浮点数1f * longSide / shortSide > 18.51f / 9; //记得浮点数
该规则不会漏掉市面上任何一台刘海屏手机。但是，它会把极少数非刘海屏手机识别为刘海屏：OPPO、Vivo家的较新旗舰机。如果要进一步精准的话，就把那几台特殊的设备型号统计出来，加以判断即可（其实不是太必要，因为那么长的非刘海手机被识别成刘海屏，上方留了点背景关系不大）。
版本选择
再聊聊各种版本选择，比如IDE啊，第三方库啊，Android buildVersion啊。
个人偏好：
尾巴
惯例，留个尾巴。聊得比较休闲，没打草稿，更多是一些个人偏好，如有技术上的错误，还请指正。
推荐阅读
像极了爱情的技术路
Android 研发技术进阶之路
如何打造个人技术影响力
支持，「在看」