Android 启动流程图 (一)

阅读顺序,

先看Binder机制, 接着对照此图看ServiceManager的启动和获取,

先了解基础启动流程, 后面的文章都会再次基础上进行增加, 例如AMS的启动和注册等.

自View实现的，当然也包括我们后面一步一步引出的自定义控件也不例外，所以说这些View应该都具有相同的绘制流程与机制才能显示到屏幕上（因为他们都具备相同的父类View，可能每个控件的具体绘制逻辑有差异，但是主流程都是一样的）。经过总结发现每一个View的绘制过程都必须经历三个最主要的过程，也就是measure、layout和draw。

既然一个View的绘制主要流程是这三步，那一定有一个开始地方呀，就像一个类从main函数执行一样呀。对于View的绘制开始调运地方这里先给出结论，本文后面会反过来分析原因的，先往下看就行。具体结论如下：

整个View树的绘图流程是在ViewRootImpl类的performTraversals()方法（这个方法巨长）开始的，该函数做的执行过程主要是根据之前设置的状态，判断是否重新计算视图大小(measure)、是否重新放置视图的位置(layout)、以及是否重绘 (draw)，

较早版本的编译系统中，错误内容如下：

而在新版编译系统中，则是这样：

这个异常是 Android 应用的方法总数限制造成的。Android 平台的 Java 虚拟机 Dalvik 在执行 DEX 格式的 Java 应用程序时，使用原生类型 short 来索引 DEX 文件中的方法。这意味着单个 DEX 文件可被引用的方法总数被限制为 65536。通常 APK 仅包含一个 classes.dex 文件，因此 Android 应用的方法总数不能超过这个数量。

即使方法数没有超过 65536，能正常编译打包成 apk，在安装的时候，也有可能会提示 INSTALL_FAILED_DEXOPT 而导致安装失败，这个一般就是因为 LinearAlloc 的限制导致的。这个主要是因为 Dexopt 使用 LinearAlloc 来存储应用的方法信息。 Dalvik LinearAlloc 是一个固定大小的缓冲区。在 Android 版本的历史上，LinearAlloc 分别经历了 4M/5M/8M/16M 限制。Android 2.2 和 2.3 的缓冲区只有 5MB，Android 4.x 提高到了 8MB 或 16MB。当方法数量过多导致超出缓冲区大小时，也会造成 Dexopt 崩溃。

要解决这个问题，一般有下面几种方案：

美团的技术团队在文章中写到：

并在 AndroidManifest 中添加以下声明：

下图是 Android 的打包流程示意图：

虽然谷歌的分包方案很简单，但是效果并不是那么好，谷歌本身也枚举了分包方案的 缺点 ：

针对上面的问题，参考网上的一些解决方案，如美团、facebook、微信等，初步使用的解决方法如下：

下面是流程图：

Android Studio 自带的 APK Analyzer，功能齐全，使用方便，使用 Android Studio APK Analyzer ，我们至少能够做到：

开发阶段使用 Android Studio 打开一个项目时，有三种方式使用 APK Analyzer 工具：

首先 dex 方法数和 dex文件有关，我们把源码编译、转化为 dex 文件时，dex 文件中会有一个区域包含了所有源码中定义或引用的方法列表，这个区域中所有方法项的总数就是方法数。之所以要考虑方法数其实是因为 Android 在设计之初只给这个区域定义了两个字节的范围（方法数量不能超过 65535 个），当超过了这个限制就会导致编译不成功，所以我们要关注方法数问题。

查看方法数可以使用命令行，也可以使用 dexcount-gradle-plugin 插件。

开发中减少方法数的实践经验主要有如下一些：

---