基础知识与适配计划

flutter屏幕适配过程中难免会碰到尺度问题，也便是说不是规划给多少就能写多少的，flutter默许的尺度为：dp(android)、pt(ios)，能够理解为1倍像素下的规范尺度，具体表现为 像素/倍率(1、2、3)

咱们开发过程中，以蓝湖为例，规划一般会以 375或 750 屏幕宽为模板进行开发，实际上便是以 iphone6为规范开发，别离表明的是 pt 和 px，iphone62倍像素屏，所以屏幕根本宽度 375, 宽度占用像素为 750，到这儿信任都理解了这两者的关系

现在主流适配计划大致有两种(都是以宽度为参阅):

  1. 依照规划稿等比适配
  2. 距离固定，内容依据剩余宽度等比扩大或许缩小(究竟横向也放不了多少东西)

dp、pt适配计划(距离固定、内容填充适配)：

这种计划一般都是运用 dp、pt 计划来适配的，一般适用于横向内容比较少的页面，一般应用在带图片的内容阅读，越是大屏，内容区域会越大，观看体会越佳，这也是曾经比较主流的适配计划，现在也同样适用，比较与下面的百分比，有时候有些布局需求略微多动一点脑子算了(而不是特殊布局直接按宽为750来布局)，不过没事僵尸还没吃掉我的脑子，还勉强够用

百分比适配计划

依据规划稿宽度，等比例适配到真机上，两者只需求相除便能够得出比例，适用规划稿像素*根本百分比即可，这样能够保证宽度上在不同宽度的手机上表现得大致相同(会有一个像素左右差错，究竟像素不会出现0.1、0.9之类的)

这也是现在跨渠道应用遍及选用的适配计划(已然跨渠道了，那么都相同吧)

混合适配

混合适配便是依据内容和渠道的展现，挑选运用百分比仍是dp、pt计划

例如依据内容分割：朋友圈分享页面挑选dp、pt计划，购物导航页挑选百分比

实际上一般应用都只会运用 百分比 计划适配愈加便利，假如想在大屏渠道上让体会更佳一些，且同时应用到 ipad 上面的应用较多选用 dp、pt计划，而只是手机端则选用 百分比的更多一点

百分比适配计划代码预备

以 dart 为例（可转化为合适自己的编程语言），生成下面代码，以便运用

import 'dart:ui';
import 'package:flutter/material.dart';
class AdaptUtil {
  //设备根本信息对象
  static final MediaQueryData mediaQuery = MediaQueryData.fromWindow(window);
  //屏幕宽度dp
  static final double width = mediaQuery.size.width;
  //屏幕高度dp
  static final double height = mediaQuery.size.height;
  //屏幕像素倍率
  static final double ratio = mediaQuery.devicePixelRatio;
  static final double dp2pxRatio = width / 750;
  //传入规划稿 750 像素宽度为参阅的尺度 dp2px
  static double dp2px(double dp2px) {
    return dp2px * dp2pxRatio;
  }
  //传入px转化成dp
  static double px(double px) {
    return px / ratio;
  }
}

因为都是静态办法，直接经过类名调用即可

//依据750像素宽的规划稿，传入尺度
Container(
  width: AdaptUtil.dp2px(750),
),
//必要时传入像素
Container(
  width: AdaptUtil.px(120),
),

应用到flutter的案例改善

实际运用过程中，因为数字都是num对象，因此能够直接对num进行扩展即可，给转化逻辑包装成特点的样子，便利调用

import 'dart:ui';
import 'package:flutter/material.dart';
final MediaQueryData mediaQuery = MediaQueryData.fromWindow(window);
//屏幕像素倍率
final double ratio = mediaQuery.devicePixelRatio;
//屏幕宽度dp
final double width = mediaQuery.size.width;
//屏幕高度dp
final double height = mediaQuery.size.height;
final double dp2pxRatio = width / 750;
//便利外边调用，不用模块化导出了，打出类名就能拿出变量了
class AdaptUtil {
  //屏幕宽度dp
  static final double width = width;
  //屏幕高度dp
  static final double height = height;
  //padding，例如：x 以及以上底部是 34 (.bottom)，运用其能够避免底部按钮点不到的问题
  static final EdgeInsets padding = mediaQuery.padding;
}
//为了便利运用，咱们伪装成特点调用(实际应该是伪特点，不存在该字段)
extension Adapt on num {
  //运用扩展便利调用,以边距750为例
  double get sp => this * dp2pxRatio;
  //将dp、pt转化为px
  double get px => this / ratio;
}

调用的时候只需求.sp即可

//如下所示调用即可，因为直接调用了办法， 因此不能运用 const，需求留意了
width: 10.sp

最后

你可能会觉得，百分比适配过程中每个都要走转化的办法，那么功用不就变低了么？

这是肯定会有一点影响的，但这类纯计算的一般影响不大，优先从其他地方进行功用优化，假如该优化的都优化了仍是存在功用问题，那么要不就抛弃跨渠道运用原生，要不就产品挑选更新内容来进行优化(不过只需功用合理一般应当以产品为主，究竟产品竞争力很关键，他们负责将产品规划好，咱们负责将技能瓶颈处理，以提升项目整体竞争力，究竟协作共赢)

PS: 实在搞不定的完成和优化点，找产品砍需求，有时间条件的能够纳入原生尝试混编开发，当然假如你觉得百分比的这个拖累了速度，能够只是选用 dp、pt适配计划，也是完全ok，不过这种计划有时需求自己额定估算距离