那些值得你试试的Android竞品分析工具

本文整理了一些自己在开发过程中经常会用到的竞品分析工具,这些工具可以帮助分析竞品。让我们得以了解竞品相应的一些技术信息,例如:代码质量、某种业务的实现方式、用了什么第三方库等。除此之外,也有一些高端玩家会玩起 HOOK ,更有甚者是通过修改代码然后进行二次打包。当然这些损害开发者利益的事情,是不值得提倡的。但如果只是出于学习的目的,我是十分建议多折腾的。

提前声明:

  • 本文只对工具做简要功能介绍,要求面面俱到讲解每个工具使用,本人表示能力有限啊;
  • 下文所介绍的工具,都会附上这些工具的官方地址以及相应的使用教程链接(如果有);
  • 有童鞋对下文提到的工具已经用得出神入化,欢迎写成文章,可以的话,也欢迎给个链接让我补充进本文,顺带学习一下;
  • 本文所有提到的工具只做分析学习使用,请不要拿去做损害他人利益的事情

Apk 内部结构

为了方便介绍工具,需要先简单科普一下 Apk 的内部结构,已经很熟悉的童鞋可以忽略此章节。需要注意的是,这里介绍的 Apk 结构并不包含加固的情况,虽然很多厂家推出了加固服务用于对抗反编译,但是加固也有诸多的问题存在,另外基本上分析的大厂应用都没有发现有加固的,可能也是考虑到加固后安装包存在的诸多问题吧。

直接使用 Android Studio 创建一个 HelloWorld 的 Moudle,然后打个 release 的 Apk 安装包,并修改后缀 apk 为 zip 后进行解压,可以看到下面一个标准的结构:

  • META-INF: 存放签名文件签名信息的目录,用于系统签名校验
  • res: 存放资源文件的目录,包含项目中的 xml 和 图片资源等
  • AndroidManifest.xml: Android项目中的配置文件
  • classes.dex: 由Java产生的字节码文件打包生成为虚拟机可以解读的字节码文件,所有的源码都在其中
  • resources.arsc: 资源文件的ID索引表,如:layout、drawable、mipmap都会在R文件生成相应的ID资源
  • 其他目录:开发者自行添加的目录,如:存放资源的 asserts 、存放依赖包的 lib 目录等

上面介绍完了一个最基本的 Apk 解压后的目录结构,下面直接拿微信作为示例,看看大厂应用的结构是怎样的:

继续阅读全文 »

你需要知道的Android拍照适配方案

说起调用系统相机来拍照的功能,大家肯定不陌生,现在所有应用都具备这个功能。例如最基本的,用户拍照上传头像。Android开发的孩纸都知道,碎片化给拍照这个功能的实现带来挺多头疼的问题。所以,我决定写写一些网上不多见但又经常听到童鞋们吐槽的问题。

拍照功能实现

Android 程序上实现拍照功能的方式分为两种:第一种是利用相机的 API 来自定义相机,第二种是利用 Intent 调用系统指定的相机拍照。下面讲的内容都是针对第二种实现方式的适配。

通常情况下,我们调用拍照的业务场景是如下面这样的:

  1. A 界面,点击按钮调用相机拍照;
  2. A 界面得到拍完照片,跳转到 B 界面进行预览;
  3. B 界面有个按钮,点击后触发某个业务流程来处理这张照片;

实现的大体流程代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
//1、调用相机
File mPhotoFile = new File(folder,filename);
Intent captureIntent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
Uri fileUri = Uri.fromFile(mPhotoFile);
captureIntent.putExtra(MediaStore.EXTRA_OUTPUT, fileUri);
mActivity.startActivityForResult(captureIntent, CAPTURE_PHOTO_REQUEST_CODE);
//2、拿到照片
@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
if (requestCode == CapturePhotoHelper.CAPTURE_PHOTO_REQUEST_CODE && resultCode == RESULT_OK) {
File photoFile = mCapturePhotoHelper.getPhoto();//获取拍完的照片
if (photoFile != null) {
PhotoPreviewActivity.preview(this, photoFile);//跳转到预览界面
}
finish();
} else {
super.onActivityResult(requestCode, resultCode, data);
}
}
//3、各种各样处理这张图片的业务代码

到这里基本科普完了如何调用系统相机拍照,相信这些网上一搜一大把的代码,很多童鞋都能看懂。

有没有相机可用?

前面讲到我们是调用系统指定的相机app来拍照,那么系统是否存在可以被我们调用的app呢?这个我们不敢确定,毕竟 Android 奇葩问题多,还真有遇到过这种极端的情况导致闪退的。虽然很极端,但作为客户端人员还是要进行处理,方式有二:

继续阅读全文 »

关于 Android 进程保活,你所需要知道的一切

早前,我在知乎上回答了这样一个问题:怎么让 Android 程序一直后台运行,像 QQ 一样不被杀死?。关于 Android 平台的进程保活这一块,想必是所有 Android 开发者瞩目的内容之一。你到网上搜 Android 进程保活,可以搜出各种各样神乎其技的做法,绝大多数都是极其不靠谱。前段时间,Github还出现了一个很火的“黑科技”进程保活库,声称可以做到进程永生不死

怀着学习和膜拜的心情进去Github围观,结果发现很多人提了 Issue 说各种各样的机子无法成功保活。

看到这里,我瞬间就放心了。坦白的讲,我是真心不希望有这种黑科技存在的,它只会滋生更多的流氓应用,拖垮我大 Android 平台的流畅性。

扯了这么多,接下来就直接进入本文的正题,谈谈关于进程保活的知识。提前声明以下四点

  • 本文是本人开发 Android 至今综合各方资料所得
  • 不以节能来维持进程保活的手段,都是耍流氓
  • 本文不是教你做永生不死的进程,如果指望实现进程永生不死,请忽略本文
  • 本文有错误的地方,欢迎留下评论互相探讨(拍砖请轻拍)

保活手段

当前业界的Android进程保活手段主要分为 黑、白、灰 三种,其大致的实现思路如下:

  • 黑色保活:不同的app进程,用广播相互唤醒(包括利用系统提供的广播进行唤醒)
  • 白色保活:启动前台Service
  • 灰色保活:利用系统的漏洞启动前台Service

继续阅读全文 »

我的 Android 开发实战经验总结

以前一直想写一篇总结 Android 开发经验的文章,估计当时的我还达不到某种水平,所以思路跟不上,下笔又捉襟见肘。近日,思路较为明朗,于是重新操起键盘开始码字一番。先声明一下哈,本人不是大厂的程序猿。去年毕业前,就一直在当前创业小团队从事自己热爱的打码事业至今。下面总结是建立在我当前的技术水平和认知上写的,如有不同看法欢迎留下评论互相交流。

1.理解抽象,封装变化

目前 Android 平台上绝大部分开发都是用着 Java ,而跟 Java 这样一门面向对象的语言打交道,不免要触碰到 抽象封装 的概念。我身边接触过的一些开发者,有一部分还对这些概念停留在写一个抽象类、接口、或者一个方法(或抽象方法)。至于为什么,我不大清楚是他们表达不出来,还是不理解。下面我也不高谈阔论,直接举例子来解释我所理解的抽象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
//Activity 间使用 Intent 传递数据的两种写法 下面均是伪代码形式,请忽略一些细节
//写法一
//SrcActivity 传递数据给 DestActivity
Intent intent = new Intent(this,DestActivity.class);
intent.putExtra("param", "clock");
SrcActivity.startActivity(intent);
//DestActivity 获取 SrcActivity 传递过来的数据
String param = getIntent.getStringExtra("param");
//写法二
//SrcActivity 传递数据给 DestActivity
Intent intent = new Intent(this,DestActivity.class);
intent.putExtra(DestActivity.EXTRA_PARAM, "clock");
SrcActivity.startActivity(intent);
//DestActivity 获取 SrcActivity 传递过来的数据
public final static String EXTRA_PARAM = "param";
String param = getIntent.getStringExtra(EXTRA_PARAM);

写法一,存在的问题是,如果 SrcActivity 和 DestActivity 哪个把 “param” 打错成 “para” 或者 “paran” ,传递的数据都无法成功接收到。而写法二则不会出现此类问题,因为两个 Activity 之间传递数据只需要知道 EXTRA_PARAM 变量即可,至于 EXTRA_PARAM 变量到底是 “param” 、 “para” 、”paran” 这一点并不需要关心,这就是一种对可能发生变化的地方进行抽象封装的体现,它所带来的好处就是降低手抖出错的概率,同时方便我们进行修改。

基于抽象和封装,Java 本身很多 API 在设计上就有这样的体现,如 Collections 中的很多排序方法:

这些方法都是基于 List 这个抽象的列表接口进行排序,至于这是一个用什么样的数据结构实现 List(ArrayList 还是 LinkedList),排序方法本身并不关心。看,是不是体现了 JDK 的设计人员的一种抽象编程的思维,因为 List 的具体实现可能有千万种,如果每一类 List 都要写一套排序方法,估计要哭瞎了。

小结:把容易出现变化的部分进行抽象,就是对变化的一种封装。

继续阅读全文 »

Android开发:最详细的 NavigationDrawer 开发实践总结

继前面写的两篇文章之后(有问题欢迎反馈哦):

  1. Android Translucent System Bar 使用指南
  2. Android Toolbar 使用指南

接着来写写Android系统UI新特性,本文是我对最近开发过程中应用 NavigationDrawer 特性的详细总结。本文涉及到的所有代码实现细节,会在文末附上源码地址。有问题欢迎在下方留言讨论

NavigationDrawer 是 Google 在 Material Design 中推出的一种侧滑导航栏设计风格。说起来可能很抽象,我们直接来看看 网易云音乐 的侧滑导航栏效果

Google 为了支持这样的导航效果,推出一个新控件 —— DrawerLayout 。而在 DrawerLayout 没诞生之前,需求中需要实现侧滑导航效果时,我们必然会选择去选择一些成熟的第三方开源库(如最有名的 SlidingMenu)来完成开发 。效果上,普遍都像 手Q 那样:

在对比过 DrawerLayoutSlidingMenu 的实现效果后,基于以下的几点,我认为完全可以在开发中使用 DrawerLayout 取代以前的 SlidingMenu

  1. 从动画效果上看,你会发现两者仅仅是在移动的效果上有些差别外,其他地方并没有太大的差异
  2. 在交互效果上,我认为这两者都差不多的,就算你把 网易云音乐 的效果套到了 手Q 上,也不会影响到用户的交互
  3. DrawerLayout 用起来比 SlidingMenu 更简单,代码量更少(往下看就知道了)
  4. DrawerLayout 是向下兼容的,所以不会存在低版本兼容性问题
  5. Google 亲儿子,没理由不支持啊!!!!!!

到这里,要是你还没有引入 DrawerLayout 开发的冲动,请继续听我为你好好安利一番。

初识 DrawerLayout

一般情况下,在 DrawerLayout 布局下只会存在两个子布局,一个 内容布局 和 一个 侧滑菜单布局,这两个布局关键在于 android:layout_gravity 属性的设置。如果你想把其中一个子布局设置成为左侧滑菜单,只需要设置 android:layout_gravity=”start” 即可(也可以是 left,右侧滑则为 end 或 right ),而没有设置的布局则自然成为 内容布局 。那么,使用 DrawerLayout 到底有多简单呢,我们先直接看看下面的布局文件 layout/activity_simple_drawer.xml

继续阅读全文 »

Android Toolbar 使用指南

过年前发了一篇介绍 Translucent System Bar 特性的文章 Android Translucent System Bar 使用指南,收到很多开发者的关注和反馈。今天开始写第二篇,全面的介绍一下 Toolbar 的使用。说起 Toolbar ,可能有很多开发的童鞋还比较陌生,没关系,请接着往下看。

初识 Toolbar

Toolbar 是在 Android 5.0 开始推出的一个 Material Design 风格的导航控件 ,Google 非常推荐大家使用 Toolbar 来作为Android客户端的导航栏,以此来取代之前的 Actionbar 。与 Actionbar 相比,Toolbar 明显要灵活的多。它不像 Actionbar 一样,一定要固定在Activity的顶部,而是可以放到界面的任意位置。除此之外,在设计 Toolbar 的时候,Google也留给了开发者很多可定制修改的余地,这些可定制修改的属性在API文档中都有详细介绍,如:

  • 设置导航栏图标;
  • 设置App的logo;
  • 支持设置标题和子标题;
  • 支持添加一个或多个的自定义控件;
  • 支持Action Menu;

总之,与 Actionbar 相比,Toolbar 让我感受到Google满满的诚意。怎样?是否已经对 Toolbar 有大概的了解,跃跃欲试的感觉出来了有木有?接下来,我们就一步一步的来看如何使用 Toolbar(其实是我使用 Toolbar 踩坑填坑的血泪史,你们接下去看,我先擦个眼泪…. )。

开始使用 Toolbar

前面提到 Toolbar 是在 Android 5.0 才开始加上的,Google 为了将这一设计向下兼容,自然也少不了要推出兼容版的 Toolbar 。为此,我们需要在工程中引入 appcompat-v7 的兼容包,使用 android.support.v7.widget.Toolbar 进行开发。下面看一下代码结构,同样把重点部分已经红圈圈出:

  • ToolbarActivity 包含了 Toolbar 的一些基本使用, ZhiHuActivity 是在熟悉了 Toolbar 后对知乎主页面的一个高仿实现。

  • layout和menu文件夹分别是上面提到的两个Activity的布局文件 和 actionmenu 菜单文件。

  • values、values-v19、values-v21 中包含了一些自定义的 theme,后面用到的时候会顺带讲解。

我们先来看一下 ToolbarActivity 的运行效果

按照效果图,从左到右分别是我们前面提及到的 导航栏图标App的logo标题和子标题自定义控件、以及 ActionMenu 。接着,我们来看下布局文件和代码实现。

首先,在布局文件 activity_tool_bar.xml 中添加进我们需要的 Toolbar 控件

继续阅读全文 »

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. 四级包名为模块名或层级名;

继续阅读全文 »