前言

okhttp是目前很火的网络请求框架，Android4.4开始HttpURLConnection的底层就是采用okhttp实现的，其Github地址：https://github.com/square/okhttp

来自官方说明：

OkHttp is an HTTP client that’s efficient by default:

• HTTP/2 support allows all requests to the same host to share a socket.
• Connection pooling reduces request latency (if HTTP/2 isn’t available).
• Transparent GZIP shrinks download sizes.
• Response caching avoids the network completely for repeat requests.

前言

新建一个AS工程，编译器会自动帮我们创建了Gradle Wrapper相关的文件，目录结构如下：

├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew
└── gradlew.bat

前言

本文主要介绍Java反射的内部原理，反射慢的原因，如何优化反射。

源码分析

平时开发中反射用得最多的应该是方法调用，下面分析反射调用方法的内部原理，先看getDeclaredMethod方法：

@CallerSensitive
public Method getDeclaredMethod(String name, Class<?>... parameterTypes)
    throws NoSuchMethodException, SecurityException {
    checkMemberAccess(Member.DECLARED, Reflection.getCallerClass(), true);
    Method method = searchMethods(privateGetDeclaredMethods(false), name, parameterTypes);
    if (method == null) {
        throw new NoSuchMethodException(getName() + "." + name + argumentTypesToString(parameterTypes));
    }
    return method;
}

前言

在项目中，使用多线程是很常见的事情，但是如果处理不当，代码写的不好，就可能会导致线程死锁，对于死锁问题，从发现到定位问题都是比较困难的，如果是线上用户发生了线程死锁，那就是难上加难了，因此最好是项目本身有自己一套线程死锁检测机制，能够自动检测，自动上报，然后我们分析上报日志就可以了。

WatchDog原理

前言

当我们执行git init命令，或者clone网上某个代码仓库后，会看到有一个.git目录，git所有版本控制信息就是放在目录里面，下面对这个.git目录进行分析。

.git目录

• hooks：钩子目录，存放执行指定git命令前或者后触发的脚本，可以看到默认会有几个sample文件，如果要开启某个钩子脚本，就把脚本文件名的后缀simple去掉就可以，这些钩子会在特定的时机被触发执行，比如post-commit在整个提交过程完成后执行，可以用于发送提交通知等，另外也有服务端钩子，在推送前或者后执行，比如post-receive在推送结束后会被执行，可以用于通知打包平台启动打包任务。关于git钩子更详细的信息可以参考：自定义 Git - Git 钩子。

• info：保存git的相关信息

• logs

  • refs：暂存记录，本地分支记录，远程分支记录

  • HEAD：记录每次的变更操作

前言

如果应用耗电量过大，就会消耗用户手机过多的电量，甚至发热，现在一般手机都会有耗电量过大的提醒，当用户看到后，也可能会把你的应用卸载掉，因此需要对其进行优化，让应用的耗电量尽可能小。

检测工具

Battery Historian：https://github.com/google/battery-historian

前言

Android中使用SQLite做为数据库，当数据量很大的情况下，就可能会出现性能问题，比如查询速度过慢，更新速度过慢等，因此需要对其进行优化。

优化方法

• 使用事务

  每次事务都会修改rollback journal文件，因此比较耗时，对于批量操作，应该合并到同一个事务中。

• 建立索引

  对查询多，更新少的字段建立索引，但索引会占用空间，而且会降低更新速度。

• 使用SQLiteStatement

  对于循环执行数据库操作，应该在循环外预编译好sql语句得到SQLiteStatement对象，然后循环内bindXXX，而不是直接在循环内调用execSQL方法，这样会导致创建大量的SQLiteStatement临时对象，而且每次都会重新编译sql语句。

• 缓存getColumnIndex返回结果

  对于循环执行数据库操作，getColumnIndex方法应该放到循环前调用，而不是每次循环都调用一次，虽然该方法的本质是从Map中查找index，但对性能还是有一定的影响的，放在循环前调用会稍微快一些。

• Cursor优化

  正如微信的WCDB所说，在合适的场景下，直接把Cursor的共享内存缓存去掉，会提高数据查询的速度。

• 分表、分库

  SQLite的同步锁是表级别的，因此为了避免等待，可以按照具体场景拆分为多个表，或者分库。

• SQL语句拼接

  不要用+进行连接，用StringBuilder，有循环的最后放到循环外部，不要每次循环都去生成sql语句字符串。

• SQL语句优化

  适用所有数据库优化，不仅仅只是SQLite，见下部分。

前言

APK包过大，可能会导致用户不想下载，或者消耗用户更多的流量，需要更多的下载等待时间，因此需要对APK进行瘦身，使得APK包尽量精简。

瘦身方法

• so优化

  1. so裁剪：避免为了使用一个小功能引入一个大的so，删除用不到的so代码和依赖。

  2. 只保留armeabi或者armeabi-v7a下的so文件：armeabi属于比较老的CPU架构，不支持硬件浮点运算，所以速度较慢，但兼容设备更多，而现在大部分首页都是支持armeabi-v7a架构的。

  3. 分渠道打包so：不同渠道的用户手机CPU架构不同，为了避免同时加入多种so，可以对不同渠道放入对应的so。

• 依赖库

  这里主要指第三方的jar，aar等依赖库，引入的库应该尽可能精简。

• res优化

  1. 只保留一套图片： 对于用到的图片，一般放到xxhdpi目录就可以，具体放哪里，要看目标用户手机主要的分辨率是多少。

  2. 动态加载：不是很重要的图，或者非首屏显示的图，改为动态加载。

  3. 图片压缩：tinypng，用webp代替png。

  4. 无用资源：用AS删除无用资源。

  5. 矢量图：用矢量图代替真实图片，矢量图代码占用空间小，而且不会失真。

  6. 多语言：对国内用户只打中文包，resConfigs指定为zh-rCN。

  7. 使用AndResGuard开源库：微信出的工具，用于压缩资源路径，同时也起到混淆资源文件名的作用。

  8. 精简字体文件：字体文件只包含需要用到的文字、数字或者符合等，而不是直接引入整个字体文件。

• assets优化

  跟res优化差不多，删除无用资源，压缩资源，动态下载。

• 代码优化

  1. 打开minifyEnabled：代码压缩，编译时会自动移除没有被使用到的代码，可以通过keep来强制指定不移除某些代码。

  2. 打开shrinkResources：资源压缩，必须在minifyEnabled为true的前提下使用，编译时会自动移除没有被使用到的资源，也可以自定义指定哪些资源不移除。

  3. proguard代码混淆：这个正式包都有，代码混淆能够减少类名、方法名等长度，移除没有被使用到的代码。

     注意minifyEnabled和proguard的区别：minifyEnabled只能移除无用代码，速度较快；而proguard除了能移除无用代码，还可以进行名称混淆，优化代码，速度较慢。参考文章：https://stackoverflow.com/questions/37007485/whats-the-difference-between-minifyenabled-and-useproguard-in-the-android-p

  4. 代码动态化：组件化，代码动态下载。

  5. 单个枚举大概占用1~1.4KB，用常量代替枚举。

为什么需要MultiDex

在Android5.0以下，虚拟机执行的是Dalvik指令，Dalvik指令集的方法索引参数至占用两个字节，也就是最多能区分65536个不同的方法，这个是65536方法数限制的根本原因，当然dx工具在打包时会直接判断方法数是否超过65536，超过就直接抛异常，这个只是表面原因。ART本身就对MultiDex做了支持，因此无需开发者对其做特殊处理。

如果APP启动速度很慢，会导致用户体验很差，甚至用户流失。所以我们需要持续地对启动速度进行优化，不断减少启动等待时间，把优化做到极致。

启动类型

启动类型可以分为三种：

• 冷启动

  进程不存在，启动时需要先创建进程，然后再创建并打开页面。

• 温启动

  进程存在，但页面不存在，只需要创建并打开页面。

• 热启动

  进程存在，页面也存在，直接把页面拉到前台即可。