入门

工程结构

核心逻辑：如何在最小改动已有IOS或Android工程的前提下运行Flutter。
Flutter理解为一个单独的模块，通过Pod库 [IOS] 或者AAR库 [Android] 的方式，由CocoaPods和Gradle引入主工程。

图1-1

Flutter启动下的Flutter调式与热重载

主要工作：

检查是否需要重新生成flutter_tools.snapshot。
基于pubspec.yaml依赖 [pub packages get] ，并生成插件描述文件.flutter-plugins和pubspec.lock。
基于Flutter配置，生成Generated.xcconfig [IOS] 和local.properties [Android] 。
基于Gradle和Xcodebuild构建应用。
基于ADB和LLDB启动应用。
等待应用中的Flutter启动，寻找Observatory端口，通过Dart Debugger连接以便调试。
寻找到端口后同步Hot Reload依赖的文件，同时透过Daemon监听命令 [用户点击插件按钮] 实现Full Restart或Hot Reload。
解决Navtive启动下的Dart调试和Hot Reload，就可以解决fluttertools造成的编译慢、以及调试环境不稳定的问题。

Native启动下的Flutter调式与热重载逻辑

Native与Flutter联合调试

结合Xcode的Attach to Process可以实现IOS与Flutter联调。

混合工程改造实践

1. 项目背景及问题

在默认情况下，引入Flutter的Native工程无法脱离父目录进行独立构建和运行，因为它会反向依赖于Flutter相关的库和资源。
在拥有了Native工程的情况下，开发者不太可能去创建一个全新的Flutter工程并重写整个项目，因此Flutter工程将包含整个Native工程，产生了一系列问题：

构建打包问题-----引入Flutter后，Native工程因此对其产生了依赖和耦合，从而无法独立构建。
混合编译导致开发效率降低-----向Flutter转型的过程中必然有很多项目使用Native开发，工程结构的改动会使开发过程无法在纯Native环境下进行，适配到Flutter工程结构对纯Native开发来说会降低开发的效率。

2. 制定解决方案

（1）.两种模式

模式	理解	内容
Standalone模式	Native工程处于独立目录环境	纯Native开发或平台打包
Flutter模式	Flutter代码在该模式下进行开发，对开发人员和打包平台来说是透明的	Flutter代码相关库的生成、编译和调试都执行Flutter定义的流程

图1-2 两种工程模式

（2）.厘清依赖
厘清Standalone模式对Flutter的依赖，并将其提取成第三方库、资源或源码文件。
1. App.framework: Dart业务源码相关文件
2. Flutter.framework: Flutter引擎库文件
3. pubs插件目录及用于索引的文件: Flutter下的插件，包括各种系统的插件和自定义的channels [桥接通道]
4. flutter_assets: Flutter依赖的静态资源，如字体和图片等
（3）.依赖引入的策略

依赖	优点	缺点
本地依赖	将Flutter相关内容的改动同步到Standalone模式也比较方便	需要对Flutter原有的构造流程进行稍复杂的改动，并且与后续的Flutter代码合并会有冲突，且Native工程与Flutter的代码、库以及资源等内容还是耦合在本地，不够独立
远程依赖	对Flutter自身的构建流程改动较少，较为彻底的解决了本地耦合的问题	同步的流程变的更加繁琐，Flutter内容的变动需要先同步到远程仓库后再回步到Standalone模式才能生效

图1-3 远程依赖

3. 改造的实现过程

（1）.目录的组织
在Flutter目录下，父工程目录下的IOS和Android的子目录分别包含对应的Native工程。
在代码管理上，子工程可以使用Git的Submodule形式，保证目录间的独立。
（2）.远程依赖的实现
在Standaloene模式下，Flutter的依赖内容都指向远程仓库中的对应文件
在Flutter模式下依赖的方式不变
1. 向Standalone模式同步Flutter的变更
2. 同步的时机：
建议在提测和灰度期间，每次Flutter业务的提交都能够触发同步脚本的执行和App打包
在开发期间，保证每日一次的同步即可

入门