flutterboost

拿来主义与实证精神

假装没事ソ 提交于 2021-01-01 07:42:21
由于工作原因,最近经常需要调研业界方案,因为很多很多东西没有必要重复造轮子,如果别人已经把问题解决了,那么直接使用是没啥问题的,这大概就是所谓的拿来主义。 其实纵观历史,尤其是近代,拿来主义其实不少,马克思主义、列宁思想其实都算是拿来主义。但拿一定要拿的清清楚楚,因而才有了毛泽东思想、邓小平主义等等。 我觉得其中有一个很重要,但是没单独提出来的东西,叫实证精神。毛说,实践是检验真理的标准。邓说,实践是检验真理的唯一标准。 实证,其实可以认为是带着目的的实践。实证,对于做技术也很重要。 譬如最近调研了一个宣称可以通过复用engine提升内存效率的库,但是实测之后,发现效果比不复用还差。这是该方案的效果: 多轮测试之后内存达到200多M,而啥也不做也才130多M: 这明显有悖这个库的初衷。于是我就提了一个issue: https://github.com/alibaba/flutter_boost/issues/933 但是,十多天过去了也没得到回复。 我想这个库大概率是不会维护了,因为他的设计导致他很难跟上官方版本的更新,就不再展开讲了。 另外还有一个经历也挺类似,自己有一个诉求就是把某个UI框架的资源动态化,于是调研了一番,发现有一篇文章挺有意思,分析了该UI框架的底层代码是如何获取资源了,于是直接改了那行代码,指向了一个自己的可更新的路径。 由于这种修改我是比较不赞同的

Flutter 混合开发框架模式探索

萝らか妹 提交于 2020-12-03 11:12:20
Flutter 混合开发框架模式探索 由于 Google 官方提供的 Flutter 混合式开发方案过于简单,仅支持打开一个 Flutter View 的能力,而不支持路由间传参、统一的生命周期、路由栈管理等业务开发中必要的能力,因此我们需要借助第三方混合开发框架(如 Flutter Boost、Thrio、QFlutter 等)的整合能力才能将 Flutter 混合开发模式投入与生产环境。本文中,我们来研究一下这类混合开发框架的职能、架构与源码。 1. 核心职能与框架目标 一个合格的混合开发框架至少需要支持到以下能力: 混合路由栈的管理:支持打开任意 Flutter 或 Native 页面。 完善的通知机制:如统一的生命周期,路由相关事件通知机制。 对于以上几点目标,我们以 iOS 为例,来逐步挖掘 Flutter 混合开发模式的最佳实现。 注:因为篇幅问题,本文不探究 Android 的实现,从 iOS 切入只是分析问题的一个角度,因 Android 与 iOS 的实现原理一致,具体实现则大同小异。其次因 Channel 通信层代码实现比较繁杂,此文对于 Channel 通信层的讲解仅停留在使用层面上,具体实现读者可以自行研究。 注:本文的 Flutter Boost 版本为 1.12.13,Thrio 的版本为 0.1.0 2. 从 FlutterViewController

Flutter Could not resolve project :path_provider_macos.

依然范特西╮ 提交于 2020-08-14 18:54:55
解决方案:先clean,再repair ZBMAC-C02VQ1ZYO:dq_flutter weichunsheng$ flutter clean Cleaning Xcode workspace... 2.5s Deleting build... 258ms Deleting .dart_tool... 4ms Deleting .android... 6ms Deleting .ios... 6ms ZBMAC-C02VQ1ZYO:dq_flutter weichunsheng$ flutter pub cache repair Resetting Git repository for flutter_boost 1.9.1+1...    错误信息: * What went wrong: Could not determine the dependencies of task ':path_provider:compileDebugAidl'. > Could not resolve all task dependencies for configuration ':path_provider:debugCompileClasspath'. > Could not resolve project :path_provider_macos. Required by: