flutter企业站,flutter 中国

Flutter 仿企业微信多选-listview可见item位置

有一个需求，是仿企业照微信的多选（效果大家自己去看）。我想到了两种方案：

思路：我们直接通过listview.builder是没办法自定义SliverChildBuilderDelegate，我们可以通过listview.custom来自定义SliverChildBuilderDelegate，通过自定义我们可以重写didFinishLayout方法，拿到里面缓存的第一个item和最后一个item。可见item的跟缓存item是差5个的，可以间接算出来，后面发现其实不太行，上下滑动之后会显示之前滑动时候的可见位置。 正解是：这个里面还有个estimateMaxScrollOffset方法，正常来说通过它可以获取到可见的第一个和最后一个item位置。但是我一开始使用这个方法，不会被回调，后面不知道修改了什么，就会回调，然后这个位置是准确的。

看下listview.builder的源码

我们可以看到childrenDelegate是直接定义好了的。

在看看listview.custom 的源码

childrenDelegate这个是一个必传参数。

相关问答

Q1: 跨平台技术；H5和Flutter谁是未来？

前言

为什么跨平台是发展趋势？

同一个应用，各个“端”独立开发，不仅开发周期长，而且人员成本高。同时，作为技术人员，也不应该满足于这种重复、低能的工作状态。在这样的形势下，跨平台的技术方案也受到越来越多人和企业的关注。

本篇文章我将从原理、优缺点等方面为大家分享跨平台技术

一. H5

说到跨平台，没人不知道H5。不管是在Mac、Windows、Linux、iOS、Android还是其他平台，只要给一个浏览器，连“月球”上它都能跑。

1.浏览器架构

下面，我们来看看让H5如此横行霸道的浏览器的架构：

浏览器由以上7个部分组成，而“渲染引擎”是性能优化的重中之重，一起了解其中的渲染原理。

2.渲染引擎原理

不同的浏览器内核不同，渲染过程会不太一样，但主要流程还是一致的。

分为下面6步骤：

从以上6步，我们可以总结渲染优化的要点：

以上就是浏览器端的内容。但H5作为跨平台技术的载体，是如何与不同平台的App进行交互的呢？这时候JSBridge就该出场了。

3.JSBridge原理

JSBridge，顾名思义，是JS和Native之间的桥梁，用来进行JS和Native之间的通信。

通信分为以下两个维度：

那么App内加载H5的过程是什么样的呢？

4.App打开H5过程

打开H5分为4个阶段：

这四步，对应的过程如上图所以，我们可以针对性的做性能优化。

5.优缺点分析

下面，我们进行H5的优缺点分析：

优点

缺点

虽然H5目前还存在不足，但随着PWA、WebAssembly等技术的进步，相信H5在未来能够得到越来也好的发展。

二.小程序

2018年是微信小程序飞速发展的一年，19年，各大厂商快速跟进，已经有了很大的影响力。下面，我们以微信小程序为例，分析小程序的技术架构。

小程序跟H5一样，也是基于Webview实现。但它包含View视图层、App Service逻辑层两部分，分别独立运行在各自的WebView线程中。

1.View

可以理解为h5的页面，提供UI渲染。由WAWebview.js来提供底层的功能,具体如下：

每个窗口都有一个独立的WebView进程，因此微信限制不能打开超过5个层级的页面来保障用户体验。

2. App Service

提供逻辑处理、数据请求、接口调用。由WAService.js来提供底层的功能,具体如下：

运行环境：

仅有一个WebView进程

3.View App Service通信

视图层和逻辑层通过系统层的JSBridage进行通信，逻辑层把数据变化通知到视图层，触发视图层页面更新，视图层将触发的事件通知到逻辑层进行业务处理。

4. 优缺点分析

优点

缺点

既然WebView性能不佳，那有没有更好的方案呢？下面我们看看React Native。

三.React Native

RN的理念是在不同平台上编写基于React的代码，实现Learn once, write anywhere。

Virtual DOM在内存中，可以通过不同的渲染引擎生成不同平台下的UI，JS和Native之间通过Bridge通信

1.React Native 工作原理

在 React 框架中，JSX 源码通过 React 框架最终渲染到了浏览器的真实 DOM 中，而在 React Native 框架中，JSX 源码通过 React Native 框架编译后，与Native原生的UI组件进行映射，用原生代替DOM元素来渲染，在UI渲染上非常接近Native App。

2.React Native 与Native平台通信

3.优缺点分析

优点

缺点

4.RN展望

虽然RN还存在不足，但RN新版本已经做了如下改进，并且RN团队也在积极准备大版本重构，能否成为开发者们所信赖的跨平台方案，让我们拭目以待。

既然React Native在渲染方面还摆脱不了原生，那有没有一种方案是直接操控GPU，自制引擎渲染呢，我们终于迎来了Flutter！

四.Flutter

Flutter是Google开发的一套全新的跨平台、开源UI框架，支持iOS、Android系统开发，并且是未来新操作系统Fuchsia的默认开发套件。渲染引擎依靠跨平台的Skia图形库来实现，依赖系统的只有图形绘制相关的接口，可以在最大程度上保证不同平台、不同设备的体验一致性，逻辑处理使用支持AOT的Dart语言，执行效率也比JavaScript高得多。

1.Flutter架构原理

2.Dart优势

很多人会好奇，为什么Flutter要用Dart，而不是用JavaScript开发，这里列下Dart的优势

3.优缺点分析

优点

缺点

Q2: Flutter 与 iOS 原生 webView 对比

本文对比的是 UIWebView、WKWebView、flutter_webview_plugin（在iOS中使用的是WKWebView）的加载速度，内存使用情况。

测试网页打开的速度，只需要获取 WebView 在开始加载网页和网页加载完成时的时间戳，时间戳的差即为打开网页的时间

为了使差异更明显，我们选择较为复杂的 新浪首页 进行加载的对比，为了减小网络对加载速度的影响，我们让手机连接同一个网络，分别进行 10 次测试然后取平均值，另外，我们需要关闭 WebView 的缓存，防止缓存对加载速度产生影响

下面使笔者进行 10 次测试所得到的数据

结果让我有点惊讶，一直以为 WKWebView 会是个王者。结果看，速度上 WKWebView 略慢一点，不过总体差异不大（该结果仅仅是测试新浪的结果，仅供参考啦）

在这里，笔者又加了一个测试，尝试记录从 viewController 的 viewDidLoad 到 webview 的 didFinish 时间，测试了新浪的数据，如下：

UIWebViewA ： 4970、3808、3815、4250、3556 avg(4079.8) （加载完所有页面）

UIWebViewB ： 4103、3124、3070、3256、2835 avg(3277.6)（加载sina完毕）

WKWebView ： 3672、3032、2892、2912、2739 avg(3049.4)

flutter_webView ： 4532、3901、4310、3496、3378 avg(3923.4)

其中可以看到，webView 有两行，UIWebViewB 的数据就是加载 sina 主站的时间；UIWebViewA 的数据是因为在加载完 sina 主站之后，新浪又加载了一个 ，所以导致总时间延长，不过即使按照 UIWebViewB 的数据来比较，也是 wkWebView 略胜一筹。

此处可以看出 flutter_webView 使用的是 wkwebView，所以它吃亏的主要原因是 flutter 包了一层。

结论：

速度（didStart - didFinish） UIWebView flutter_webview WKWebView

速度（viewDidLoad - didFinish）WKWebView UIWebView flutter_webview

这里查看内存使用的是 xcode 的 debug session 中的 memory。

首先看之前测试时，连续打开十次新浪的内存情况

接着我们在看一下打开淘宝首页的内存情况

从图上可以看出，WKWebView 在内存方面有很大的优势啊，UIWebView 的内存是真的伤啊，然后 debug 看了一下 flutter_webView，他使用的就是原生的 webView 。

他相比较原生 WKWebView 的内存开销稍大一点，从测试表现来看，一般大个 30 MB 左右。

结论：内存 WKWebView flutter_webview UIWebView

可以在 html5test 中对浏览器的兼容性进行评分，通过测试发现得分分别如下

因为 flutter 里使用的就是 WK，所以和原生的 WKWebView 一样都是 444 分，比 UIWebView 的 437 略胜一筹

结论：兼容性 WKWebView = flutter_webview UIWebView

UIWebView : 速度相比较 WKWebView 稍快一点，但是内存是一大硬伤，所以只要条件允许，就不推荐使用了

WKWebView : 速度略慢一点，不过差别不大，总体可以接受。是比UIWebView更好的选择，推荐使用。

flutter_webView_plugin ：在iOS中使用的就是原生的WKWebView，所以总体和 native WKWebView 表现差不多。如果是混编项目中，因为它被包了一层，所以页面加载上存在一定的劣势，所以混编项目中仍然推荐使用 WKWebView。不过如果从多端考虑、以及项目可迁移等，那么使用也未尝不可，就是维护成本要增加一些，需要维护两套 webView。这个就需要根据自己的情况自己取舍了。

Q3: flutter常用组件

主要是关注decoration (装饰) 可以设置container的属性，这里color指的是背景色

alertdialog会返回一个结果，这样可以通过switch或其他方法做多次弹框等其他操作

Q4: flutter 慢慢退出了吗？

看点：Flutter 的争议

InfoQ：我们在看到一些比较比较消极的看法，他们认为 Flutter 正在被悄悄放弃，怎么看待这些声音？

宗心：Gartner 将每个技术成熟度曲线都将技术的生命周期划分为五个关键阶段。技术萌芽期：潜在的技术突破即将开始。早期的概念验证报道和媒体关注引发广泛宣传。通常不存在可用的产品，商业可行性未得到证明。期望膨胀期：早期宣传产生了许多成功案例 — 通常也伴随着多次失败。某些公司会采取行动，但大多数不会。泡沫破裂谷底期：随着实验和实施失败，人们的兴趣逐渐减弱。技术创造者被抛弃或失败。只有幸存的提供商改进产品，使早期采用者满意，投资才会继续。稳步爬升复苏期：有关该技术如何使企业受益的更多实例开始具体化，并获得更广泛的认识。技术提供商推出第二代和第三代产品。更多企业投资试验；保守的公司依然很谨慎。生产成熟期：主流采用开始激增。评估提供商生存能力的标准更加明确。该技术的广泛市场适用性和相关性明显得到回报。基于这个理论，Flutter 应该处于期望膨胀和泡沫破裂之间，一方面看好的人还会继续大力宣传和投入解决问题，同时在尝试落地失败后的公司和个人会极力唱衰，因此我们应该回归本质去看，跨平台技术本身有其特定场景下存在的价值，多平台的研发效能收益是真实的公司需求，目前行业的龙头企业都仍然在持续投入和改进中，谈被放弃为之尚早。

所谓原生级别的流畅，但实际很卡，体验差，而且有些跨端项目一开始用 Flutter，结果性能卡脖子，无奈又回到 Android 和 iOS 分开搞的局面嵌套之美，难以欣赏Flutter 是 KPI 项目，负责人升职完了，华丽转身，留下一地烂摊子……

Q5: 移动端的适配问题

什么是px

    像素，相对于显示器屏幕的分辨率。

    特点：固定大小，设置以后就不能因为页面改变而改变。

什么是pt

    物理长度单位 1pt = 1px +1px*1/3

什么是em

    相对长度单位，相对当前对象内文本的字体尺寸。

    特点：em的值并不是固定的，em会继承父级元素的字体大小。

    注意：浏览器默认字体大小16px。谷歌最小12px。

什么是rem

    CSS3新增的一个相对单位（root em）相对于根节点html的字体大小来计算的。默认 1rem = 16px

    特点：值只受到根节点html的字体大小影响，并不受父元素字体大小的影响。

rem适配

写在js的内容

(function(document,window){

    let doc    = document.documentElement,//获取根节点html

    resizeEvent = "orientationchange" in window ?  "orientationchange" :"resize",

    resets      = () ={

        if(doc.clientWidth750){

            doc.style.fontSize = "100px";

            document.getElementById("root").style.width = '750px';

            return

        }

        let fontSizeValue = doc.clientWidth/7.5;

        doc.style.fontSize = fontSizeValue+"px";

        document.getElementById("root").style.width = "auto";

    }

    if(!doc.addEventListener) return ;

    window.addEventListener(resizeEvent,resets,false)

    doc.addEventListener("DOMContentLoaded",resets,false)

})(document,window)

--------------------------------------------我是一条分割线--------------------------------------------

App

  原生开发  ios   

安卓

前端开发app  dclould  apicloud  ---开发完移动端页面之后，进行打包apk文件

前端开发的原生app应用  ------ react-native  flutter  weex ----跨终端应用开发

混合开发 hybird  套壳开发 ------对于前端没什么太大工作  主要还是写移动端页面

h5页面-------webapp -----移动端网站

小程序开发

微信公众号开发

平台---

业务平台

后台管理

pc端的面向客户的网站

企业站

orientationchange 事件

当设备的方向变化（设备横向持或纵向持）此事件被触发。

js

    //判断在window对象中是否有orientationchange属性

    'orientationchange' in window   

DOMContentLoaded 事件

当初始的 HTML 文档被完全加载和解析完成之后（不需要等待图片等其他资源加载完成），DOMContentLoaded 事件被触发。

 load 事件

页面上所有的资源（图片，音频，视频等）被加载以后才会触发load事件，简单来说，页面的load事件会在DOMContentLoaded被触发之后才触发。

window.onload=function(){

}

document.onready