贝壳flutter动态化,Flutter动态化

Flutter中Dio动态设置Http代理IP和端口

这问题，一开始就有。因为忙着忙着也没管。后来发现还是很有需要灵活修改代理ip和端口号的。所以得处理一波了。

创新互联公司基于分布式IDC数据中心构建的平台为众多户提供多线BGP机房 四川大带宽租用 成都机柜租用 成都服务器租用。

因为本身做Android出身，就草船借鉴了下Android里的设置点个8下，进入开发者模式的套路。看到这，系不系心如明镜般？哈哈~ 摸着Android过河也是可以的。

解决方案有了：

我们设置了20次，点点点吧，减小误触几率。

这个Http代理填写IP和端口号的页面，可以新开一个，就是两个输入框，点Submit后，重置Dio实例，并把代理设置给HttpClient。

这里需要注意的是，如果你这里重置了client.findProxy，那么一定要重新实例化Dio实例，不然不生效。这一点也可以在源码中得到印证.

^_^，这就搞完了。还挺简单的。但是确实解决了很大的问题，也很灵活。大家自行拿去试试吧。

Keframe 分帧入屏: 处理flutter卡顿，优化流畅度

在掘金上浏览到 Nayuta 开源的贝壳flutter流畅优化组件 Keframe 。在Demo上试用了一番，确有奇效，下面记录一下笔记心得。

借用一下作者的图解：

另外 Keframe 还提供了一个工具类 SizeCacheWidget 用于缓存子节点中，分帧组件嵌套的实际 widget 的尺寸信息。对于列表，在每一个 item 中嵌套 FrameSeparateWidget，并将 ListView 嵌套在 SizeCacheWidget 内即可。

Flutter动态化方案调研

腾讯课堂14M

今日头条3M

闲鱼22M

百度贴吧13M

蚂蚁财富56.8M

百度网盘14M

手机淘宝15M

贝壳找房8M

由粗粒度小组件动态拼装出页面，Native端已经有很多成熟的框架，如天猫的Tangram。

开发语言：iOS、Android

适用场景：快速迭代的活动营销页面

优点：无侵入，更新简单

缺点：提前预埋，扩展性差，灵活性差

以webview作为容器的app，历史悠久，最早到2011年。

开发语言：HTML

适用场景：双端严格一致的银行类app，容器类的支付宝小程序等

优点：动态更新，跨平台

缺点：性能，加载速度

UI用Xml+JS表达，用Native View渲染。

开发语言：Xml+JS

适用场景：双端严格一致的银行类app，容器类的支付宝小程序等

优点：native组件，生态成熟

缺点：三方库crash，性能缺陷

UI用Dart表达，用Dart engine渲染。

Flutter官方不支持动态化。原因是Flutter在 Release 模式下构建的是 AOT 编译产物，在 Debug 模式下构建的是 JIT ，AOT 依赖的 Dart VM 和 JIT 并不一样， JIT Release 并不支持 iOS 设备。可行的方案是：AOT 需要一个编译后的 “Dart VM”。抽离一份 DartVM 独立编译，再以动态库的形式引入项目。

开发语言：Dart

适用场景：iOS、Android、Web、Desktop、Embed

优点：性能最佳

缺点：增大包体积 20MB+

大厂的主流方案。UI用JS表达，用Dart engine渲染。

开发语言：JS、类JS

适用场景：iOS、Android

优点：性能最佳

缺点：需要掌握JS、Dart两个语言和框架

大厂的主流方案。UI用Dart表达，用Dart engineX渲染。

开发语言：Dart

适用场景：iOS、Android

优点：性能最佳

缺点：需要改造Dart engine

1、 美团外卖Flutter动态化实践

2、 携程App 首页动态化探索

3、 Flutter 动态化在最右 App 中的实践

4、 Flutter 动态化热更新的思考与实践

5、 NOW直播Flutter动态搜索列表页实现

6、 Flutter动态化的方案对比及最佳实现-闲鱼

7、 基于JavaScript 的MXFlutter

基于Weex的Flutter项目框架

最近在做的一个项目，项目的前期采用Weex开发。但是随着交互复杂度的增加，Weex一处开发多处多处运行的特征并没有很好的体现，相反很多时候我们还是需要做IOS和Android的适配。如今火热的Flutter相比Weex和Rn来说，给出了更好的跨平台解决方案。所以我们设计了一套基于Weex实现，底层跑在Flutter Engine上的框架。

底层的Runtime采用isolate engine,框架业务逻辑，Dom的解析逻辑和Render逻辑都跑在这里。

渲染引擎采用Flutter的Skia，彻底剥离了Android和IOS的差异性.

将Weex VirsualDom的解析都替换成Flutter Widget.

设计基于Weex2Dart的Brider,使JS和Dart可以相互调用

weex-demo的性能展示

release环境下采用AOT模式，性能会有质的飞跃。

Android-Release版本只有10m大小

相比Weex和Rn具有更好的性能，同时具有更好的跨平台性

相比Flutter，具有动态部署的能力（Flutter Release采用AoT模式并没有动态部署的能力，即使Debug版本也只是开发环境下才有动态化能力并没有可以实施项目的能力）

只需要会Weex开发或则Rn开发就可以，不需要额外学习Dart，已有的Weex项目可以无缝切换。

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依赖产物

完成！！！