本文，我将解析怎么前构建一个用户交互的登录页面。这里，我使用 TextField 挂件，这方便用户输入用户名和密码。还使用 FlatButton 挂件，来处理一些动作。当然，我还使用了 Image 挂件来设定登录页面的 logo。

效果图如下：

第一步： main() 函数

import 'package:flutter/material.dart';void main() {

  runApp(MyApp());

}class MyApp extends StatelessWidget {

  @override

  Widget build(BuildContext context) {

    return MaterialApp(

      debugShowCheckedModeBanner: false,

      home: LoginDemo(),

    );

  }

}

这个 main() 函数也就是应用的入口。MyApp 类中添加了一个 LoginDemo 类作为 home 属性的参数。

第二步：class LoginDemo

• 设定脚手架的 appBar 属性来作为应用的标题，如下：

appBar: AppBar(

  title: Text('Login Page'),

),

• 在本次的 UI 布局中，所有的挂件都会放在 Column 挂件中，然后存放在脚手架的 body 中。Column 中的第一个是存放 Container 挂件，用来处理 Image 挂件。

Container(

  height: 150.0,

  width: 190.0,

  padding: EdgeInsets.only(top: 40),

  decoration: BoxDecoration(

    borderRadius: BorderRadius.circular(200),

  ),

  child: Center(

    child: Image.asset('asset/images/flutter-logo.png'),

  ),

),

flutter-logo.png 文件存放在 asset/images 文件夹中。我们需要在 pubspec.yaml 文件中配置路径。

# To add assets to your application, add an assets section, like this:

assets:

  - asset/images/

添加完资源之后，我们可以运行应用了。

• 然后，使用 TextField 挂件处理用户名和密码。 TextField 挂件是一个输入挂件，帮助我们处理用户的输入信息。

Padding(

  padding: EdgeInsets.all(10),

  child: TextField(

    decoration: InputDecoration(

      border: OutlineInputBorder(),

      labelText: 'User Name',

      hintText: 'Enter valid mail id as abc@gmail.com'

    ),

  ),

),

Padding(

  padding: EdgeInsets.all(10),

  child: TextField(

    obscureText: true,

    decoration: InputDecoration(

      border: OutlineInputBorder(),

      labelText: 'Password',

      hintText: 'Enter your secure password'

    ),

  ),

),

这里的 Padding 挂件能够帮助你设定 TextField 挂件的内边距。

obscureText 属性值为 true 的时候，帮助我们对 TextField 展示特殊的字符，而不是真正的文本。

• 我们使用 FlatButton 挂件来处理忘记密码

FlatButton(

  onPressed: (){

    //TODO FORGOT PASSWORD SCREEN GOES HERE

  },

  child: Text(

    'Forgot Password',

    style: TextStyle(color: Colors.blue, fontSize: 15),

  ),

),

onPressed() 这个函数中，我们可以处理页面跳转或者其他的点击逻辑。

• 对于登录按钮，我们使用 FlatButton 挂件，但是我们得装饰一下，这里我们使用 Container 进行包裹。

Container(

  height: 50,

  width: 250,

  decoration: BoxDecoration(

    color: Colors.*blue*, borderRadius: BorderRadius.circular(20),

  ),

  child: FlatButton(

    onPressed: () {

      Navigator.push(

        context,

        MaterialPageRoute(builder: (_) => HomePage()),

      );

    },

    child: Text(

      'Login',

      style: TextStyle(color: Colors.*white*, fontSize: 25),

    ),

  ),

),

上面我们设定了 Container 挂件的 height 和 width 属性，所以 flatbutton 也会获取到相同的高度和宽度。

decoration 属性允许我们设计按钮，比如颜色 colorColors.blue 和 borderRadiusBorderRadius.circular(20) 属性。

• 最后指定 Text 挂件以为新用户创建账号

这里我们可以通过 GestureDetector 挂件的 onTap() 功能进行导航操作。或者创建类似忘记密码按钮的 onPressed() 事件。

这里是整个项目的完整代码：

// lib/HomePage.dart



import 'package:flutter/material.dart';



class HomePage extends StatefulWidget {

  @override

  _HomePageState createState() => _HomePageState();

}



class _HomePageState extends State<HomePage> {

  @override

  Widget build(BuildContext context) {

    return Scaffold(

      appBar: AppBar(

        title: Text('Home Page'),

      ),

      body: Center(

        child: Container(

          height: 80,

          width: 150,

          decoration: BoxDecoration(

              color: Colors.blue, borderRadius: BorderRadius.circular(10)),

          child: FlatButton(

            onPressed: () {

              Navigator.pop(context);

            },

            child: Text(

              'Welcome',

              style: TextStyle(color: Colors.white, fontSize: 25),

            ),

          ),

        ),

      ),

    );

  }

}

// lib/main.dart

import 'package:flutter/material.dart';



import 'HomePage.dart';



void main() {

  runApp(MyApp());

}



class MyApp extends StatelessWidget {

  @override

  Widget build(BuildContext context) {

    return MaterialApp(

      debugShowCheckedModeBanner: false,

      home: LoginDemo(),

    );

  }

}



class LoginDemo extends StatefulWidget {

  @override

  _LoginDemoState createState() => _LoginDemoState();

}



class _LoginDemoState extends State<LoginDemo> {

  @override

  Widget build(BuildContext context) {

    return Scaffold(

      backgroundColor: Colors.white,

      appBar: AppBar(

        title: Text("Login Page"),

      ),

      body: SingleChildScrollView(

        child: Column(

          children: <Widget>[

            Padding(

              padding: const EdgeInsets.only(top: 60.0),

              child: Center(

                child: Container(

                    width: 200,

                    height: 150,

                    /*decoration: BoxDecoration(

                        color: Colors.red,

                        borderRadius: BorderRadius.circular(50.0)),*/

                    child: Image.asset('asset/images/flutter-logo.png')),

              ),

            ),

            Padding(

              //padding: const EdgeInsets.only(left:15.0,right: 15.0,top:0,bottom: 0),

              padding: EdgeInsets.symmetric(horizontal: 15),

              child: TextField(

                decoration: InputDecoration(

                    border: OutlineInputBorder(),

                    labelText: 'Email',

                    hintText: 'Enter valid email id as abc@gmail.com'),

              ),

            ),

            Padding(

              padding: const EdgeInsets.only(

                  left: 15.0, right: 15.0, top: 15, bottom: 0),

              //padding: EdgeInsets.symmetric(horizontal: 15),

              child: TextField(



                obscureText: true,

                decoration: InputDecoration(

                    border: OutlineInputBorder(),

                    labelText: 'Password',

                    hintText: 'Enter secure password'),

              ),

            ),

            FlatButton(

              onPressed: (){

                //TODO FORGOT PASSWORD SCREEN GOES HERE

              },

              child: Text(

                'Forgot Password',

                style: TextStyle(color: Colors.blue, fontSize: 15),

              ),

            ),

            Container(

              height: 50,

              width: 250,

              decoration: BoxDecoration(

                  color: Colors.blue, borderRadius: BorderRadius.circular(20)),

              child: FlatButton(

                onPressed: () {

                  Navigator.push(

                      context, MaterialPageRoute(builder: (_) => HomePage()));

                },

                child: Text(

                  'Login',

                  style: TextStyle(color: Colors.white, fontSize: 25),

                ),

              ),

            ),

            SizedBox(

              height: 130,

            ),

            Text('New User? Create Account')

          ],

        ),

      ),

    );

  }

}

本文采用意译的方式翻译。原文 levelup.gitconnected.com/login-page-…

推荐阅读

抛出问题

className大家都用过吧，用它在react项目中设置样式。它的用法很简单，除了可以设置一个样式外，react中也可以使用className引入多个类样式。

这次在写项目的时候，碰到一个非常小但是当时却一直解决不了的问题。后面在复盘的时候将它解决了。问题大致是这样的：

有两个活动页，每个活动页上都有一个活动规则图标来弹出活动规则，活动规则图标距离顶部会有一个值。现在问题就是这个活动规则在这两个活动页距离顶部的这个值是不一样的，但是我已经将这个活动规则图标做成了组件，并在这两个活动页里都调用了它，从而导致两个页面的样式会相同。如下图所示：

解决问题

这个问题不算很大，但是属于细节问题。就和我的组长所说的一样，一个项目应该要做到先完成再完美。所以我当时的解决方法是再写一个活动规则组件，只是将距离顶部的值做出修改即可。效果确实是达到了，不过在最后复盘代码的时候，组长注意到了这两个组件，并开始询问我为什么这样做。

组长：Rule_1和Rule_2这两个组件是什么意思，我看它们没有很大的区别呀。

我便简单说了一下缘由。

组长接着说：你忘了组件是什么吗？一个CSS样式值不同就大费周章地新增一个组件，这岂不是太浪费了。再去想想其他方案。

通过这一番谈话我想起了组件化思想的运用，发现之前解决的这个小问题解决的并不够好。于是，我就带着组件化思想又来重新完善它。

我重新写了一个demo代码，将主要内容和问题在demo代码中体现出来。下面是原版活动规则组件demo代码，之后的代码都是基于demo代码完成的

import React from "react";

import "./index.css";

const Header = ({ onClick }) => {

  return (

    <>

      <div className="container_hd">

        <div

          className='affix'

          onClick={onClick}

        ></div>

      </div>

    </>

  );

};

export default Header;

组件化思想

我自己问自己：既然已经写好了一个活动规则组件，为什么仅仅因为一个样式值的不同而去新增一个功能一样的组件？很显然，这种方法是最笨的方案。既然是组件，那就应该要有复用性，或者说只需在原有的基础上稍加改动就可达到效果。

这是样式的问题，因此要从根本上解决问题。单纯地修改 CSS 样式肯定不行，因为两个页面两个不同的样式。

className 运用

className 就不用多介绍了，经常能使用，咱们直接来看如何解决问题。在这里我定义了一个 Value 值，用来区分是在哪个页面的，比如分别有提交页和成功页，我在成功页设置一个 Value 值，，然后将 Value 值传入到活动规则组件，那么在活动规则组件里只需要判断 Value 值是否等于成功页的 Value 值即可。在 className 处做一个三元判断，如下所示：

className={`affix_${Value === "0" ? "main" : "submit"}`}

相当于如果Value等于0的时候类名为affix_main，否则为affix_submit。最后再css将样式完善即可。完整代码可以参考如下：

• 成功页组件

import Header from "./components/Header";



const Success = () => {

  const Value = "0";

  return (

    <div style={{ backgroundColor: "purple", width: "375px", height: "670px" }}>

      <Header Value={Value}></Header>

    </div>

  );

};



export default Success;

• 活动规则组件

import React from "react";

import "./index.css";

const Header = ({ onClick, Value }) => {

  return (

    <>

      <div className="container_hd">

        <div

          className={`affix_${Value === "0" ? "main" : "submit"}`}

          onClick={onClick}

        ></div>

      </div>

    </>

  );

};

export default Header;

• 活动规则组件样式

.container_hd {

  width: 100%;

}

.affix_main {

  position: absolute;

  top: 32px;

  right: -21px;

  z-index: 9;

  width: 84px;

  height: 26px;

  background: url('./assets/rule.png');

  background-size: contain;

  background-repeat: no-repeat;

}

.affix_submit {

  position: absolute;

  top: 12px;

  right: -21px;

  z-index: 9;

  width: 84px;

  height: 26px;

  background: url('./assets/rule.png');

  background-size: contain;

  background-repeat: no-repeat;

}

通过对比效果图可以看出，两者的效果确实发生变化。完成之后，我心里在想：为什么当时就没想出这个简单易行的方案呢？动态判断并设置类名，至少比最开始的新增一个组件的方法高级多了。

总结问题

对于这个问题的解决就这样告一段落了，虽然看起来比较简单（一个动态设置类名），但是通过这个className的灵活使用，让我对className的用法有了更进一步的掌握，也不得不感叹组件化思想的广泛运用，这里最大程度地将组件化思想通过className 发挥出来。

因此，希望通过这个问题，来学会className的灵活用法，并理解好组件化思想。当然如果大家还有更好的解决方案的话，欢迎在评论区告诉我。

大家好，我卡颂。

当一个React应用逻辑变得复杂后，组件render花费的时间会显著增长。如果从组件render到视图渲染期间消耗的时间过长，用户就会感知到页面卡顿。

为了解决这个问题，有两个方法：

1. 让组件render的过程从同步变为异步，这样render过程页面不会卡死。这就是并发更新的原理

2. 减少需要render的组件数量，这就是常说的React性能优化

通常，对于不同类型组件，我们会采取以上不同的方法。比如，对于下面这样的有耗时逻辑的输入框，方法1更合适（因为并发更新能减少输入时的卡顿）：

function ExpensiveInput({onChange, value}) {

  // 耗时的操作

  const cur = performance.now();

  while (performance.now() - cur < 20) {}



  return <input onChange={onChange} value={value}/>;

}

那么，能不能在整个应用层面同时兼顾这2种方式呢？答案是 —— 不太行。

这是因为，对于复杂应用，并发更新与性能优化通常是相悖的。就是本文要聊的 —— 并发悖论。

欢迎加入人类高质量前端交流群，带飞

从性能优化聊起

对于一个组件，如果希望他非必要时不render，需要达到的基本条件是：props的引用不变。

比如，下面代码中Child组件依赖fn props，由于fn是内联形式，所以每次App组件render时引用都会变，不利于Child性能优化：

function App() {

  return <Child fn={() => {/* xxx */}}/>

}

为了Child性能优化，可以将fn抽离出来：

const fn = () => {/* xxx */}



function App() {

  return <Child fn={fn}/>

}

当fn依赖某些props或者state时，我们需要使用useCallback：

function App({a}) {

  const fn = useCallback(() => a + 1, [a]);

  return <Child fn={fn}/>

}

类似的，其他类型变量需要用到useMemo。

也就是说，当涉及到性能优化时，React的代码逻辑会变得复杂（需要考虑引用变化问题）。

当应用进一步复杂，会面临更多问题，比如：

• 复杂的useEffect逻辑

• 状态如何共享

这些问题会与性能优化问题互相叠加，最终导致应用不仅逻辑复杂，性能也欠佳。

性能优化的解决之道

好在，这些问题有个共同的解决方法 —— 状态管理。

上文我们聊到，对于性能优化，关键的问题是 —— 保持props引用不变。

在原生React中，如果a依赖b，b依赖c。那么，当a变化后，我们需要通过各种方法（比如useCallback、useMemo）保持b、c引用的稳定。

做这件事情本身（保持引用不变）对开发者来说就是额外的心智负担。那么，状态管理是如何解决这个问题的呢？

答案是：状态管理库自己管理所有原始状态以及派生状态。

比如：

• 在Recoil中，基础状态类型被称为Atom，其他派生状态都是基于Atom组合而来

• 在Zustand中，基础状态都是create方法创建的实例

• 在Redux中，维护了一个全局状态，对于需要用到的状态通过selector从中摘出来

这些状态管理方案都会自己维护所有的基础状态与派生状态。当开发者从状态管理库中引入状态时，就能最大限度保持props引用不变。

比如，下例用Zustand改造上面的代码。由于状态a和依赖a的fn都是由Zustand管理，所以fn的引用始终不变：

const useStore = create(set => ({

  a: 0,

  fn: () => set(state => ({ a: state.a + 1 })),

}))





function App() {

  const fn = useStore(state => state.fn)

  return <Child fn={fn}/>

}

并发更新的问题

现在我们知道，性能优化的通用解决途径是 —— 通过状态管理库，维护一套逻辑自洽的外部状态（这里的外部是区别于React自身的状态），保持引用不变。

但是，这套外部状态最终一定会转化为React的内部状态（再通过内部状态的变化驱动视图更新），所以就存在状态同步时机的问题。即：什么时候将外部状态与内部状态同步？

在并发更新之前的React中，这并不是个问题。因为更新是同步、不会被打断的。所以对于同一个外部状态，在整个更新过程中都能保持不变。

比如，在如下代码中，由于List组件的render过程不会打断，所以list在遍历过程中是稳定的：

function List() {

  const list = useStore(state => state.list)

  return (

    <ul>

      {list.map(item => <Item key={item.id} data={item}/>}

    </ul>

  )

}

但是，对于开启并发更新的React，更新流程可能中断，不同的Item组件可能是在中断前后不同的宏任务中render，传递给他们的data props可能并不相同。这就导致同一次更新，同一个状态（例子中的list）前后不一致的情况。

这种情况被称为tearing（视图撕裂）。

可以发现，造成tearing的原因是 —— 外部状态（状态管理库维护的状态）与React内部状态的同步时机出问题。

这个问题在当前React中是很难解决的。退而求其次，为了让这些状态库能够正常使用，React专门出了个hook —— useSyncExternalStore。用于将状态管理库触发的更新都以同步的方式执行，这样就不会有同步时机的问题。

既然是以同步的方式执行，那肯定没法并发更新啦～～～

总结

实际上，凡是涉及到自己维护了一个外部状态的库（比如动画库），都涉及到状态同步的问题，很有可能无法兼容并发更新。

所以，你会更倾向下面哪种选择呢：

1. 不care并发更新，以前React怎么用，现在就怎么用

2. 根据项目情况，平衡并发更新与性能优化的诉求

大家好，我卡颂。

虽然React官网用大量篇幅介绍最佳实践，但因JSX语法的灵活性，所以总是会出现奇奇怪怪的React写法。

本文介绍2种奇怪（但在某些场景下有意义）的React写法。也欢迎大家在评论区讨论你遇到过的奇怪写法。

欢迎加入人类高质量前端交流群，带飞

ref的奇怪用法

这是一段初看让人很困惑的代码：

function App() {

  const [dom, setDOM] = useState(null);

 

  return <div ref={setDOM}></div>;

}

让我们来分析下它的作用。

首先，ref有两种形式（曾经有3种）：

1. 形如{current: T}的数据结构

2. 回调函数形式，会在ref更新、销毁时触发

例子中的setDOM是useState的dispatch方法，也有两种调用形式：

1. 直接传递更新后的值，比如setDOM(xxx)

2. 传递更新状态的方法，比如setDOM(oldDOM => return /* 一些处理逻辑 */)

在例子中，虽然反常，但ref的第二种形式和dispatch的第二种形式确实是契合的。

也就是说，在例子中传递给ref的setDOM方法，会在div对应DOM更新、销毁时执行，那么dom状态中保存的就是div对应DOM的最新值。

这么做一定程度上实现了感知DOM的实时变化，这是单纯使用ref无法具有的能力。

useMemo的奇怪用法

通常我们认为useMemo用来缓存变量props，useCallback用来缓存函数props。

但在实际项目中，如果想通过缓存props的方式达到子组件性能优化的目的，需要同时保证：

• 所有传给子组件的props的引用都不变（比如通过useMemo）

• 子组件使用React.memo

类似这样：

function App({todos, tab}) {

    const visibleTodos = useMemo(

      () => filterTodos(todos, tab),

    [todos, tab]);

    

    return <Todo data={visibleTodos}/>;

}



// 为了达到Todo性能优化的目的

const Todo = React.memo(({data}) => {

  // ...省略逻辑

})

既然useMemo可以缓存变量，为什么不直接缓存组件的返回值呢？类似这样：

function App({todos, tab}) {

  const visibleTodos = useMemo(

      () => filterTodos(todos, tab),

  [todos, tab]);

  

  return useMemo(() => <Todo data={visibleTodos}/>, [visibleTodos])

}



function Todo({data}) {

  return <p>{data}</p>;

}

如此，需要性能优化的子组件不再需要手动包裹React.memo，只有当useMemo依赖变化后子组件才会重新render。

总结

除了这两种奇怪的写法外，你还遇到哪些奇怪的React写法呢？

跨平台混合应用(及替代方案)取代了性能优先的原生应用

纯粹的原生应用通常是一种依赖于平台的GUI程序, 它使用特定操作系统的本地开发语言和GUI框架. 例如, Gedit 是一个原生应用, 因为它使用 C 和 GTK 作为实现依赖. Notepad++ 是一个原生应用, 因为它使用 C/C++ 和 Win32 GUI API. 这些原生应用还保留了操作系统特有的UI/UX原则和本地功能. 因此, 电脑用户可以轻松上手并与其他内置原生应用一起使用这些应用. 这些传统的原生应用即使在低端硬件上也能流畅运行, 因为它们没有使用中间消息传递模块或嵌入式渲染/代码执行引擎--它们只是触发内置SDK功能的二进制文件. 原生桌面应用和移动应用开发的情况都是一样的.

混合应用开发运动结束了原生应用开发的黄金时代, 但却创造了一种新的方式, 可以在创纪录的时间内构建类似原生的跨平台应用. 此外, 混合应用的性能问题导致了另一种使用自定义渲染表面和代码执行环境的类原生应用的发展.

让我们来谈谈传统原生应用开发的弊端.

Why Native Apps Are the Best 为什么原生应用是最好的

每个操作系统通常都预装了通用的GUI软件程序. 例如, Ubuntu提供了原生终端, 文本编辑器, Settings应用, 文件管理器等. 这些内置应用无疑遵循了相同的UI/UX原则, 而且由于出色的软件设计和原生SDK的使用, 占用的磁盘空间, 内存和CPU处理能力更低. 第三方原生应用的工作原理也与内置操作系统应用相同. 它们不会过度使用系统资源, 而是根据为用户提供的功能公平地使用计算能力.

从所有面向用户的角度来看, 原生应用都非常出色. 它们绝不会拖慢低端电脑的运行速度. 此外, 它们也不会敦促用户改变操作系统特有的UI/UX做法. 看看Remmina RDP(原生GUI程序)与Ubuntu内置终端的对比:

 Remmina和Ubuntu上的终端

每个移动操作系统都提供了原生SDK, 用于开发特定平台的应用捆绑包. 例如, 您可以使用Android SDK构建高性能, 轻量级和用户友好的移动应用. 看看著名的VLC媒体播放器的Android版本是如何通过XML布局实现"关于"视图的:

 VLC Android项目实现了原生应用视图.

混合应用: 类似本地的Web应用

即使原生应用为用户提供了最好的GUI程序, 为什么现代开发人员还是开始开发混合应用呢? 从应用用户的角度来看, 原生应用是非常好的, 但它们却给应用开发人员带来了一个关键问题. 尽管一些操作系统提供了与POSIX标准类似的底层应用接口, 但大多数内置的应用开发SDK都提供了不同编程语言的不同应用接口. 因此, 应用开发人员不得不为一个软件产品维护多个与平台相关的代码库. 这种情况增加了跨平台原生应用的开发难度, 因为一个新功能需要多个特定平台的实现.

混合应用开发通过提供统一的SDK和语言来为多个平台开发应用, 从而解决了这一问题. 开发人员开始使用Electron, NW.js, Apache Cordova和类似Ionic的框架, 利用Web技术构建跨平台应用. 这些框架在Web浏览器组件内呈现基于HTML的类原生应用GUI, 并通过本地-JavaScript接口和桥接器调用基于JavaScript封装的特定平台本地API. 看看Skype如何在Ubuntu上用HTML呈现类似本地的屏幕:

 Skype的首选项窗口.

桌面应用配有Web浏览器和Node.js运行模块. 移动应用则使用现有的特定平台浏览器视图(即Android Webview).

混合应用解决方案解决了开发人员的问题, 却给用户带来了新的麻烦. 由于基于Web的解析和渲染, 混合应用的运行速度比原生应用慢数百倍. 一个简单的跨平台计算器应用可能会占用数百兆字节的存储空间. 运行多个跨平台应用窗口就像运行多个重型Web浏览器. 不幸的是, 大多数用户甚至感觉不到这些问题, 因为他们使用的是功能强大的现代硬件组件.

混合替代方案的兴起

一些开发人员仍然非常关注应用的性能--他们需要应用在低端机器上也能使用. 因此, 他们开始开发更接近原生应用的跨平台应用, 而不使用Web视图驱动方法. 开发人员开始使用Flutter和类似React Native的框架. 与基于网页视图的方法相比, 这些框架为跨平台应用开发提供了更好的解决方案, 但它们无法像真正的原生应用那样进行开发.

Flutter没有使用原生的, 特定平台的UI/UX原则. React Native在每个应用中嵌入了JavaScript引擎, 性能不如原生应用. 与基于网页视图的方法相比, 这些混合替代方案无疑提供了更好的跨平台开发解决方案, 但在应用大小和性能方面仍无法与真正的原生应用相媲美.

你可以从以下报道中了解Flutter如何与混合应用开发(Electron)竞争:

拜拜Electron, 你好Flutter

混合(和替代方案)赢得了软件市场!

每个商业实体都试图通过开发网站和Web应用进入互联网. 与独立的应用相比, 计算机用户更愿意使用在线服务. 因此, Web浏览器开始改进, 增加了各种以开发者为中心的功能, 如新的Web API, 可访问性支持, 离线支持等. 对开发人员友好的JavaScript鼓励每个开发人员在任何情况下都使用它.

借助混合应用开发技术, 开发人员可以在最短时间内将现有的Web应用转化为桌面应用(如WhatsApp, Slack 等). 他们将React, Vue和Svelte应用与本地窗口框架封装在一起, 创建了功能齐全的跨平台桌面应用. 这种方法节省了数千开发人员的工时和开发成本. 因此, Electron成为了现代桌面应用的开发解决方案. 然后, 一个只需几兆内存和存储空间的代码编辑器程序就变成了现在这样:

 Visual Studio Code占用约600M内存.

一般用户不会注意到这一点, 因为每个人都至少使用8或16GB内存. 此外, 他们的存储设备也不会让他们感受到 500M字节代码编辑器的沉重(Tauri和Neutralinojs解决了应用大小的问题, 但它们仍在制作混合应用).

同样, 如果应用变得缓慢, 典型的移动用户往往会将责任归咎于设备. 现代用户经常升级设备, 以解决应用开发人员造成的性能问题. 因此, 在当今的软件开发行业, 混合应用开发比本地应用开发更受欢迎. 此外, 混合替代方案(如 Flutter, React Native等)也变得更加流行.

总结一下

混合应用开发框架和其他替代框架为构建跨平台应用提供了一个高效, 开发人员优先的环境. 但是, 从用户的角度来看, 这些开发方法会产生一些隐藏的性能和可用性问题. 现代强大的硬件组件处理能力可以掩盖这些开发方法中的技术问题. 此外, 与依赖平台的原生应用开发相比, 这些方法提供了更富有成效, 开发人员优先的开发环境. 编程新手开始学习桌面应用的Electron开发, 移动应用的Flutter开发和React Native开发, 就像他们跳过C作为他们的第一门编程语言一样.

因此, 原生应用的黄金时代走到了尽头. 幸运的是, 程序员仍在维护旧的原生应用代码库. 操作系统永远不会将其预先包含的应用迁移到混合应用中. 与此同时, 一些开发人员使用类似SDL的跨平台, 高性能原生绘图库构建轻量级跨平台应用. 尽管现代混合应用开发和替代方法已成为软件行业的默认方式, 但我们仍可以保留现有的纯原生定位.

flutter有哪些架构的框架?

Flutter是一种新兴的跨平台移动应用开发框架，它提供了丰富的UI组件和工具，使得应用开发更加容易。在Flutter中，有很多架构框架可供选择，以下是几个比较常用的架构框架：

1. BLoC (Business Logic Component)：BLoC是一种状态管理模式，它将应用程序中的业务逻辑和UI分离，使得应用程序更易于维护和测试。在Flutter中，可以使用flutter_bloc库来实现BLoC架构。 Provider：Provider是Flutter中的一个轻量级状态管理库，它使用InheritedWidget实现状态共享，可以有效地解决Flutter应用中的状态管理问题。
2. MobX：MobX是一种基于响应式编程的状态管理库，它使用可观察对象来管理应用程序的状态，并自动更新与之相关的UI组件。在Flutter中，可以使用mobx库来实现MobX架构。
3. Redux：Redux是一种流行的状态管理模式，在Flutter中也有相应的实现库redux_flutter。Redux通过单一数据源管理应用程序的状态，并使用纯函数来处理状态的更新，可以有效地解决Flutter应用中的状态管理问题。 以上是常用的Flutter架构框架，每个框架都有其优点和适用场景，开发者可以根据自己的需求选择合适的架构框架。

除了上面提到的框架之外，还有以下几个Flutter架构框架：

1. GetX：GetX是一种轻量级的Flutter架构框架，它提供了路由管理、状态管理和依赖注入等功能，可以大大简化Flutter应用的开发。
2. MVC：MVC是一种经典的软件架构模式，它将应用程序分为模型、视图和控制器三个部分，可以有效地分离关注点，使得应用程序更易于维护和扩展。
3. MVP：MVP是一种衍生自MVC的架构模式，它将应用程序分为模型、视图和Presenter三个部分，Presenter负责处理业务逻辑，将模型数据展示到视图上。
4. MVVM：MVVM是一种流行的架构模式，它将应用程序分为模型、视图和视图模型三个部分，视图模型负责处理业务逻辑，将模型数据展示到视图上。

总之，Flutter中有很多架构框架可供选择，每个框架都有其优点和适用场景，开发者可以根据自己的需求选择合适的架构框架。

Flutter BLoC

Flutter BLoC是一种状态管理模式，它将应用程序中的业务逻辑和UI分离，使得应用程序更易于维护和测试。BLoC这个缩写代表 Business Logic Component，即业务逻辑组件。
BLoC的核心思想是将UI层和业务逻辑层分离，通过Stream或者Sink等异步编程方式，将UI层和业务逻辑层连接起来。具体来说，BLoC模式包含以下三个部分：
Events：事件，即UI层的用户操作或其他触发条件，例如按钮点击，网络请求完成等等。
Bloc：业务逻辑层，用于处理Events，处理业务逻辑，并向UI层提供状态更新。
State：状态，即UI层的显示状态，例如页面的loading状态，数据请求成功或失败状态等等。

BLoC的核心是Bloc和State之间的联系，Bloc接收Events，并根据业务逻辑处理后，通过Stream向UI层提供状态更新。UI层监听Bloc的Stream，获取最新的State，并根据State更新UI状态。
在Flutter中，可以使用StreamController来创建BLoC。StreamController是一个异步数据流控制器，可以创建一个Stream用于事件流，创建一个Sink用于事件的注入。
Flutter框架提供了一个非常好的BLoC框架flutter_bloc，它封装了BLoC的核心逻辑，使得开发者可以更加方便地使用BLoC模式进行状态管理。使用flutter_bloc框架，只需要定义好Events、Bloc和State，然后将它们组合起来，就可以实现状态管理，从而将UI层和业务逻辑层分离。

总之，Flutter BLoC是一种状态管理模式，它通过将UI层和业务逻辑层分离，使用Stream或Sink等异步编程方式将它们连接起来，实现了应用程序的业务逻辑和UI分离。

如何选择使用

选择使用哪种Flutter架构框架取决于具体的应用程序需求和开发团队的技术水平。以下是一些常见的应用场景和推荐的架构框架：
对于小型应用程序，可以考虑使用轻量级的状态管理库，如Provider或GetX。
对于需要处理复杂业务逻辑的应用程序，可以使用BLoC、MobX或Redux等状态管理框架。
对于需要实现高度可测试性的应用程序，可以考虑使用MVC、MVP或MVVM等经典的软件架构模式。
总之，选择哪种Flutter架构框架取决于具体的应用程序需求和开发团队的技术水平。开发者应该根据自己的需求和技能水平选择最适合的架构框架，以提高开发效率和代码质量。

GetX和BLoC的优缺点

GetX和BLoC都是常见的Flutter架构框架，它们各有优缺点，下面是它们的主要特点和优缺点的比较：

GetX

优点：

简单易用：GetX是一种轻量级的Flutter框架，提供了简单易用的依赖注入、路由管理和状态管理等功能，可以大大简化Flutter应用的开发。
性能优秀：GetX使用原生的Dart语言构建，不需要任何代码生成，因此运行速度非常快，同时也具有很好的内存管理和性能优化能力。
功能完备：GetX提供了路由管理、依赖注入、状态管理、国际化、主题管理等功能，可以满足大多数应用程序的需求。

缺点：

社区相对较小：相比其他流行的Flutter框架，GetX的社区相对较小，相关文档和教程相对较少，需要一定的自学能力。
不适合大型应用：由于GetX是一种轻量级框架，不适合处理大型应用程序的复杂业务逻辑和状态管理，需要使用其他更加强大的框架。

BLoC

优点：

灵活可扩展：BLoC提供了灵活的状态管理和业务逻辑处理能力，可以适应各种应用程序的需求，同时也具有良好的扩展性。
可测试性强：BLoC将UI和业务逻辑分离，提高了代码的可测试性，可以更容易地编写和运行测试代码。
社区活跃：BLoC是一种流行的Flutter框架，拥有较大的社区和用户群体，相关文档和教程比较丰富，容易入手。

缺点：

学习曲线较陡峭：BLoC是一种相对复杂的框架，需要一定的学习曲线和编程经验，初学者可能需要花费较多的时间和精力。
代码量较大：由于BLoC需要处理UI和业务逻辑的分离，因此需要编写更多的代码来实现相同的功能，可能会增加开发成本和维护难度。
总之，GetX和BLoC都是常见的Flutter架构框架，它们各有优缺点。选择哪种框架取决于具体的应用程序需求和开发团队的技术水平。

前言

通常我们在App中会使用第三方的开源代码，按照许可协议，我们应该在App中公开使用的开源代码并且附上对应的开源协议。当然，实际上只有少部分注重合规性的大厂才会这么干，比如下图是支付宝的关于界面的第三方信息。当然，对于小企业，基本上都不会放使用的第三方开源代码的任何信息。 

不过，作为一个有“追求”的码农，我们还是想对开源软件致敬一下的，毕竟，没有他们我都不知道怎么写代码。然而，我们的 App 里用了那么多第三方开源插件，总不能一个个找出来一一致敬吧？怎么办？其实，Flutter 早就为我们准备好了一个组件，那就是本篇要介绍的 AboutDialog。

AboutDialog 简介

AboutDialog 是一个对话框，它可以提供 App 的基本信息，如 Icon、版本、App 名称、版权信息等。 

同时，AboutDialog还提供了一个查看授权信息（View Licenses）的按钮，点击就可以查看 App 里所有用到的第三方开源插件，并且会自动收集他们的 License 信息展示。所以，使用 AboutDialog 可以让我们轻松表达敬意。怎么使用呢？非常简单，我们点击一个按钮的时候，调用 showAboutDialog 就搞定了，比如下面的代码：

IconButton(

  onPressed: () {

    showAboutDialog(

      context: context,

      applicationName: '岛上码农',

      applicationVersion: '1.0.0',

      applicationIcon: Image.asset('images/logo.png'),

      applicationLegalese: '2023 岛上码农版权所有'

    );

  },

  icon: const Icon(

    Icons.info_outline,

    color: Colors.white,

  ),

),

参数其实一目了然，具体如下：

• context：当前的 context；
• applicationName：应用名称；
• applicationVersion：应用版本，如果要自动获取版本号也可以使用 package_info_plus 插件。
• applicationIcon：应用图标，可以是任意的 Widget，通常会是一个App 图标图片。
• applicationLegalese：其他信息，通常会放置应用的版权信息。

点击按钮，就可以看到相应的授权信息了，点击一项就可以查看具体的 License。我看了一下使用的开源插件非常多，要是自己处理还真的很麻烦。 

可以说非常简单，当然，如果你直接运行还有两个小问题。

按钮本地化

AboutDialog 默认提供了两个按钮，一个是查看授权信息，一个是关闭，可是两个按钮 的标题默认是英文的（分别是VIEW LICENSES和 CLOSE）。 

如果要改成本地话的，还需要做一个自定义配置。我们扒一下 AboutDialog 的源码，会发现两个按钮在DefaultMaterialLocalizations中定义，分别是viewLicensesButtonLabel和closeButtonLabel。这个时候我们自定义一个类集成DefaultMaterialLocalizations就可以了。

class MyMaterialLocalizationsDelegate

    extends LocalizationsDelegate<MaterialLocalizations> {

  const MyMaterialLocalizationsDelegate();



  @override

  bool isSupported(Locale locale) => true;



  @override

  Future<MaterialLocalizations> load(Locale locale) async {

    final myTranslations = MyMaterialLocalizations(); // 自定义的本地化资源类

    return Future.value(myTranslations);

  }



  @override

  bool shouldReload(

          covariant LocalizationsDelegate<MaterialLocalizations> old) =>

      false;

}



class MyMaterialLocalizations extends DefaultMaterialLocalizations {

  @override

  String get viewLicensesButtonLabel => '查看版权信息';



  @override

  String get closeButtonLabel => '关闭';



}

然后在 MaterialApp 里指定本地化localizationsDelegates参数使用自定义的委托类对象就能完成AboutDialog两个按钮文字的替换。

return MaterialApp(

  debugShowCheckedModeBanner: false,

  title: 'Flutter Demo',

  theme: ThemeData(

    primarySwatch: Colors.blue,

  ),

  home: const AboutDialogDemo(),

  localizationsDelegates: const [MyMaterialLocalizationsDelegate()],

);

添加自定义的授权信息

虽然 Flutter 会自动收集第三方插件，但是如果我们自己使用了其他第三方的插件的话，比如没有在 pub.yaml 里引入，而是直接使用了源码。那么还是需要手动添加一些授权信息的，这个时候我们需要自己手动添加了。添加的方式也不麻烦，Flutter 提供了一个LicenseRegistry的工具类，可以调用其 addLicense 方法来帮我们添加授权信息。具体使用如下：

LicenseRegistry.addLicense(() async* {

  yield const LicenseEntryWithLineBreaks(

    ['关于岛上码农'],

    '我是岛上码农，微信公众号同名。\f如有问题可以加本人微信交流，微信号：island-coder。',

  );

});

这个方法可以在main方法里调用。其中第一个参数是一个数组，是因为可以允许多个开源代码共用一份授权信息。同时，如果一份开源插件有多个授权信息，可以多次添加，只要名称一致，Flutter就会自动合并，并且会显示该插件的授权信息条数，点击查看时，会将多条授权信息使用分割线分开，代码如下所示：

void main() {

  runApp(const MyApp());

  LicenseRegistry.addLicense(() async* {

    yield const LicenseEntryWithLineBreaks(

      ['关于岛上码农'],

      '我是岛上码农，微信公众号同名。如有问题可以加本人微信交流，微信号：island-coder。',

    );

  });



  LicenseRegistry.addLicense(() async* {

    yield const LicenseEntryWithLineBreaks(

      ['关于岛上码农'],

      '使用时请注明来自岛上码农、。',

    );

  });

}

总结

本篇介绍了在 Flutter 中快速展示授权信息的方法，通过 AboutDialog 就可以轻松搞定，各位“抄代码”的码农们，赶紧用起来向大牛们致敬吧！