Android今日头条屏幕适配方案的原理梳理
前言
最近在项目里面遇到了屏幕适配的问题,UI要求APP在不同手机上展示效果和设计稿保持“像素级”同步,在对比了几种屏幕适配方案之后,选择了基于今日头条的AndroidAutoSize适配方案。
本文主要简单分析其适配原理,以及在实际使用中遇到的一个问题,需要更深入了解原理可以阅读文末参考文献。
正文
UI给的设计稿一般都是以像素px为单位,而在Android开发中官方推荐的使用的单位是dp。
Android笔记之Xfermode
Xfermode
是Android中用来指示Paint
绘制的内容与View中已有内容的混合计算方式,也就是用来确定图形绘制到目标图形的时候,如何处理两个图形重合部分的颜色变化。共18个,分为Alpha合成和混合两种。
设要绘制的图形为src
,已经绘制好的图形为dst
。
需要注意的是,这些图片除了要绘制的图形有着色之外,其他部分要为透明,并且包括透明区域在内的图片大小(宽高)要能完全覆盖另外一张图片的图形区域,否则绘制出的图形可能与预设的效果不一致
按照官方的定义,不同Xfermode
绘制结果如下:
Android笔记之贝塞尔曲线的应用
贝塞尔曲线是用节点和控制点绘制的高精度曲线,Android中常用的有二阶、三阶贝塞尔曲线。本文介绍使用贝塞尔曲线绘制折线图,并实现动画效果。
贝塞尔曲线介绍
下图是二阶贝塞尔曲线绘制方法介绍,只要各个点满足条件:AD/AB = BE/BC = DF/DE,那么当沿着当前线段移动D、E点时,F点的运动轨迹就是一个贝塞尔曲线:
Android paint绘制text
Android中绘制文字的方法如下:
1 | /** |
其中y
是文字baseline的y坐标。
下图表示Paint.FontMetrics
中存储的文字的各种信息(来源:简书):
我们没法直接获取到baseline的坐标
,所以只能从另外一个角度考虑:
因为在绘制文字时,文字的上下中心(即上图中的center
)是确定的,我们只要计算出center
到baseline
之间的偏移量,就可以计算出baseline的y坐标
。
LeetCode笔记--重建二叉树
二叉树的遍历根据根节点与左右子节点的遍历顺序的不同分为三种:
前序遍历
根左右:先遍历根节点,再左子树,再右子树(先从根节点开始,记录左节点直到没有)
第一个为根节点
中序遍历
左根右:先左子树,再根子树,再右子树(从树的最左边的节点开始遍历)
后序遍历
左右根:先左子树,后右子树,再根节点
最后一个为根节点
在遍历的时候,当父节点只有一个子节点时,依然要遵循以上三种遍历的先后顺序(没有该子节点则不写内容),以保证某一侧的子树(“左边的子树”或“右边的子树”)所有节点都被完全遍历,之后才可以根据遍历的规则切换到下一子树。
如如下子树:
1 | G |
Java笔记之YYYY格式化日期
最近看到一个帖子,表示有人以"YYYY-MM-dd"
格式化日期时,在2019-12-30
时出现2020-12-30
的BUG。
本文来简单分析一下为什么会出现这个情况。
根据JDK文档关于日期的定义,y
表示的是我们日常使用的年份,而Y
表示的是Week year
。
先了解几个知识点:
Week year
Android笔记之跨进程通信
Java笔记之序列化与反序列化:Serializable、Externalizable和Parcelable

序列化:指将Java对象
转化为字节流
以便在网络、文件中保存、传输。
反序列化:指的是从字节流中恢复Java对象。
本文主要讨论Android和Java中实现序列化的4种方式,并探讨一下其实现原理。
Android & Java中实现序列化的方式有:
Android中的SpareArray和ArrayMap实现分析
日常开发中,常用的存储键值对的数据结构是HashMap
,根据Java笔记之HashMap保存数据和Java笔记之计算Java对象的大小及其应用可以知道,HashMap
存储键值对会占用比较多的内存控件,而对于内存限制较大的Android平台来说,为了避免这种浪费,官方推荐我们使用SpareArray
和ArrayMap
,本文对这两个类的实现进行分析比较。
SpareArray
以及他的衍生类都是以基本类型为key
,因为避免了自动装箱,并且用数组直接保存key、value(而非像HashMap
那样将其封装为Node
对象后再保存),因而节省了内存。
ArrayMap
则支持所有类型的key,他是将key
和value
全部保存在一个数组中(n
位为key
,n+1
位为value
),避免了将其封装为Node
对象带来的内存消耗。
当要保存的数据量比较小(小于几千个)的时候,如果KEY是基本类型,推荐使用SparseArray
及其衍生类以节省内存,如果KEY是其他类型则使用ArrayMap
;否则使用HashMap
更加高效。