工程结构
-
核心逻辑：如何在最小改动已有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打包
在开发期间，保证每日一次的同步即可
网友评论