pouloghost的专栏

在我近十年的大前端从业经验中，有一半是在和flutter/rn打交道。虽然，flutter和rn官方和社区已经在非常努力的优化、填坑了，但是这两者的坑还是远远高于原生开发。但是，在锁表的大周期下，华为带着鸿蒙来了，给水深火热的客户端开发带来了新的降温神器：乍一看，鸿蒙是带来了更多的开发需求。但时间拉长，在成本的驱使下，大量中小厂的客户端要不然更快的被完整放弃，要不然科技以套壳为本，客户端最终会落到更加边缘的窘境。当然，跨端很可能会是救客户端于水火的最后稻草，或者跨端真的还需要吗？

ffi是一个比一般通信更底层的机制，接近于jni或者jsi。主要用来做dart和c++的interop。 方法定义和绑定 dart call c++ 官方demo是： import 'dart:ffi'; // For FFI import 'dart:io'; // For Platform.isX final DynamicLibrary nativeAddLib = Platform.isAndroid ? DynamicLibrary.open("libnative_add.so")

flutter 是啥就不介绍了。。。这篇主要针对flutter channel，不涉及dart::ffi。主要是dart<->c++<->java的通信。 核心概念 BinaryMessenger：真正的信道，用来传输数据的 MethodCall：传输的数据内容，event和method都被认为是MethodCall MessageCodec：用来序列化/反序列化数据 方法定义和绑定 所有的绑定都是在BinaryMessenger中，由于跨语言，所以实际代码是c++的。注意，只有

现在越来越多的新技术栈出现，时不时要做调研，做评价，慢慢摸到了一些思路。 维度 常见的评价维度其实都集中在技术上，然而作为业务承载的根基，技术栈的评价维度完全不应该只有技术向评价，而且技术向评价根本不是重点。 目前看，应该有三个方向：产品向、技术向和开发向。 产品向 产品同学通常对技术栈本身其实没有特别的要求，但是落到他们的利益上，技术栈需要满足快速迭代这个核心需求。快速迭代主要是，写得快、发版快。所以评价要关注： 动态化，最高需求其实是动态化。就是发板快，细微的改动不需要跟随发板。这个对于强数据驱动公司

最近被安排在公司推广 flutter，搞了几个月算是摸到了一些推广技术的门道。 私以为，一个框架级别的技术想在比较大规模的团队中推广应该是要经过下面几个 milestone：可行性调研，单人开发可用，多人协作可用，防劣化机制建立，开发质效提升。 涉及到的功能点主要有：文件&库管理，分支模型，语言&平台能力补强，基础通用组件，基础业务组件，代码规范，业务结构规范，CI，复杂组件。 具...

我司引入了 flutter 到主 App 中，这个大概是大部分公司的节奏。引入一个新技术，一定要搞定集成问题。 不定制化且切到最新版本的前提下： 在 1.9 版本，flutter build aar 即可。所以如果是 1.9 版本，请关掉这个文章。 用闲鱼的 FBI，应该是一键化的事情。如果用 FBI，请关掉这个文章。 问题 一键将 flutter 工程集成到主工程，且支持远程发布和本地发布。...