技术决定下限，品味决定上限。 技术好只能保证做出来的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，我已经用了半年了，没啥问题。
