flutter启动速度,flutter启动优化

app是如何制作的，APP如何开发？

手机APP制作流程：无需技术，教你制作一个自己的手机APP

一款手机APP的制作，说复杂非常复杂，涉及到多个领域的研发，稍复杂一点的个人研发基本上搞不定，但是，也有非常简单的手机APP一站式制作运营方法。

随着移动互联网基层开开发技术的发展，无需编程技术，也可以在应用公园制作手机。这里就以应用公园为例，教您熟悉手机APP制作流程，手把手教你制作一款自己心仪的手机APP。

第一步：了解自己想要制作一款怎么的手机APP。是软硬件结合？ 游戏 类？商城类？新闻资讯类？互动类？聊天类？还是团购类、同城服务类？送餐类？企业展示类？

每一个类别的APP开发差异非常大，主要就是不同类型所需要的功能支持。对自己想要做的APP有个大致的了解，但是这一步很多人都没搞清楚，大部分人都存在一个大概模糊的创意、想法阶段。

第二步：了解自己想要做的APP的基础功能，划分板块。

对基础功能的了解、板块的分类，上手最快的方法就是：查看市场上类似的APP进行借鉴。

第三步：界面及交互的设计

界面及交互的设计，可以直接使用“墨刀”。可以先设计一个大概，后期不断丰富。

第四步：APP功能的开发制作

APP功能的开发直接使用应用公园就可以了。应用公园把市场上常见的APP功能进行拆分组合，你不需要懂任何编程技术，只需哟安把需要的功能挑选出，组合搭配一个，就能迅速组建出一个手机APP。

手机APP制作具体流程：

1、打开应用公园的官网，点击“开始制作”，注册登录；

2、应用公园为在线APP制作平台，所以不需要下载任何东西，直接进入制作页面就可以；

3、应用公园目前有两种模式：

（1）主题模式：应用公园平台上，已经很多已经制作完善的手机APP软件，可以直接当做模板使用，仅需要把里面的文字图片进行替换，就可以快速制作一款APP。

（2）自由模式：就像拼图一样，把需要的功能自由组合搭配一下，就可以创造一款独一无二的手机APP。

每一个功能控件的具体功能，都通过后台自动配置。

4、手机APP打包

制作完善后，在应用公园平台直接点击制作完成，就会自动打包成手机安装程序。

5、应用发布上架

在应用公园平台直接申请应用发布，通过联网后，就可以联网使用了。

6、下载管理、运营

应用公园提供运营管理后台、下载站点、下载二维码、手机管理助手等APP相关产品，一站式服务，自动配置，免去多次开发成本，而且后期的功能、内容的更新迭代自己既可以搞定，也不需要具体的编程技术。

自己制作app需要 编程知识 。但依靠第三方工具，三分钟就可以做成专属自己的APP。下面以简易网为例演示：

简网APP工厂三大特点

1、最低的成本：节省所有开发成本，以及仅几分钟的时间成本。

2、实用的功能：贴近传统网站的内容编辑与发布方式。

3、灵活的运营：生成APP后，一个人也可以完美运营。

先来了解一下APP工厂：三分钟制作APP

使用简网APP工厂之前，我曾经通过其他类似的APP公司制作过两三个不同版本的免费APP，简网的操作流程是制作门槛最低的一家。

不支持用户名注册，需要使用微博账号

新浪与腾讯微博用户数几乎覆盖全网网民数，我们默认用户已经拥有微博账号，以便于进行APP快速创建。

填写APP信息：几分钟搞定

制作APP之前我们需要做一些准备工作，比如我们要明确我们要做一个怎样的APP，我们要为这个APP准备一张1024x1024的ICON以及一张114x114的小图标，另外还需要一张640x1136的开机图。

从简网APP工厂的首页，经过3次跳转，省略了网站注册过程，通过模板挑选完成APP美工定案，所需的是APP的图标与应用简介。全过程几分钟足矣。

快捷实用的后台采编系统

我们制作了一个新闻资讯类的APP软件，同时我们拥有了一个功能齐全的后台更新系统。利用后台可以完全解决APP内容更新问题，可以快速进行新闻发布，包括文字、图片、视频、微博等形式，并且引入了完善的评论系统与社区系统。

笔者至今使用过三家大型网站的后台系统，由于种种 历史 原因，这些后台系统都存在或多或少的不合理设计，也许是因为承载的功能过多，数据架构过于复杂，在新入职人员上手操作时，需要经过长时间的熟悉过程。

简网为我们制作的APP提供了统一的后台模板，这个后台的功能亮点在于不仅提供原始录入，还提供也许是目前设计最为合理的网络来源抓取功能。包括网页、微博在内的网络内容，都可以在大约1分钟时间内导入后台中，并且实时呈现在用户手机上的APP客户端。

APP的生成时间约为三分钟，APP容量只有3M，一般的宽带都可以在1分钟之内下载好装进手机

我们得到了一个可安装的APP软件

同时获得了一个功能完善的编辑后台

快速的内容抓取，让后台采编人员的数量可以降到最低，维持一个日更新量在100篇文章左右的APP客户端，一个工作人员足矣。

内容采编神器：发布到应用

“发布到应用”这个功能可以说是管理后台提供的最强大的一个功能，经过简单的设置后，我们可以在几秒钟之内把网络内容发布到我们的APP客户端。

这样一个媒体类APP就做好了。

很高兴回答这个问题。

我是从事安卓App开发的，开发过很多App，那么App是如何制作的。

页面设计

我们看到的app都一个个页面，每个页面功能不同。首先是产品经理通过调研整理需求，然后将需求整理成页面(可以使用墨刀等网页制作)，然后在交给UI人员进行专业设计和美化，最后将设计图打包给开发人员。

开发设计

拿安卓举例，开发使用语言也分几种，具体得根据实际情况来选择。

1.原生开发

安卓一般使用java语言开发，当然现在也有kotlin语言进行开发。如何开发就涉及到具体编程了，这里就不详说了。简单描述就是使用安卓提供的一系列控件来实现页面，复杂点的页面可以通过自定义控件来实现。

2.使用H5语言开发

使用H5开发的好处有很多，可以多端复用，比如浏览器端，ios端，当然H5开发的体验是没有原生好的。结合我做过的项目来说，一般是这个页面需要分享出去的话，就用H5开发。

3.使用flutter开发

flutter是近年来谷歌推出的一款UI框架，

使用dart语言进行开发，支持跨平台，weight渲染直接操作硬件层，体验可媲美原生。但是flutter技术比较新，生态还不完善，开发起来效率相对偏低

页面数据填充

页面开发出来只是空壳子，没有数据填充，这时候就需要通过接口获取数据，然后解析数据，显示在页面上。

到此，一个大概的App制作流程就结束了。

首先你要清楚自己想要什么样的APP,是做哪一方便的?简单的?还是复杂的

一下我就分为两类进行回答

一,简单APP

必要岗位

ui设计师(至少一个)

主要负责APP页面的搭建和交互的梳理

客户端开发人员(至少一个)

目前市面上的APP开发方式多为混合开发,如果做一个简单的APP可以选择webapp,这样不但可以减少开发周期还可以控制开发成本

服务端开发(至少一个)

目前服务器语言很多php,java,

node.js

非必要岗位

首先 ,我说的非必要岗位不是说这些岗位不重要,而是说在为了减少成本的情况下,这样岗位可以被别的岗位所替代

产品经理

如果开发的App功能简单,UI设计师就可以担任这样职责

测试工程师

当然,在时间允许的情况下,开发人员也可以是测试人员

二,复杂APP

复杂app可以考虑纯原生开发,那么客户端至少两个人进行开发(安卓,IOS),或者考虑混合开发,及web前端+原生开发人员

必要岗位

ui设计师,安卓开发工程师,ios开发工程师,后端开发工程师,产品经理,测试工程师,人员的多少可以根据项目的大小来定

三,必要成本

服务器 :这是开发app必须要的,也就是我们放代码的地方

上架审核所需费用 :比如IOS上架审核的花好几百,安卓要申请软著等

今年六月的时候，萌生了开发一个记账 App 的想法，想去用自己的 App 记账，管理收支。那时正好在英国是考试周，放假后，我回到了国内，准备去实现我的计划。没想到这暑假很快就结束了，在这个暑假中经历的太多的事，准备了要去美国读研的考试，遇到了生命中的另一半，同时，也将 Costuary for iPhone 带到了这个世界。

Logo

说道为什么要开发这样一个 App ，因为笔者在 UK 读书，市面上很少有记账 App 能够实现实时汇率的换算，带有这个功能的 App 也是操作繁杂。所以要自己开发一个，功能并没有那么复杂的，并且能够满足自己在国外和国内生活需求的 App，所以自己编写了 iPhone 的客户端，为了获取汇率和 Excel 导出，又用 Java 设计和编写了 Costuary 的后端服务器。

比起今年年初开发的 Flat Weather，这个项目的代码量大约是他的十倍，需要实现众多的功能和模块。

这篇文章将会介绍一下 Costuary 的功能与我开发过程中的一些心得。

效果图设计

说到设计，两年前，我还是一个 Android 开发者，Google 的 Material Design 是我的最爱，所以，Costuary 采用了 Android 5.0 之后采用的 Material Design 设计。其中掺杂了一些我自己的设计，因为 Material Design 的控件有时候操作繁琐。

早在 5 月份的时候已经零零总总的用 Sketch 画出了这个产品的 UI 和图标，之后开始了漫长开发的过程。

Sketch交互

与去年开发的 Android 版不同，iPhone 版的 Costuary 采用了底部导航栏的设计，相比于 Android 通常使用的 Navigation Drawer 的抽屉布局，底部导航栏的设计即使在右手操作 iPhone 的时候都不会太费力。

UX功能 Features

Costuary 支持世界上主要货币的实时汇率转换，所有外汇在统计时会转换成主货币的数目，方便查看花销。

日历视图能够很直观的反映出哪一天有消费和收入。

说到记账软件，量化消费的图表无疑是重要的一环，Costuary 提供了饼状图来视觉化一段时间的花销。

可以建立多个账户来表示自己的银行卡，支付宝，现金等等。

可以看出本月的预算还有多少。

如果想要进行更加详细的分析，可以使用导出功能将账本导出到 Excel。

允许备份账本内容到 iCloud。

开发

去把一纸设计变成真正的产品，这是一个独立开发者应该具有的能力。只会写代码不只是我唯一掌握的，能够去设计出来自己想要的应用并且将他实现才是我在做的事情。

这款应用的开发并没有想象中的简单，需要自己去实现大量 Android UI 控件，很多圆角，阴影，字体，要慢慢的去调整，让控件适合 iPhone 的屏幕。整个应用的背后有 3 个关系型数据库来储存账户，账本与各种汇率。与以前开发的 Flat Weather 不同，Costuary 会产生大量的用户数据，所以整个软件架构的稳定性变得异常重要，需要设计一些机制来防止数据丢失与损坏。

Development

为了实现 App 获取每日的汇率，并且在 iPhone 上能够实现账本导出到 Excel ，我设计了一个服务器后端来处理这些繁杂的实物。每次 App 启动后会与我的服务器来更新最新的汇率。当用户选择导出时，账本会被发送到服务器上并处理为 Excel 发送到用户的邮箱里。

Mail

说到服务器，就不得不提到用户隐私了，因为导出到 Excel 功能需要将账本传到我的服务器上做进一步处理，很多人会觉得我侵犯了他的个人隐私。对此，为了保护我的权益与用户的权益，我撰写了 Costuary 软件许可及服务协议与 Costuary 隐私政策，这是我作为独立开发者这么多年后第一次去写许可协议。

Agreement资费

与我的其他产品一样，这款 App 依旧是免费供大家使用的，作为独立开发者，我们都知道，绝大多数用户不会去珍惜一个免费的产品。就像 Flat Weather 一样，虽然获得了很多人的支持，但是也收到了很多人的吐槽。在 Costuary 中依然设计了一个的捐助按钮，如果大家使用之后喜欢这个应用，请支持我将他维护下去。

Please donate me尾巴

Costuary for iPhone 是我开发出来过最大的软件体系。我相信，能够独立开发出来产品的人懂得不只是编程。一个人要去经历项目的全部生命周期：规划，设计，开发，运营，维护，营销，这些是我开发这么多产品所学会的。

现在的 Costuary 只是第一个版本，还有很多 iPhone 的特性没有来得及开发，以后会跟上的，比如 iPhone X 的适配，3D Touch、Today Widget、Touch ID 等等。

以前在少数派撰稿的时候，很多读者会来问我如何学习开发，我也特地去写过如何去学习编程，但我相信，真正想去学习的，想去为这个生态贡献出自己的一份力的人，自己都会找到学习的方法。我的专业是电子电器而不是软件工程，但是我不后悔当年去学习编程。

最后，还是感谢在背后默默支持我的人，我会不断地改进与提升，如果 Costuary 真的在记账方面给予了你便利，这是我莫大的荣幸。

如果想要了解我的更多作品可以访问我的个人博客 MikeTech，或者在少数派中阅读我以前写过的文章。今年年初也在 iPhone 上写过一个天气 App，天气应用 Flat Weather 的设计历程

对了，关于记账有什么用，如何记账，如何养成记账的习惯。为什么每个月末都捉襟见肘，除了没钱，很可能是对财务管理的能力不强。想了解这一方面的知识，不妨看一看我派的付费阅读栏目：从零开始做好个人记账

你好，非常感谢你的邀请。

开发一个app的话首先

第一步、需要调研，分析开发需求。

第二步、根据你的开发需求整理一个开发方案，选择合理的架构。

第三步、开始研发。

第四步、测试。

第五步、上线试运行。

第六步、查缺补漏后投入使用。

开发一个app的话。有多种选择。可以找一个第三方公司来进行开发。也可以自己招聘开发团队。也可以交给比较信任的程序员朋友来进行开发。第三种方式的话，属于接私活儿，成本较低。 当然前提你得有认识的人。

我也是程序员出身。参与过web网站开发。传统办公开发。H5开发。微信小程序开发。以及安卓开发。有着较丰富的开发经验。自己完全可以胜任一个App，如果你有这方面的事需求的话，也可以私信我。我是山东的。如果方便的话也可以面谈。

App软件开发，从之前的沟通需求、规划设计、程序开发、测试修改、它的发布等。这是一个非常复杂和漫长的过程，一旦进入通信，就需要定期维护和功能变更。它需要大量的专业人员参与，成本自然很高。 所以，随着更新市场的发展和人们福利的提高，现在已经不像传统开发那么困难了。只需要动动鼠标，不需要触碰代码就可以完成制作app部分。

App开发已成为企业发展的重要推动力量

十年巨变！移动互联网已颠覆我们的时代，商业、社交、视频、新闻、工具等领域，移动应用的渗透率已高达95%，在团购 旅游 和零售行业，移动端收入规模已超过PC端，手机APP已成为企业不可或缺的线上阵地。

不用编程就能制作app的在线平台，摆脱了很多复杂的流程，还能减少用户的麻烦，不会制作，而且可以在平台上查看详细的课程，非常贴心的设置！在这里，我想说的是，如果你想制作app的话，可以在平台上查看详细的课程。总的来说，这种方法会大大降低软件开发app的成本，节省时间，让很多人解决了资金短缺和想快速制作app的问题。

app是如何制作的，APP如何开发？

随着智能手机APP软件的吸引力越来越大，越来越多的企业开始开发自己的APP应用。企业要想开发属于自己企业的APP应用，首先要分析自身的情况和市场对产品的需求。

在APP,开发这件事上，企业一定要注意以下几点。

1. 开发APP应用一定要明确以自己为中心，开发APP是否能带来巨大的利润。

2. 要了解目标用户的需求，配置APP吸引用户，提高用户购买应用的意愿。

3. 通过合作再次寻找潜在客户，我相信开发APP的收益远远大于成本。

开发APP苹果系统，必须使用Xcode苹果开发工具，一般采用Objective-C或Swift语言。Objective-C是继承了C语言的C字，可以直接用Objective-C语言进行编程。如果你不懂数据，差别很小。还有一些新的苹果后缀语言，非常有用。

Andro系统的app都是用Java语言开发的，Java语言已经流行了20多年，这个趋势还在持续和延续。如果想要安卓系统的app首先要掌握Java语言，对于说C语言的人来说，学习Java还是很容易的。如果你对自学感兴趣，Java网站上有很多培训课程，还有很多免费培训。视频，不想付费。如果这个绝对是零基础（没学过其他编程语言，比如c语言），如果真的很感兴趣，可以自学，但是速度比较慢。

总结：app开发拥有多种方法，选择最适合自己的方式方法很重要

答案写到这里，我想您应该知道了app的开发途径或者方法是什么。如果您是小企业或者是个体工商户，您可以找人帮忙开发小程序或者自己在一些网站上进行傻瓜式软件开发。正如上文所说，现在有很多的网站支持在线生成APP，常用的功能和接口都已经设置好了，操作起来不是很难。如果您是大企业，业务多访问量比较大，我的建议是您应该聘请专业的软件工程师开发专门的app，避免后期出现的问题没办法及时解决给您的企业带来损失。

不懂的话，找专业的人帮忙，我就是专业的

app即application program。应用程序。目前手机平台是ios和安卓两大平台的天下。本人不才从事安卓开发。简单介绍一下吧你问的这个问题范围太广。ios和安卓开发语言不同。ios使用的是object_c和swift。安卓是基于java。二者都属于面向对象的语言。开发平台安卓基于android studio早期使用的是eclipse+adt。不过已经被淘汰了。那么怎样开发app？首先你需要一个后台程序员写服务器以及搭建数据库。其次你的会ios或是android其中之一那么这就是最简单的配置.现在流行混合开发如果你再会点前端的h5和js就更好了。一般一个软件公司的基本配置是一个前端一个ios一个安卓一个后台。基本就满足你搭建网站和手机应用的需求了。不过你作为老板养这样一个团队很费钱。还不如找外包

软件的生成需要经历以下几个阶段:

1、满足用户需求——建立软件目标，设想产品功能，进行场景化细分说明；进行可行性分析，用户需求收集，用户需求场景描述；场景问题梳理；获取用户行为、想法；场景应用痛点，机会点

2、需求开发与管理——建立用户画像，从软件目标出发，进行问题梳理，场景行为分析，愿景分析，建立体验地图

3、利用Axure绘制软件原型，在用户场景中切入，并组织软件原型实施，在实施过程中进行问卷调查，收集问题，记录用户行为，不断改善软件需求，进行需求评审，进入评审优化

4、技术可行性分析——技术分析，场景分析，功能实现验证，

5、开发计划制定，实施，测试，验证，发布

[img]

相关问答

Q1: 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。这个就需要根据自己的情况自己取舍了。

Q2: flutter加载h5很卡

flutter加载h5很卡的解决方法如下：

一种临时解决方案，在切换动画加载完毕后，再去构造 WebView，这样从用户角度上看，就不会有路由切换动画的卡顿了。class WebViewPage extends StatefulWidget {undefined

final String uri;

WebViewPage({undefined

@required this.uri,

}) : assert(uri != null);

@override

_WebViewPageState createState() = _WebViewPageState();

}

class _WebViewPageState extends State {undefined

WebViewController _controller;

bool _animationCompleted = false;

@override

Widget build(BuildContext context) {undefined

// 主要是下面的代码

var route = ModalRoute.of(context);

if (route != null !_animationCompleted) {undefined

void handler(status) {undefined

if (status == AnimationStatus.completed) {undefined

route.animation.removeStatusListener(handler);

setState(() {undefined

_animationCompleted = true;

});

}

}

route.animation.addStatusListener(handler);

}

return Scaffold(

title: widget.title,

backgroundColor: Colors.white,

body: _animationCompleted

? WebView(

initialUrl: 'about:blank',

onWebViewCreated: (WebViewController webViewController) {undefined

_controller = webViewController;

_loadHtmlFromAssets();

},

)

: Container(),

);

}

_loadHtmlFromAssets() async {undefined

var uri = Uri.dataFromString(

await rootBundle.loadString(widget.uri),

mimeType: 'text/html',

encoding: Encoding.getByName('utf-8'),

).toString();

_controller.loadUrl(uri);

}

}

Fluent是目前国际上比较流行的商用CFD软件包，在美国的市场占有率为60%，凡是和流体、热传递和化学反应等有关的工业均可使用。

它具有丰富的物理模型、先进的数值方法和强大的前后处理功能，在航空航天、汽车设计、石油天然气和涡轮机设计等方面都有着广泛的应用。

FLUENT软件包含基于压力的分离求解器、基于密度的隐式求解器、基于密度的显式求解器，多求解器技术使FLUENT软件可以用来模拟从不可压缩到高超音速范围内的各种复杂流场。

FLUENT软件包含非常丰富、经过工程确认的物理模型，由于采用了多种求解方法和多重网格加速收敛技术，因而FLUENT能达到最佳的收敛速度和求解精度。

灵活的非结构化网格和基于解的自适应网格技术及成熟的物理模型，可以模拟高超音速流场、传热与相变、化学反应与燃烧、多相流、旋转机械、动/变形网格、噪声、材料加工等复杂机理的流动问题。

Q3: Flutter浪潮下的音视频研发探索

文/陈炉军

整理/LiveVideoStack

大家好，我是阿里巴巴闲鱼事业部的陈炉军，本次分享的主题是Flutter浪潮下的音视频研发探索，主要内容是针对闲鱼APP在当下流行的跨平台框架Flutter的大规模实践，介绍其在音视频领域碰到的一些困难以及解决方案。

分享内容主要分为四个方面，首先会对Flutter有一个简单介绍以及选择Flutter作为跨平台框架的原因，其次会介绍Flutter中与音视频关系非常大的外接纹理概念，以及对它做出的一些优化。之后会对闲鱼在音视频实践过程中碰到的一些Flutter问题提出了一些解决方案——TPM音视频框架。最后是闲鱼Flutter多媒体开源组件的介绍。

Flutter

Flutter是一个跨平台框架，以往的做法是将音频、视频和网络这些模块都下沉到C++层或者ARM层，在其上封装成一个音视频的SDK，供UI层的PC、iOS和Android调用。

而Flutter做为一个UI层的跨平台框架，顾名思义就是在UI层也实现了一个跨平台开发。可以预想的是未Flutter发展的好的话，会逐渐变为一个从底层到UI层的一个全链路的跨平台开发，技术人员分别负责SDK和UI层的开发。

在Flutter之前已经有很多跨平台UI解决方案，那为什么选择Flutter呢？

我们主要考虑性能和跨平台的能力。

以往的跨平台方案比如Weex，ReactNative，Cordova等等因为架构的原因无法满足性能要求，尤其是在音视频这种性能要求几乎苛刻的场景。

而诸如Xamarin等，虽然性能可以和原生App一致，但是大部分逻辑还是需要分平台实现。

我们可以看一下，为什么Flutter可以实现高性能：

原生的native组件渲染以IOS为例，苹果的UIKit通过调用平台自己的绘制框架QuaztCore来实现UI的绘制，图形绘制也是调用底层的API,比如OpenGL、Metal等。

而Flutter也是和原生API逻辑一致，也是通过调用底层的绘制框架层SKIA实现UI层。这样相当于Flutter他自己实现了一套UI框架，提供了一种性能超越原生API的跨平台可能性。

但是我们说一个框架最终性能怎样，其实取决于设计者和开发者。至于现在到底是一个什么状况：

在闲鱼的实践中，我们发现在正常的开发没有特意的去优化UI代码的情况下，在一些低端机上，Flutter界面的流畅性是比Native界面要好的。

虽然现在闲鱼某些场景下会有卡顿闪退等情况，但是这是一个新事物发展过程中的必然问题，我们相信未来性能肯定不会成为限制Flutter发展的瓶颈的。

在闲鱼实践Flutter的过程中，混合栈和音视频是其中比较难解决的两个问题，混合栈是指一个APP在Flutter过程中不可能一口气将所有业务全部重写为Flutter，所以这是一个逐步迭代的过程，这期间原生native界面与Flutter界面共存的状态就称之为混合栈。闲鱼在混合栈上也有一些比较好的输出，例如FlutterBoost。

外接纹理

在讲音视频之前需要简要介绍一下外接纹理的概念，我们将它称之为是Flutter和Frame之间的桥梁。

Flutter渲染一帧屏幕数据首先要做的是，GPU发出的VC信号在Flutter的UI线程，通过AOT编译的机器码结合当前Dart Runtime，生成Layer Tree UI树，Layer Tree上每一个叶子节点都代表了当前屏幕上所需要渲染的每一个元素，包含了这些元素渲染所需要的内容。将Layer Tree抛给GPU线程，在GPU线程内调用Skia去完成整个UI的渲染过程。Layer Tree中有PictureLayer和TextureLayer两个比较重要的节点。PictureLayer主要负责屏幕图片的渲染，Flutter内部实现了一套图片解码逻辑，在IO线程将图片读取或者从网络上拉取之后，通过解码能够在IO线程上加载出纹理，交给GPU线程将图片渲染到屏幕上。但是由于音视频场景下系统API太过繁多，业务场景过于复杂。Flutter没有一套逻辑去实现跨平台的音视频组件，所以说Flutter提出了一种让第三方开发者来实现音视频组件的方式，而这些音视频组件的视频渲染出口，就是TextureLayer。

在整个Layer Tree渲染的过程中，TextureLayer的数据纹理需要由外部第三方开发者来指定，可以把视频数据和播放器数据送到TextureLayer里，由Flutter将这些数据渲染出来。

TextureLayer渲染过程：首先判断Layer是否已经初始化，如果没有就创建一个Texture，然后将Texture Attach到一个SufaceTexture上。

这个SufaceTexture是音视频的native代码可以获取到的对象，通过这个对象创建的Suface，我们可以将视频数据、摄像头数据解码放到Suface中，然后Flutter端通过监听SufaceTexture的数据更新就可以顺利把刚才创建的数据更新到它的纹理中，然后再将纹理交给SKIA渲染到屏幕上。

然而我们如果需要用Flutter实现美颜，滤镜，人脸贴图等等功能，就需要将视频数据读取出来，更新到纹理中，再将GPU纹理经过美颜滤镜处理后生成一个处理后的纹理。按Flutter提供的现有能力，必须先将纹理中的数据从GPU读出到CPU中，生成Bitmap后再写入Surface中，这样在Flutter中才能顺利的更新到视频数据，这样做对系统性能的消耗很大。

通过对Flutter渲染过程分析，我们知道Flutter底层需要渲染的数据就是GPU纹理，而我们经过美颜滤镜处理完成以后的结果也是GPU纹理，如果可以将它直接交给Flutter渲染，那就可以避免GPU-CPU-GPU这样的无用循环。这样的方法是可行的，但是需要一个条件，就是OpenGL上下文共享。

OpenGL

在说上下文之前，得提到一个和上线文息息相关的概念：线程。

Flutter引擎启动后会启动四个线程：

第一个线程是UI线程，这是Flutter自己定义的UI线程，主要负责GPU发出的VSync信号时候用当前Dart编译的机器码和当前运行环境创建出Layer Tree。

还有就是IO线程和GPU线程。和大部分OpenGL处理解决方案中一样，Flutter也采取一个线程责资源加载，一部分负责资源渲染这种思路。

两个线程之间纹理共享有两种方式。一种是EGLImage(IOS是 CVOpenGLESTextureCache)。一种是OpenGL Share Context。Flutter通过Share Context来实现纹理共享，将IO线程的Context和GPU线程的Context进行Share，放到同一个Share Group下面，这样两个线程下资源是互相可见可以共享的。

Platform线程是主线程，Flutter中有一个很奇怪的设定，GPU线程和主线程共用一个Context。并且在主线程也有很多OpenGL 操作。

这样的设计会给音视频开发带来很多问题，后面会详细说。

音视频端美颜处理完成的OpenGL纹理能够让Flutter直接使用的条件就是Flutter的上下文需要和平台音视频相关的OpenGL上下文处在一个Share Group下面。

由于Flutter主线程的Context就是GPU的Context，所以在音视频端主线程中有一些OpenGL操作的话，很有可能使Flutter整个OpenGL被破坏掉。所以需要将所有的OpenGL操作都限制在子线程中。

通过上述这两个条件的处理，我们就可以在没有增加GPU消耗的前提下实现美颜和滤镜等等功能。

TPM

在经过demo验证之后，我们将这个方案应用到闲鱼音视频组件中，但改造过程中发现了一些问题。

上图是摄像头采集数据转换为纹理的一段代码，其中有两个操作：首先是切进程，将后面的OpenGL操作都切到cameraQueue中。然后是设置一次上下文。然后这种限制条件或者说是潜规则往往在开发过程中容易被忽略的。而这个条件一旦忽略后果就是出现一些莫名其妙的诡异问题极难排查。因此我们就希望能抽象出一套框架，由框架本身实现线程的切换、上下文和模块生命周期等的管理，开发者接入框架以后只需要安心实现自己的算法，而不需要关心这些潜规则还有其他一些重复的逻辑操作。

在引入Flutter之前闲鱼的音视频架构与大部分音视频逻辑一样采用分层架构：

1：底层是一些独立模块

2：SDK层是对底层模块的封装

3：最上层是UI层。

引入Flutter之后，通过分析各个模块的使用场景，我们可以得出一个假设或者说是抽象：音视频应用在终端上可以归纳为视频帧解码之后视频数据帧在各个模块之间流动的过程，基于这种假设去做Flutter音视频框架的抽象。

咸鱼Flutter多媒体开源组件

整个Flutter音视频框架抽象分为管线和数据的抽象、模块的抽象、线程统一管理和上下文同一管理四部分。

管线，其实就是视频帧流动的管道。数据，音视频中涉及到的数据包括纹理、Bit Map以及时间戳等。结合现有的应用场景我们定义了管线流通数据以Texture为主数据，同时可以选择性的添加Bit Map等作为辅助数据。这样的数据定义方式，避免重复的创建和销毁纹理带来的性能开销以及多线程访问纹理带来的一些问题。也满足一些特殊模块对特殊数据的需求。同时也设计了纹理池来管理管线中的纹理数据。

模块：如果把管线和数据比喻成血管和血液，那框架音视频的场景就可以比喻成器官，我们根据模块所在管线的位置抽象出采集、处理和输出三个基类。这三个基类里实现了刚才说的线程切换，上下文切换，格式转换等等共同逻辑，各个功能模块通过集成自这些基类，可以避免很多重复劳动。

线程：每一个模块初始化的时候，初始化函数就会去线程管理的模块去获取自己的线程，线程管理模块可以决定给初始化函数分配新的线程或者已经分配过其他模块的线程。

这样有三个好处：

一是可以根据需要去决定一个线程可以挂载多少模块，做到线程间的负载均衡。第二，多线程并发式能够保证模块内的OpenGL操作是在当前线程内而不会跑到主线程去，彻底避免Flutter的OpenGL 环境被破坏。第三，多线程并行可以充分利用CPU多核架构，提升处理速度。

从Flutter端修改Flutter引擎将Context取出后，根据Context创建上下文的统一管理模块，每一个模块在初始化的时候会获取它的线程，获取之后会调用上下文管理模块获取自己的上下文。这样可以保证每一个模块的上下文都是与Flutter的上下文进行Share的，每个模块之间资源都是共享可见的，Flutter和音视频native之间也是互相共享可见的。

基于上述框架如果要实现一个简单的场景，比如画面实时预览和滤镜处理功能，

1：需要选择功能模块，功能模块包括摄像头模块、滤镜处理模块和Flutter画面渲染模块，

2：需要配置模块参数，比如采集分辨率、滤镜参数和前后摄像头设置等，

3：在创建视频管线后使用已配置的参数创建模块

4：最后管线搭载模块，开启管线就可以实现这样简单的功能。

上图为整个功能实现的代码和结构图。

结合上述音视频框架，闲鱼实现了Flutter多媒体开源组件。

组要包含四个基本组件分别是：

1：视频图像拍摄组件

2：播放器组件

3：视频图像编辑组件

4：相册选择组件

现在这些组件正在走内部开源流程。预计9月份，相册和播放器会实现开源。

后续展望和规划

1：实现开头所说的从底层SDK到UI的全链路的跨端开发。目前底层框架层和模块层都是各个平台各自实现，反而是Flutter的UI端进行了跨平台的统一，所以后续会将底层也按照音视频常用做法把逻辑下沉到C++层，尽可能的实现全链路跨平台。

2：第二部分内容为开源共建，闲鱼开源的内容不仅包括拍摄、编辑组件，还包括了很多底层模块，希望有开发者在基于Flutter开发音视频应用时可以充分利用闲鱼开源出的音视频模块能力，搭建APP框架，开发者只要去负责实现特殊需求模块就可以，尽可能的减少重复劳动。

Q4: 雅马哈M112和M112T区别？

作者 | Attila Vágó

译者 | 弯月

出品 | CSDN（ID：CSDNnews）

首先，我仍然相信苹果 M1 的芯片在技术上取得了巨大的飞跃，再次站在了创新的最前沿，然而一旦新鲜感消失之后，裂痕就会慢慢显现，我们的看法也会逐渐改变。没有任何一种关系是完美的，包括技术与用户在内。

简单地回顾一下，我购买的是 M1 Pro 的基本型号（ 8GB RAM），这是一次罕见的尝试，我想证明新款 13" M1 Pro 可以取代15" Pro（16GB RAM），从理论上来说完全可以。

软件开发人员应注意的问题

M1Pro 的基本款本身没有任何问题，然而我是最早的一批用户，有一段时间内，我不得不忍受测试版的软件，努力体会“M1 的优化”，最终一切顺利，我并不觉得硬件有任何阻碍。我前后一共使用了 9 个月，其中大约 6 个月 100%在使用苹果的新芯片，并没有觉得有必要再使用英特尔芯片的15" Pro。

话虽如此，我确实遇到了一些问题，而且有些永远没有得到解决。首先，我不得不将 Flutter 开发转移到 VSCode。因此不得不学习 VSCode，但事后看来，虽然我非常喜欢在 Android Studio 中开发 Flutter，但 VSCode 的体验也不逊色。

iOS 模拟器运行良好，而且设备启动速度非常快，8GB 的 RAM 偶尔会呈现不好的体验。根据 iStatistica Pro 仪表板的显示，我推测这些问题的诱因是操作系统在交换区与RAM之间频繁拷贝数据。苹果的 SSD 速度很快，但还是比不上 RAM。有些人可能会说我太挑剔，但是我认为如果你想模拟应用并获得流畅的用户体验，则需要16GB 的 RAM。相比之下，我的15"MacBook Pro 加载了英特尔芯片，拥有 16GB RAM，虽然已经两年多了，但运行该应用没有任何卡顿。我认为这足以说明，如果你想开展更高级的专业软件开发，而不仅仅是普通的 HTML、CSS、JS 网站，则应该选择 16GB RAM。我原本就对此持怀疑态度，毕竟内存是计算机执行能力的关键，而且内存越小，就越受限。

动态图形专业人士应注意的问题

M1芯片刚推出时，主要用于处理图形密集型任务，例如视频、图像编辑或 3D 渲染等。所有人看似都兴致高昂，但我的建议是，大多数应用都不切实际，或者需要专门定制。

M1的性能真的远超英特尔芯片吗？毫无疑问。这是唯一值得注意的方面吗？绝对不是。

最近，我开设了一个 YouTube 频道，专门探讨无障碍环境，而且我的视频都是用苹果的 Motion 制作的。只有部分视频有声音，还有几百个 2D 层，其余的只是简单的图形和效果。你猜怎么着？使用 M1 + 8GB RAM时，整个工程根本无法编辑，机器基本一动不动。你可能以为我开了 4K 的高清画面，但实际上我只是在制作一个 60FPS、1080p 的工程，只使用草稿质量进行预览，就无法正常运行。还想浏览 3 分钟的视频？根本没戏。我只是苹果 Motion 的业余爱好者，所以只能想象专业是的项目会多么复杂。别说 8GB 的 RAM 不行，我怀疑 16GB 也不够！

内存是 M1 的致命弱点

新芯片推出后不久，原本理智的 YouTube 用户开始散布恐慌，讨论的都是关于苹果交换区与 SSD 的寿命问题。这完全没必要，因为实际上，如果电脑的使用不仅限于查看电子邮件、浏览网页和编辑文档，则建议使用 16GB 的芯片。有人认为 8GB 就足够了，但是当你想处理更复杂的任务时，就会遇到麻烦。有人可能记得 M1 是一个 SOC（片上系统），这意味着处理图形和数据的内存是共享的。

苹果和 MacOS 非常擅长用抽象来解除内存的上限，但只能做到一定程度上而已。一旦超过阈值，就会遇到内存不足的问题。

你可能会说，照此说来 8GB RAM 似乎没什么用啊。这款CPU非常强大，但无法提供持续的性能，它的优点是在处理压力较小的任务时，能够提供短暂的爆发，但这基本没什么意义。当然，它可以在1分钟内渲染完一个1分钟的 Motion项目，但问题在于，55秒还是90秒有区别吗？我觉得没有。

苹果 M1 是一台糟糕的机器？

绝对不是。我很高兴自己成为了 M1 最早的一批用户。M1 是一款出色的 CPU，苹果的设计非常正确。仅凭省电这一点，就值得购买。最近，我的一位朋友搬来和我住在一起，她一直在使用我的 M1，而且从第一天开始就爱上了它。即便一整天不充电也没问题，改变了她守着插头过日子的生活。正如她所说：“这台电脑可以一直运行，即便运行一整天也没问题。”这才是真正的苹果风，这才是大多数用户想要的产品，而且对于绝大多数人来说，8GB RAM 的 M1 Pro 就足够了。

不过，Pro 有点过誉了，至少是有争议的。许多购买苹果 Pro 设备的人都是专业人士，而且从事的是娱乐、媒体、软件开发以及内容创建等行业，他们需要的大多数工具都会消耗大量内存。对于我来说，8GB RAM 的 13" M1 Pro 更像是一台 Air Max 而已，只不过电池、触控栏和风扇更大。感觉最近推出的 iPhone 13Pro 比 M1 MacBook 更“专业”。我认为，苹果的产品与命名不太贴切。总的来说，我认为 M1 很不错，只不过不适合“专业人士”……

Q5: Flutter下载jar速度慢

文章转自：

用Android Stduio创建Flutter项目的时候，会出现各种问题，踩了一个又一个，最后编译的时候可能会出现一直显示Running Gradle task 'assembleDebug'然后就不动了，或者会显示Could not resolve io.flutter等问题，归根结底是网络无法访问到Google服务引起的，两种解决方案：

1.具有比较良好的访问谷歌的网络环境

2.修改镜像源为国内的：

找到Flutte SDK目录下的Flutter打包配置文件flutter.gradle

路径为flutter\packages\flutter_tools\gradle\flutter.gradle

第一处配置：

buildscript {

repositories {

//注释

// google()

// jcenter()

//添加

maven { url ' ' }

maven { url ' ' }

maven { url ' ' }

}

dependencies {

classpath 'com.android.tools.build:gradle:3.5.0'

}

}

第二处配置：

class FlutterPlugin implements PluginProject {

//注释

// private static final String MAVEN_REPO = " ";

//添加这行

private static final String MAVEN_REPO = " ";

第三处配置：

void addFlutterDependencies(buildType) {

String flutterBuildMode = buildModeFor(buildType)

if (!supportsBuildMode(flutterBuildMode)) {

return

}

String repository = useLocalEngine()

? project.property('local-engine-repo')

: MAVEN_REPO

最后一处，项目中的配置，修改Flutter项目下的android下的build.gradle：

buildscript {

ext.kotlin_version = '1.3.50'

repositories {

// google()

// jcenter()

maven { url ' ' }

maven { url ' ' }

maven { url ' ' }

}

}

allprojects {

repositories {

// google()

// jcenter()

maven { url ' ' }

maven { url ' ' }

maven { url ' ' }

}

}

修改完成后，再build，就可以正常构建了！！！