Android也做了一段时间了，做的项目也经历过大大小小的测试，这里把一些适配的实际情形写下来，方便日后查阅，后面会持续更新。
主要记录一些适配的实际情形，至于使用.9图、dp单位这类适配就不说了。

最后做的项目中，有用到横竖屏切换，碰到个小坑，在这里记录一下。

背景：用户在进入直播页面（姑且称之为RoomActivity），进入页面的时候会传入横竖屏的参数，在RoomActivity中拿到参数通过setRequestedOrientation来进行设置横竖屏。

众所周知，android在横竖屏切换的时候，会销毁当前的页面，然后重建，导致的便是activity的生命周期会执行2次，那么写在其中的方法也会执行2次。在onStart()中我写了进入直播间的方法(enterRoom())，在onStop()中写了离开直播间的方法(exitRoom())，那么在切换屏幕的时候，会调用2次enterRoom，1次exitRoom，因为都是网络请求，不能保证后请求的一定后完成，那么就有可能导致2次enterRoom执行完成之后，exitRoom才执行完成，即用户发了2次进入直播间的请求，1次离开直播间的请求，离开的请求是最后完成，导致的最终结果便是用户不在直播间了，但他依然能看到画面，只不过看不到弹幕相关的一些东西了。

这显然是个问题，需要解决。

前言

很早之前就听说过android MVP的模式，也看过许许多多的文章，但是众说纷纭，每个人有每个人的理解，如果光看，可能并不能很深刻的理解。但是作为android界的权威，Google出了一个MVP的官方例子。若是从这个例子来看MVP模式，或许会有不一样的感悟呢？多说无益，下面开始。

代码准备

Github上打开googlesamples/android-architecture，打开分支，选择todo-mvp（Basic Model-View-Presenter architecture），然后下载zip，解压后导入到AS中。

前言

在这个技术日新月累的今天，各种新的轮子层出不穷。网络这块，从HttpClient到android-async-http，再到Volley。当下比较火的网络框架Retrofit也是受到了很多开发者的热爱。虽然项目中并没有使用到Retrofit，但抱着学习的态度，我还是打算接触一下，算是有个了解。说不定后面的开发中会用到呢？

Retrofit概述

Retrofit是一个 RESTful 的 HTTP 网络请求框架的封装。注意这里并没有说它是网络请求框架，主要原因在于网络请求的工作并不是Retrofit来完成的。Retrofit 2.0开始内置OkHttp，前者专注于接口的封装，后者专注于网络请求的高效，二者分工协作。
我们的应用程序通过Retrofit请求网络，实际上是使用Retrofit接口层封装请求参数、Header、Url等信息，之后由OkHttp完成后续的请求操作，在服务端返回数据之后，OkHttp将原始的结果交给Retrofit，后者根据用户的需求对结果进行解析的过程。所谓Retrofit，其实就是Retrofitting OkHttp了。

项目中有这样一个需求：

用户点击送礼物，会弹出一个礼物选择对话框，然后在选择一个礼物之后，可以选择礼物数量，按照图中的意思，选择数量很自然的想到了用PopupWindow来做了。但是这里有一个问题就是：弹出来的数量选择框是需要在数量显示栏的上方的。

如果是在下方，那很简单，直接popupWindow.showAsDropDown(v);即可。但若是在上方，则需要自己计算坐标了，然后通过showAtLocation()方法来显示。

前言

在我的Android实现简易轻量下载器：单线程任务队列文章中，有提到过任务队列。当时是需要下载，实现一个简单的单线程任务队列即可。
最近项目中也需要用到任务队列，并且有2种需求：

1. 动态礼物动画：在用户送完动态礼物之后，会在界面上展现一个动画。界面上一次最多能执行1个动画，动画按顺序执行。即：一个入口一个出口。
2. 静态礼物动画：在用户送完静态礼物之后，会在界面上展现一个动画。界面上一次最多能并列执行2个动画，动画按顺序执行。即：一个入口两个出口。
   同样都是任务队列，只不过一个是只有一个出口，另一个有两个出口。

项目组支付宝商户审核通过，要准备接入支付宝移动支付的能力，本文主要讲述一下android接入支付宝移动支付SDK的步骤。

前期准备

1. 支付宝商户网站注册支付宝商户账号。
2. 签约移动支付产品，等到审核通过。
3. 秘钥的生成与上传。
   注册和签约没什么好说的，由公司相关部门或人员进行操作就好了。这里重点讲一下密钥。

本篇博客主要介绍如何实现一个仪表盘动态显示的效果，此效果来源于买卖人这个应用，3个室友有2个做安卓，而且都在买卖人，所以我也跟着实现了一波。
效果如下：

前言

项目中对于图片的长宽比有很严格的需求，如果比例不一致，那么在App上显示会影响体验，于是要求长宽比一致。但是比例并不是固定的，有的图需要1:1比例，有的图需要14:9比例，有的图又需要9:16的比例。

起初我的想法是，自定义View在onMeasure里利用比例，将计算后的宽高设置给View就好了。但是这么一想，比例不一致啊。现在需要3种比例，我要自定义3个View，那如果后面有其他的一些比例呢？我不是又得写啦~

抱着偷懒的态度，我设想用自定义属性来解决这个问题，自己设置比例，这样只用自定义一个View，然后根据传入的比例再行计算即可。

问题

在我的上一篇文章中，写了自定义弧形SeekBar，效果达到了自己的预期，于是高高兴兴回家了。但是后面手贱，在家里自己随意玩了玩，发现SeekBar滑动几下之后再滑动就会变得特别卡。然后查看代码，短时间内没什么头绪。

没错，这个时候又要祭出我的室友了。

室友之前是做rom相关的，对于android系统工具用得很熟。然后他拿着我的手机打开开发者选项中的GPU呈现模式分析，运行了一下程序，滑了一会之后就这样了：