Android Translucent System Bar 使用指南

近几天准备抽空总结Android一些系统UI的实践使用,于是开始动手建了一个库 AndroidSystemUiTraining ,边撸代码边写总结。今天开写第一篇,对 Translucent System Bar 的实践做一些总结。说起 Translucent System Bar 的特性,可能有些朋友还比较陌生,这里做一下简单的介绍。

看上图,Android 4.4之前,即使我们打开手机app,我们还总是能看到系统顶部那条黑乎乎的通知栏,这样会使得app稍显突兀。于是Android 4.4开始,便引入了Translucent System Bar的系特性,用于弥补系统通知栏突兀之处。(估计也是向ios学习,因为ios一大早就有这个特性)。我们先来看看 Translucent System Bar 新特性引入后,发生了什么样的变化。下面截取了 中华万年历的天气预报界面QQ音乐主界面 的效果(两个界面的效果实现 Translucent System Bar 的方式有些区别,下文会细讲)

可以看到,系统的通知栏和app界面融为一体,妈妈再也不用面对黑乎乎的通知栏了。有关 Translucent System Bar 的特性就暂且介绍到此。

工程简介

先简单介绍一下工程的结构,核心部分已经圈出,待我逐一讲解

  • 主要的操作都在style.xml 和 AndroidManifest.xml 中,Activity里面没有任何涉及到Translucent System Bar设置的代码,所以可以忽略不看。
  • ColorTranslucentBarActivity 和 ImageTranslucentBarActivity 分别用于展示两种不同实现方式的效果
  • 要在Activity中使用 Translucent System Bar 特性,首先需要到AndroidManifest中为指定的Activity设置Theme。但是需要注意的是,我们不能直接在values/style.xml直接去自定义 Translucet System Bar 的Theme,因为改特性仅兼容 Android 4.4 开始的平台,所以直接在values/style.xml声明引入,工程会报错。有些开发者朋友会在代码中去判断SDK的版本,然后再用代码设置Theme。虽然同样可以实现效果,但个人并不推崇这种做法。我所采取的方法则是建立多个SDK版本的values文件夹,系统会根据SDK的版本选择合适的Theme进行设置。大家可以看到上面我的工程里面有valuesvalues-v19values-v21

继续阅读全文 »

Android性能分析工具整理汇总

把做Android开发以来碰到的一些不错的性能分析工具做个整理汇总…

Debug GPU Overdraw

类型:系统自带功能UI渲染检测功能(打开Settings,然后到 Developer Options -> Debug GPU Overdraw 选择 Show overdraw areas,手机系统设置中文的孩纸,自行对照翻译进去哈)
作用:用来检测UI的重绘次数,开发者可以用来优化UI的性能。
使用心得:检测UI性能的利器,对于开发者做UI优化的帮助挺大的。因为大量的重绘容易让app造成卡顿或者直接导致丢帧的现象。开发者熟悉View的绘制原理可以结合对一些布局或者自定义控件做相应的优化。诸如:在ListView或GridView里面的item使用layout_weight设置就会造成多余重绘。其他情况还有很多,不一一例举。至于怎么用,可以自行Google

Profile GPU Rendering

类型:系统自带功能UI渲染检测功能(打开Settings,然后到 Developer Options -> Profile GPU Rendering. 选择 On screen as bars )
作用:用来检测UI绘制帧的速率和耗时,同样开发者可以用来优化UI的性能。
使用心得:跟Debug GPU Overdraw功能类似,但它反应的是UI绘制帧的速率,同样可以用来检测自己的app是否丢帧或者绘制过度,具体操作可以自行Google

Hierarchy Viewer

类型:SDK自带工具(打开Settings,然后到 Developer Options -> Profile GPU Rendering. 选择 On screen as bars )
作用:检测UI渲染用的
使用心得:老牌工具了,Google一下

Memory Monitor、Heap Viewer、Allocation Tracker

类型:AndroidStudio自带的工具
作用:均是内存检测分析的工具
使用心得:不用多说,大家懂的…

继续阅读全文 »

Android编码命名规范

今年正式本科毕业,目前为止参与过的团队开发项目也有四五个。阅读过各式各样的混乱代码,最离谱的见过所有的变量都用中文拼音首字母,心中真是万千匹草泥马在奔腾。由此,也意识到命名对于编码的重要性。有人说,看一个开发者的水平如何,从看他代码的命名可以大致得出结论。好的命名除了可以让项目成员快速且更好的理解代码,自己读起来也赏心悦目。为此,特地根据自己平常的一些编码规范和网上一些资料进行整理汇总,方便自己时常查看对比。

基本的命名法

Java编程比较常见的有下面三种命名方式

  1. 驼峰(Camel)命名法:又称小驼峰命名法,除首单词外,其余所有单词的第一个字母大写。
  2. 帕斯卡(pascal)命名法:又称大驼峰命名法,所有单词的第一个字母大写
  3. 下划线命名法:单词与单词间用下划线做间隔

一般建议拿来做命名的单词要比较精悍短小,这样即使两三个单词一起拼装成一个命名,也不至于显得很冗长。当然有些单词我们也可以直接写成一些约定俗成的缩写。诸如:msg(message)、init(initial)、img(image)等…..

个人认为,这些缩写可参照业界常见的缩写命名,也可以根据当前项目中的风格,进行团队成员间的约定。这样相对比较灵活,也方便团队成员之间相互理解。

包命名

采用反域名命名规则,全部使用小写字母。

  1. 一级包名为com;
  2. 二级包名为xx(可以是公司或则个人的随便);
  3. 三级包名应用的英文名app_name;
  4. 四级包名为模块名或层级名;

继续阅读全文 »