flutter工程化,Flutter工程化

Flutter初始化

新建一个Flutter工程，android模块。

1，只有一个Activity组件，它是Dart层绘制Widget的容器。

2，Application配置FlutterApplication。

应用Application配置io.flutter.app.FlutterApplication类，App首次启动时，初始化。

调用FlutterMain.startInitialization()方法。

initConfig方法，从AndroidManfest.xml配置的applicaion节点获取meta-data数据，初始化以下默认值。

这些值都是使用中用到的name，例如，抽取apk中asset资源时，flutter_assets打包目录，打包产物data名称。

initResources方法， 初始化资源。

在Flutter打包apk的asset目录下，包括fluttter_asset目录/资源项，将资源从apk中抽取，保存在 Context.getDir("flutter", 0) 目录下。

/data/user/0/包名/app_flutter目录。

在目录中创建一个时间戳文件，根据apk版本和包信息记录的lastUpdateTime更新时间，第二次启动时，若apk未更新，不需要再次抽取。

加载so库，libflutter.so，System.loadLibrary()。

主页面继承FlutterActivity，配置启动模式singleTop。

FlutterActivity类在io.flutter.app包， (区别io.flutter.embedding.android包)， 组件生命周期委托给FlutterActivityDelegate类。

组件启动，onCreate方法。

FlutterMain.ensureInitializationComplete方法，确保资源成功抽取完成，创建FlutterView视图(io.flutter.view)，继承SurfaceView类，setContentView方法，设置组件主布局即FlutterView视图。

最后，根据Bundle路径，runBundle()加载运行，

调用FlutterView的runFromBundle方法，入口点在dart的main方法，

通过FlutterNativeView，调用FlutterJNI的native方法。

nativeRunBundleAndSnapshotFromLibrary方法。

任重而道远

相关问答

Q1: Flutter 四种工程类型及Flutter项目类型切换

标准的Flutter App工程，包含标准的Dart层与Native平台层

Flutter平台插件工程，包含Dart层与Native平台层的实现

Flutter纯Dart插件工程，仅包含Dart层的实现，往往定义一些公共Widget

参考资料:

Q2: Flutter工程化之iOS混编集成

在flutter官网上推荐了iOS项目中两种混编方式：

笔者在采用两种集成方式的过程中，因为iOS项目结构设计导致这两种简单的集成方式都有些麻烦，所以在实践中更改和优化了集成方式，使之在笔者的项目中能够更加简单和快速的集成。

问题：在不更改flutter tool中相关脚本的前提下，添加的Script Phase中的脚本相对路径错误，如果只是开发，手动更改下路径就可以了，但是在考虑到CI中不能每次在pod install之后都去更改，所以在开发调试中采用该集成方式，结合flutter attach的方式去调试。

通过编译相关的 xcframework + Cocoapods私有库的集成方式在CI中集成，这样QA的CI不需要配置flutter的相关依赖

根据flutter编译工具的提示： 上面的编译命令是打包flutter工程项目和插件的产物，在实际开发过程中可以发现是否引入了依赖Native的插件会导致贬义编译产物的不同。

根据上面的对比：

第一部分：基础的 Flutter Engine + Flutter App 编译后的产物 Flutter.xcframwork -- Flutter引擎的包 App.xcframework -- 工程项目对应的AOT的编译产物 第二部分：三方插件的注册中心 FlutterPluginRegistrant.xcframework -- 第三方插件的注册中心，其实是Native + iOS通信的集合 第三部分：依赖iOS Native的原生 FMDB . xcframwork path_provider_ios.xcframework sqflite.xcframework -- cached_network_image依赖的原生实现

根据上面的编译产物可以知道Flutter和App是编译后必有的包，后面的两个部分完全是服务于三方插件的，到这可以解答第二个问题：笔者App的混编过程中混编插件失效是因为笔者在NativeApp中重写了Flutter的容器，使用了FlutterEngineGroup动态创建多引擎去对应进入不同的功能模块，混合插件是因为重写过程中没有通过GeneratedPluginRegistrant注册插件，所以需要在Native的Flutter容器中注册插件，使之生效。

在这为什么使用commit的hash作为flutter-libs的依赖，因为pod install的时候会有缓存，除了版本好，commit hash也能保证每次CI编译通过 pod install 来更新flutter-libs依赖产物

完成！！！