业精于勤,荒于嬉; 行成于思,毁于随

前言

在Flutter的开发过程中，构建App的时候会遇到一些问题需要对其进行调试，亦或者是需要了解其构建过程需要对其进行调试，主要包括Flutter Tools的调试和Flutter App的调试，Flutter App的调试比较简单，本篇文章着重介绍一下Flutter Tools相关的调试技巧。

前言

Flutter 作为一个跨平台，高性能的移动开发框架，通过Skia绘制引擎对UI进行渲染，可以用于快速地构建iOS和Android应用，对于普通开发者来讲，它基本已经做到开箱即用的程度。到2019.02.26为止，Flutter也已经对外发布了Release 1.2.2版本，并且处于不断迭代的过程中。但是如果你想更深入的学习或者进行定制操作，那么难免会需要对Flutter Engine进行编译，也会遇到一些问题。

前言

手淘的插件化框架Atlas在ART上首次启动的时候，会通过禁用dex2oat来达到插件迅速启动的目的。之后后台进行dex2oat，下次启动如果dex2oat完成了则启用dex2oat，如果没有完成则继续禁用dex2oat。但是这部分代码淘宝并没有开源。且由于Atlas后续持续维护的可能性极低，加上Android 9.0上禁用失败及64位动态库在部分系统上禁用会发生crash，对于核心技术我们必须能掌握在自己手中。此文结合逆向与正向的角度来分析Atlas是通过什么手段达到禁用dex2oat的，以及如何自己实现代码达到禁用的目的。

在buildTools 28.0.0以前，aapt2自带了资源分区，通过–package-id参数指定。但是该分区只支持>0x7f的PP段，而在Android 8.0之前，是不支持>0x7f的PP段资源的，运行时会抛异常。但是当指定了一个<0x7f的PP段资源后，编译资源时却会报错

1

error: invalid package ID 0x15. Must be in the range 0x7f-0xff..

核心思想就是使用UnSafe直接操作内存

个推Push SDK 2.12.5.0初始化函数中会调用boolean com.igexin.push.util.a.b(Context context);函数。

该方法对libgetuiext3.so做了存在性校验，但是插件化后，对应动态库不在原始目录上，校验失败，导致个推不初始化，push功能异常。

之所以会校验失败，是因为插件化后该动态库位于/data/data/packageName/app_plugins/pluginName/pluginVersion/lib/libgetuiext3.so目录下，不在常规目录下

2018 I/O大会上，Google推出了一种名为Android App Bundle的东西，借助Spilt Apk机制来完成动态加载，大家都称Android App Bundle为动态化框架，其实这是错误的，或许可以将其称为一个基于ProtoBuffer格式的序列化和反序列化框架，且它是一个zip包。而且它本身并不支持动态化，只是动态化的一个载体文件，真正实现逻辑并不是它。

如果网络库使用的是OkHttp，那么OkHttp提供了Dns接口，用于自定义dns的实现，一般HttpDNS就可以通过这个接口去实现，但是这种方式有一个巨大的局限性，就是只能拦截到当前使用的OkHttpClient的DNS，无法拦截其他库中的OkHttpClient的DNS解析行为，而且如果使用的不是OkHttp，则一律拦截不到。那么有没有一种方式，可以拦截到整个App的DNS解析而不依赖OkHttp呢？

最近遇到了一个奇葩的问题，有个别用户反馈App上的菊花一直在转消失不掉，当时产生了几个猜想：

1、dns解析出问题了
2、服务端有问题
3、哪里超时了
4、哪里死循环了

一开始以为是偶然，结果短短一天内，有好几个用户反馈有这个问题，所以这绝对不是偶然，一定是有一个条件触发了这个bug。

之前写过两篇providedAar系列的文章，见：

• Android application中使用provided aar并没有那么简单
• 再谈Application ProvidedAar

基本上已经完美的实现了Android Gradle Plugin [1.3.0,3.2.0+)版本com.android.application中使用provided aar的功能，支持代码和资源的引用，同时不将代码和资源编译进去，但是还遗留了最后一个比较头疼的问题，那就是configurate阶段和构建阶段会被警告日志刷屏。