include重用 merge减少布局层级 ViewStub延迟加载
重用” target=”_blank”>1、< include/>重用
比如我们要写一个TitleBar（title_bar_layout.xml）,是这样子的。
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="50dp"
android:orientation="horizontal">
<TextView
android:layout_width="50dp"
android:layout_height="match_parent"
android:background="@drawable/back" />
<TextView
android:layout_width="0dp"
android:layout_height="match_parent"
android:layout_weight="1"
android:gravity="center"
android:text="竞技台"
android:textSize="18sp" />
<TextView
android:layout_width="50dp"
android:layout_height="match_parent"
android:gravity="center"
android:text="确定"
android:textSize="18sp" />
</LinearLayout>每一个项目中都有TitleBar，所以使用< include/>进行服用，以便统一管理，在使用的时候，一行代码就OK了。
<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:id="@+id/activity_layout_opt"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context="zhangwan.wj.com.myshare.activity.LayoutOptActivity">
<include layout="@layout/title_bar_layout" />
</FrameLayout>减少视图层级” target=”_blank”>2、< merge/>减少视图层级
为什么要减少视图层级，在加载布局的时候，rinflater是通过深度优先遍历来构造视图树，每解析到一个View，就会递归调用rinflater,直到这条路径的最后一个元素，然后再回溯过来将每一个View添加到他们的parent中，整个View树构建完毕。在使用了include后可能导致布局嵌套过多，出现不必要的layout节点，从而导致解析变慢。这个时候我们可以使用< merge/>标签。< merge/>标签可用于两种典型情况：
布局顶结点是FrameLayout且不需要设置background或padding等属性，可以用merge代替，因为Activity内容试图的parent view就是个FrameLayout，所以可以用merge消除只剩一个。
某布局作为子布局被其他布局include时，使用merge当作该布局的顶节点，这样在被引入时顶结点会自动被忽略，而将其子节点全部合并到主布局中。
为了更好理解这两种情况，我们复习一下DecroView，DecroView是Activity的顶级View，继承与FramLayout,内部有一个竖直方向的LinerLayout,上面是标题栏，下面内容栏，内容栏是我们Activity的setContentView的布局，这个内容栏是个FramLayout。
我们看第一种情况，我们通过View Hierarchy工具看一下，如图：
发现了有一个FrameLayout是不需要的。使用< merge/>修改。
<?xml version="1.0" encoding="utf-8"?>
<merge xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:id="@+id/activity_layout_opt"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context="zhangwan.wj.com.myshare.activity.LayoutOptActivity">
<include layout="@layout/title_bar_layout" />
</merge>我们在通过View Hierarchy工具看一下，如图：
我们在看第二种情况
比如，如果你有一个 Layout 是一个竖直方向的 LinearLayout，其中包含两个连续的 View 可以在别的 Layout 中重用，那么你会做一个 LinearLayout 来包含这两个 View ，以便重用。不过，当使用另一个 LinearLayout 来嵌套这个可重用的 LinearLayout 时，这种嵌套 LinearLayout 的方式除了减慢你的 UI 性能外没有任何意义。
为了避免这种情况，你可以用 < merge/> 元素来替代可重用 Layout 的根节点。例如：
<merge xmlns:android="http://schemas.android.com/apk/res/android">
<Button
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="@string/add"/>
<Button
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:text="@string/delete"/>
</merge>ViewStub延迟加载
延迟加载意味着我们可以分批次的将一个Layout中的View解析加载到内存，比如说，我们最先加载Loading的布局，等待网络请求，然后加载常规展示的布局，当网络请求发生错误或者空数据的时候，加载错误布局。分批次加载减轻了CPU和GPU的负担，ViewStub 是一个轻量的视图，不需要大小信息，也不会在被加入的 Layout 中绘制任何东西。ViewStub可见或是被inflate了，ViewStub就不存在了，取而代之的是被inflate的Layout。所以它也被称做惰性控件。
<?xml version="1.0" encoding="utf-8"?>
<merge xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context="zhangwan.wj.com.myshare.activity.LayoutOptActivity">
<include layout="@layout/title_bar_layout" />
<ViewStub
android:inflatedId="@+id/no_data_view"
android:id="@+id/no_data_view"
android:layout="@layout/no_data_layout"
android:layout_width="match_parent"
android:layout_height="match_parent"/>
</merge>注意android:inflatedId指定的no_data_view是布局no_data_layout的根id, android:layout=”@layout/no_data_layout”是指定加载哪个布局。
要让ViewStub显示出来，可以用viewStub.infalte()或viewStub.setVisibility(View.VISIBLE)来完成，如下。
public void showEmptyView() {
// listview.setVisibility(View.GONE);
if (mNoDataView == null) {
ViewStub noDataViewStub = (ViewStub)findViewById(R.id.no_data_view);
mNoDataView = noDataViewStub.inflate();
} else {
mNoDataView.setVisibility(View.VISIBLE);
}
}现在你可能会问，ViewStub和View.GONE的区别。他们的共同点是一开始的时候都不会显示，但是View.GONE在布局加载的时候，就已经添加到布局树上了，而ViewStub只会在显示的时候才会渲染布局。最后注意ViewStub加载的布局中不能有merge。
如何优化?
减少布局的层级,合理的使用include,merge,ViewStub
自定义组件的onDraw()中避免大量创建临时对象,比如String,以免频繁触发GC
自定义组件的onDraw()中,考虑使用canvas.clipRect()绘制需要被绘制的区域
对像ListView这样的组件容器,考虑使用convertView,使用ViewHolder,
考虑使用性能更高的组件,比如推荐使用RecycleView来代替ListView,
###使用staticlayout来实现自动换行
针对代码优化
无用代码扫描
同无用资源扫描方式一样，可以针对无用的代码进行扫描，这里需要关注的一点就是在插件里面通过反射的方法调用的主应用的一些类和方法是不能删除的。
也可以使用SonarQube扫描无用类，以及不同类里面的重复代码。
详情请参考：
github.com/SonarSource…
针对整体优化
签名方式
Google在Android7.0系统提供了新的apksigner签名工具，相比使用java提供的jarsigner签名工具，APK体积可以减小约5%（依赖文件数量）。
对比未签名的APK，用jarsigner签名工具签名，APK里面所有压缩后的文件和文件夹体积都增大了；而apksigner签名工具签名，除了META_INF文件夹增大了以外，其它文件和文件夹的大小都没有改变。
产生上述变化的原因是：
jarsigner是针对每个文件进行了签名，然后针对签名后的文件计算摘要，并写入到META-INF文件夹下的MANIFEST.MF文件里面；而apksigner直接计算所有文件的摘要，写入MANIFEST.MF文件。
新的apksigner工具，已经集成到Android 7.0 SDK中了，使用方法可以参考官方文档：
developer.android.com/studio/comm…
针对整体优化
7ZIP压缩
我们知道Apk文件实际上就是一个Zip文件。Android SDK的打包工具apkbuilder采用的是Deflate算法将Android App的代码、资源等文件进行压缩，压缩成Zip格式，然后签名发布。
既然是压缩，那能不能改进其压缩方式，获取更小的Apk文件？通过分析Apk打包的流程图我们可以发现SignedJarBuilder类对整个工程包括代码Dex和一些压缩的资源、文件进行压缩，使用的是JDK中zip包下提供的算法。
简单的方式我们可以在不改变App编译器工作的情况下，对生成的Apk文件进行二次压缩，同样使用Deflate算法，但是将压缩等级从标准提升到极限压缩。提高压缩级别可在不对Apk包本身的内容做任何修改的情况下得到更小的Apk。
## 备注：
需要注意这样极限压缩之后的签名被破坏，需要重新签名。
Android平台对Apk安装包的解压算法只支持Deflate算法，其它算法如LZMA，虽然压缩率更好，但是由于Android平台默认不支持，所以如果采用这种算法压缩Apk，会导致Apk无法安装。
目前在Mac上没发现好用的7Zip压缩软件，需要在Windows下使用。
一般情况下面，AS直接编译生成的APK里面，.arsc文件是没有进行任何压缩的，前文中APK组成部分的第一张图就可以看出。
下面，我们来解压APK，重新用7zip进行压缩，就会发现几乎所有文件都变小了，特别是.arsc文件，减小的比较多。
将APK包解压到文件夹
全选所有文件，右键“添加到压缩包”
3.“压缩格式”必须“zip”
4.“压缩等级”选择“极限压缩”
5.“压缩方法”必须“Deflate”（试了Deflate64,BZip2,LZMA,PPMd都无法正常安装）
6.“单词大小”选择“256”
- 将后缀改为APK即可
出现 adb – [INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION] 未签名的应用安装失败。
## 从命令行构建和签署您的应用
不需要 Android Studio 也可以签署您的应用。您可以通过 apksigner 工具从命令行签署您的应用，或在构建期间配置 Gradle 来签署您的应用。无论使用哪一个方式，您必须首先使用 keytool 生成一个私钥。例如：
keytool -genkey -v -keystore my-release-key.jks
-keyalg RSA -keysize 2048 -validity 10000 -alias my-alias注：keytool 位于 JDK 中的 bin/ 目录中。要从 Android Studio 查找您的 JDK，选择 File > Project Structure，然后点击 SDK Location，您将看到 JDK location。
本示例会提示您输入密钥库和密钥的密码，并为您的密钥提供“Distinguished Name”字段。随后，它生成一个名为 my-release-key.jks 的密钥库文件，将它保存在当前目录中（您可以根据需要移动它）。此密钥库包含一个有效期为 10,000 天的密钥。
现在，您可以构建一个未签署的 APK 并手动签署它，也可以配置 Gradle 以签署您的 APK。
## 构建未签署 APK 并手动签署它
打开命令行，然后导航至项目的根目录 – 在 Android Studio 中，选择 View > Tool Windows > Terminal。然后调用 assembleRelease 任务：
gradlew assembleRelease这将在 project_name/module_name/build/outputs/apk/ 中创建一个名为 module_name-unsigned.apk 的 APK。此 APK 此时处于未签署且未对齐的状态，使用您的私钥签署后才能安装。
使用 zipalign 对齐未签署的 APK：
zipalign -v -p 4 my-app-unsigned.apk my-app-unsigned-aligned.apkzipalign 可以确保所有未压缩的数据的开头均相对于文件开头部分执行特定的字节对齐，这样可减少应用消耗的 RAM 量。
通过 apksigner 使用您的私钥签署 APK：
apksigner sign --ks my-release-key.jks --out my-app-release.apk my-app-unsigned-aligned.apk在本例中，在使用单密钥库文件 my-release-key.jks 中存储的私钥和证书签署 APK 后，将以 my-app-release.apk 的形式输出签署的 APK。
apksigner 工具支持其他签署选项，包括使用单独的私钥和证书文件签署 APK 文件和使用多个签署人签署 APK。有关更多详情，请参阅 apksigner 参考。
注：要使用 apksigner 工具，您必须已安装 Android SDK Build Tool 的修订版 24.0.3 或更高版本。您可以使用 SDK 管理器更新此软件包。
验证您的 APK 是否已签署：
apksigner verify my-app-release.apk针对资源优化
优化库中资源
通常在大型的项目中，都会引入很多系统库和第三方的库。
比如低版本兼容库V4、V7、网络请求库、图片处理库等，如果库中包含一些大图，而我们并不会用到，就可以采用1×1的透明图片替代，达到既能编译通过，又可以缩小库体积的目的。
arsc文件优化
在剔除R文件小节中，大家已经看到了.arsc文件内容格式。在整体优化小节中，已经对.arsc进行了比较大的优化，接下来分析一下其它优化方式。
可以采用混淆来缩减资源文件的名称，以及移除未使用的备用资源等方式来优化.arsc文件。如何移除未使用的备用资源，gradle里面
增加如下配置：
android {
defaultConfig {
...
resConfigs "zh", "zh_CN", "zh_HK", "zh_MO", "zh_TW", "en"
}
}通过该方式，爱奇艺客户端包体积可以缩减100多KB。
避免使用圆角的ImageView
在实际项目内，经常会用到一些带圆角的图片，或者直接就是圆形的图片。圆形的图片，多数用于一些用户的头像之类的显示效果。
而在 Android 下，也有大量的类似 XxxImageView 的开源控件，用于操作 Bitmap 以达到一个圆角图片的效果，例如 Github 上比较火的 RoundedImageView。
它们大部分的原理，是接收到你传递的 Bitmap ，然后再输出一个与原来 Bitmap 等大的新 Bitmap ，在此基础之上，进行圆角的一些处理，这就导致了，实际上会在内存中，多持有一个 Bitmap ，一下一张图片占用的内存就被加倍了。
针对代码优化
剔除R文件
随着项目中资源的增加，会发现生成的dex文件里面R.class文件越来越大。我们知道真正使用资源的地方都是以R.xxx.xxx这种方式访问的，而R.xxx.xx是对应于.arsc文件里面的一个常量值。
参考：
