flutter安全,fluttering
Flutter APP 上架 APP Stroe--- Flutter产物是Debug 版被拒绝上传
ITMS-90338: Non-public API usage - The app references non-public symbols in Frameworks/Flutter.framework/Flutter: _ptrace.
专注于为中小企业提供网站建设、成都网站建设服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业新田免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了上千家企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。
原因: 使用了 Flutter 的debug 版产物 打成 iPa 包
就是Frameworks/Flutter.framework 是debug 版的产物
Debug 版的 Flutter 产物 ,SDK 内部使用了 苹果内部私有的API , 会被苹果审核监测到,存在安全性隐患. 导致拒绝上传到苹果后台.
产生的原因: 因为开发过程中,直接使用了debug 模式进行开发, 在打包的时候,直接打开 iOS 文件夹下面的工程,在Xcode 里设置 release 模式时,此时,Flutter 的产物还是 debug 模式下的产物. 没有删除替换成 release 产物
1.先 将工程 清理一遍,清理之前debug模式下 的Flutter 产物
2.然后 打开Xcode 工程,配置好相关 版本号,证书,release 模式
3. 使用命令行 打包 release ,这样Flutter.framework就会生成 release 产物
4.最后 在Xcode 工程内,按照正常 打包上传 包过程就可以了
1.进入 Flutter 工程 命令行操作
flutter clean
2 .清理之前debug 模式下的 残留产物 (或者手动进入文件夹删除)
rm -rf ios/Flutter/Flutter.framework
3. 获取 Flutter 的第三方依赖库
flutter pub get
4.编译 release 打包 产物
flutter build ios --release
(此时这里可以打包出 app 了, 为了安全起见,最好再次进入Xcode 清理一遍,直接打包上传,)
上面这一步,主要目的是生成 Flutter.framework 的release 版本产物
5.进入Xcode 工程,clean 一遍,检查相关证书配置,版本号等
6.直接 Xcode Archive 打包IPA 上传 苹果后台
最后上传成功:
思路: 通过检查Flutter.framework 它的CPU 架构支持
如果: 该产物 支持模拟器 x86_arm64 这样的架构的话,说明该产物就是 Debug 版的 产物
因为release 版的 产物是 不支持 模拟器CPU架构的.
输入终端命令: lipo -info 产物的物理路径
比如: lipo -info /Users/zzc/Documents/rce_flutter/ios/Flutter/Flutter.framework/Flutter
flutter项目升级2.0过程填坑记录
在此之前先推荐看大佬的: 填坑指导
iOS需要注意：
1、flutter2.0要求cocoapods 升级到1.9.0
详情看这篇博客
2、原来flutter项目中的podfile文件是旧版本的ccocoapods了，删除podfile和对应的.lock，然后flutter项目重新运行使用它自动生成的podfile文件
3、安装CocoaPods
卸载cocoapods：sudo gem uninstall cocoapods
查看cocoapods版本：pod --version
指定版本安装：
sudo gem install -n /usr/local/bin cocoapods -v 1.9.3（新MacOS系统升级）
不指定版本安装
sudo gem install -n /usr/local/bin cocoapods
说明 :老项目sdk1.17.0===升级到2.0.1,当前所有操作基于win平台
到此为止环境已经准备妥当，正式进入项目修改。
所有的插件都要适配到空安全，插件是否支持均会有对应说明Null safety,适配过程不确定版本的话，可以使用dio: any,适配完事后再在pubspec.lock文件中查看具体的版本修改过来,实在有部分插件没有支持的，参考下面
部分插件在适配空安全的版本放弃维护了，得自行更新或寻找替代，如： flutter_swiper 变为 flutter_swiper_null_safety ，插件更新后要注意项目中的用法是否需要更新
2.1.1: 以前采用的是 provide 插件共享全局数据,现在变化为 provider ，用法改变, 点击参考 ，以防文章丢失，我重复一遍：
比如:
2.1.2: dio版本升级到4.0.0最新版后，部分用法改变
2.2.1
2.2.2
解决方案:
2.2.3
解决方案:
2.2.4
解决方案:
2.2.5
解决方案:
2.2.6
解决方案:
2.2.7
解决方案:
2.2.8
解决方案: child 换为sliver
2.2.8.1
解决方案: 项目目录下: android--app-build.gradle --minSdkVersion改为:18 或者19
2.2.8.2
解决方案: 在pubspec.yarm管理里面添加:publish_to
2.2.8.3
解决方案: video_player升级后字段发生了变化，initialized字段更换为:isInitialized(_controller.value.isInitialized)
2.2.8.4
解决方案:
2.2.8.5
解决方案:
2.2.8.6
解决方案: 方案一:删除ios目录下的Podfile.lock 文件然后重新运行 pod install命令
方案二:删除ios目录下的Podfile.lock与Podfile文件 重新运行flutter run或flutter build ios
方案三:删除ios目录,重新运行 flutter create . 命令，注意有"."这个符号不要忘记
2.2.8.7
这个报错一般对应的就是下面的报错，注意看后面的报错信息，看是哪个插件报错。
解决方案: 把Podfile的版本注释打开，改为platform :ios, '9.0' 或者是更高的版本
全局替换
1.将new List() 替换为[];
2.TextField的inputFormatters:[WhitelistingTextInputFormatter.digitsOnly] 替换为[FilteringTextInputFormatter.digitsOnly]
3.TextField的inputFormatters:[WhitelistingTextInputFormatter(RegExp("[a-z|A-Z|0-9]"))]替换为FilteringTextInputFormatter.allow(RegExp("[a-z|A-Z|0-9]"))
4.Stack组件中overflow: Overflow.visible改为 clipBehavior: Clip.none；overflow: Overflow.clip改为clipBehavior:Clip.hardEdge
5.ListWheelScrollView组件中clipToSize = false改为clipBehavior: Clip.none,clipToSize = true改为 Clip.hardEdge
6.TextField中maxLengthEnforced: true改为maxLengthEnforcement:MaxLengthEnforcement.enforced
7.FlatButton、RaisedButton、OutlineButton的变化： 官方参考
颜色的属性发生了变化，由原来的Color 变为了MaterialStatePropertyColor, 这是未了解决不同状态(pressed、hovered、focused、disabled)下按钮颜色的变化
例如
8.出现如下警告
9.showSnackBar报错误
解决方案: Scaffold换为ScaffoldMessenger
10.textSelectionColor弃用
解决方案:
11.charts_flutter升级后属性报错
解决方案:
12.flutter 真机调试无法访问网络，dio报错
解决方案:
android:
ios:
问题12完整参考
Flutter 升级空安全攻略
1、升级依赖的插件版本pubspec.yaml（包括example），pub get 解决依赖冲突
2、pubspec.yaml所在路径下执行 dart pub upgrade --null-safety 检查是否所在flutter工程依赖库是否都升级到了空安全版本
example示例需要进入example路径下检查
1、List默认构造方法删除，改用[];
main.dart文件main方法第一行增加CustomFlutterBinding();
2、flutter clean，删除所有 pubspec.lock文件 ，pub get
3、FutureOr报错引入头文件、import 'dart:async';
4、属性用优先用late 或者 ？声明，在确定不为空情况才用！
Flutter Dio源码分析(四)--封装
Flutter Dio源码分析(一)--Dio介绍
Flutter Dio源码分析(二)--HttpClient、Http、Dio对比
Flutter Dio源码分析(三)--深度剖析
Flutter Dio源码分析(四)--封装
Flutter Dio源码分析(一)--Dio介绍视频教程
Flutter Dio源码分析(二)--HttpClient、Http、Dio对比视频教程
Flutter Dio源码分析(三)--深度剖析视频教程
Flutter Dio源码分析(四)--封装视频教程
github仓库地址
本文会手把手教你该怎么去封装一个类库，平时在我们的工作中都是拿着别人的造好的轮子在使用，这篇文章将带你怎么去自己造轮子，以后再碰到别的类库需要对其进行封装的时候提供一个的思路和方法。
在前面的文章中，我们对 Dio 的基本使用、请求库对比、源码分析，我们知道 Dio 的使用非常的简单，那为什么还需要进行封装呢？有两点如下：
当组件库方法发生重要改变需要迁移的时候如果有多处地方用到，那么需要对使用到的每个文件都进行修改，非常的繁琐而且很容易出问题。
当不需要 Dio 库的时候，我们可以随时方便切换到别的网络请求库，当然 Dio 目前内置支持使用第三方库的适配器。
因为一个应用程序基本都是统一的配置方式，所以我们可以针对 拦截器 、 转换器 、 缓存 、 统一处理错误 、 代理配置 、 证书校验 等多个配置进行统一管理。
因为我们的应用程序在每个页面中都会用到网络请求，那么如果我们每次请求的时候都去实例化一个 Dio ，无非是增加了系统不必要的开销，而使用单例模式对象一旦创建每次访问都是同一个对象，不需要再次实例化该类的对象。
这是通过静态变量的私有构造器来创建的单例模式
我们对 超时时间 、 响应时间 、 BaseUrl 进行统一设置
因为不管是 get() 还是 post() 请求， Dio 内部最终都会调用 request 方法，只是传入的 method 不一样，所以我们这里定义一个枚举类型在一个方法中进行处理
我们已经把 Restful API 风格简化成了一个方法，通过 DioMethod 来标明不同的请求方式。在我们平时开发的过程中，需要在请求前、响应前、错误时对某一些接口做特殊的处理，那我们就需要用到拦截器。 Dio 为我们提供了自定义拦截器功能，很容易轻松的实现对请求、响应、错误时进行拦截
我们发现虽然 Dio 框架已经封装了一个 DioError 类库，但如果需要对返回的错误进行统一弹窗处理或者路由跳转等就只能自定义了
在我们发送请求的时候会碰到几种情况，比如需要对非open开头的接口自动加上一些特定的参数，获取需要在请求头增加统一的 token
在我们请求接口前可以对响应数据进行一些基础的处理，比如对响应的结果进行自定义封装，还可以针对单独的 url 做特殊处理等。
我们看了转换器的介绍，发现和拦截器的功能差不多，那为什么还要存在转换器，有两点：
执行流程： 请求拦截器 请求转换器 发起请求 响应转换器 响应拦截器 最终结果 。
只会被用于 'PUT'、 'POST'、 'PATCH'方法，因为只有这些方法才可以携带请求体(request body)
会被用于所有请求方法的返回数据。
在开发过程中，客户端和服务器打交道的时候，往往会用一个 token 来做校验，因为每个公司处理刷新token的逻辑都不一样，我这里举一个简单的例子
为什么我们需要有取消请求的功能，如果当我们的页面在发送请求时，用户主动退出当前界面或者app应用程序退出的时候数据还没有响应，那我们就需要取消该网络请求，防止不必要的错误。
由 服务器生成 的 一小段文本信息 ，发送给浏览器，浏览器把 cookie 以kv形式保存到本地 某个目录下的文本文件内，下一次请求同一网站时会把该 cookie 发送给服务器。
cookie 的使用需要用到两个第三方组件 dio_cookie_manager 和 cookie_jar
因为在我们平时的开发过程中，会碰到一种情况，在进行网络请求时，我们希望能正常访问到上次的数据，对于用户的体验比较好，而不是展示一个空白的页面，该缓存主要是 《Flutter实战》网络接口缓存 提供参考。
我们在程序退出后内存缓存将会消失，所以我们用 shared_preferences 进行磁盘缓存数据。
在我们用flutter进行抓包的时候需要配置 Dio 代理。由 DefaultHttpClientAdapter 提供了一个 onHttpClientCreate 回调来设置底层 HttpClient 的代理。
用于验证正在访问的网站是否真实。提供安全性，因为证书和域名绑定，并且由根证书机构签名确认。
日志打印主要是帮助我们开发时进行辅助排错
为什么除了Flutter之外，我们还需要另一个跨平台开发框架？
不久前，谷歌正式推出 Jetpack Compose 1.0 版本。近日，JetBrains 在此基础上发布了 Compose Multiplatform Alpha 版本，旨在将 Compose 扩展到桌面和 Web 端。
Compose Multiplatform 由 Compose for Desktop 和 Compose for Web 组成，通过 Kotlin Multiplatform 支持许多不同的平台。其中，Compose Desktop 采用 Google 的 Skia 图形库，来实现在 Windows、macOS 和 Linux 上的 UI 绘制，借此在所有支持的操作系统中提供统一的体验，类似于 Flutter 的做法。
根据 Kotlin 团队的说法，相比起 Electron 框架，Compose Multiplatform 在内存消耗、安装大小和 UI 渲染性能等方面将有更明显的优势。随着 Alpha 版本的发布，Compose Multiplatform 还收获了新的 Android Studio 插件，包括对在 IDE 中显示组件预览的支持以及许多附加功能。
我们希望通过本文帮助大家进一步了解 Compose 的跨平台能力，以及 JetBrains 将 Compose 从 Android 扩展到这些其他平台背后的主要驱动力是什么。
基于 Jetpack Compose 1.0
由谷歌打造的 Jetpack Compose 是一款用于在 Android 应用程序之内构建用户界面的官方框架，上周刚刚发布 1.0 版本。与此同时，Android Studio 代号“极狐”的首个稳定版 2020.3.1 也正式亮相。
尽管才刚迎来 1.0，但谷歌表示“目前 Play Store 中已经有超过 2000 款应用程序在使用 Compose——更重要的是，就连 Play Store 这款应用本身也在使用 Compose。”谷歌方面还表示，“我们一直在与一些顶级应用的开发人员进行合作，他们的反馈和支持帮助我们使 1.0 版本更加强大。”
Jetpack Compose for Android 迎来 1.0 版本
Compose 基于 Kotlin 开发，而 Kotlin 与 Android Studio（即官方指定的 Android IDE）均来自开发工具厂商 JetBrains。虽然 Jetpack Compose 专为 Android 打造（与谷歌的 Flutter 框架不同）， 但 JetBrains 公司坚信 Compose 完全能够获得跨平台能力 。
Compose for Desktop: 这只是开始
Compose Multiplatform 可以说是该框架面向 MacOS、Linux、Windows 以及 Web 开设的一个端口，目前刚刚发布 1.0 Alpha 版本。虽然尚处于早期开发阶段，但 JetBrains 表示，其已经“为开发人员带来能够基本安全使用的稳定 API”。
TheRegister 就此事询问了 JetBrains 公司 Compose 项目负责人 Nikolay Igotti，希望了解为什么该公司在拥有了已经广泛应用于 IntelliJ IDEA IDE 及多种丰富变体的桌面应用程序跨平台 Java 框架之外，还要费力开发 Compose for Desktop。Igotti 的回答是，“旧有 Java 框架基本上就是修改版的 Swing。Swing 属于默认 JDK UI 框架，Swing 和 AWT（Abstract Windows Toolkit，抽象窗口工具包）。Compose 则完全是另一码事，当然我们也在设计中考虑到了互操作性需求……Swing 这套框架太陈旧了，最早出现在上世纪九十年代末。多年来人们对于 UI 的设计思路已经天翻地覆，Swing 显然满足不了要求了。”
JetBrains IDE 中的 Compose for Desktop 项目
Compose 与 Swing 有一个比较大的共同点：与其他使用本机控件的跨平台框架，比如例如 Java 的 SWT（Standard Widget Toolkit）以及微软的 Xamarin 有所不同，它们选择自主绘制控件。Compose 使用的 Skia 开源图形库，也在谷歌 Chrome、Flutter 及其他众多框架当中得到广泛应用。那这是否意味着 Compose 应用程序将没有自己的原生外观？对此，Igotti 的回应是，“这取决于开发人员的选择，取决于他们如何为应用程序设置主题。在这方面，Compose 的情况与 Flutter 等其他框架没什么区别。”
那 Compose for Desktop 应用程序是否依赖于 JVM（Java Virtual Machine）运行？Igotti 表示，“我们也知道，JVM 应用程序的发布情况可能比较棘手。因此我们提供自己的 Gradle 插件，其使用 jpackage 与 Jlink 以 JVM 应用程序为基础制作原生应用程序。Mac 的.dmg、Windows 的 MSI、Linux 的 deb 包等均可实现，大家用不着担心 JVM。”
也就是说，开发成果将会是一款被精心包裹起来的 JVM 应用程序。JetBrains 还有一款用于解决这个问题的 Kotlin/Native 编译器，“预计将在未来发布，或者专门用于桌面开发。”
对应用程序的另一种思考方式
那 Web 应用程序方面呢？Igotti 回应称，“我们使用 Kotlin/JS 编译器。”Compose 的 Web 版本不如桌面版先进，说明文档中也警告称“API 尚未最终确定，预计会发生重大变化。”此外，虽然 Web 版本确实使用 Compose 模型，但 API 却完全不同，而且会使用 HTML 与 CSS。所以，Web 版与 Compose for Desktop 之间能够共享的代码应该比较少。
据 Igotti 介绍，“Compose 代表着一种不同的应用程序思考方式。状态即 UI 的真实来源，而 UI 本身是无状态的，其表达永远由状态计算得出。在这方面，Compose for Web 采用一组相同的原语，完全相同的状态管理思路。但是对于具体的小部件集合与排列方式，Web 版与桌面版之间确实无法互通。”
说到这里，为什么要把 Compose for Android 扩展到多种其他平台之上？“Compose 的目标受众主要分为三类。首先是使用 Kotlin 与 Compose 的 Android 开发人员，他们希望把自己的开发成果交付至其他平台；其二是纯 Kotlin 开发人员，他们希望以‘一次编写、随处运行’的方式开发新的应用程序；第三则是那些不太熟悉 Kotlin 或者 Compose，但又希望开发出精美 UI 的用户，我们希望能为他们提供实现目标的工具。”
Igotti 并没有给出具体的发布日期，但表示自己希望 Beta 版能在今年秋天发布，“我们也希望能在今年之内推出 1.0 版本。”项目本身是完全开源的，“二十一世纪了，框架在大多数人们心目中就不应该收费。我们只是想开发一款长期缺失的软件”，补足 JetBrains 当前商业模式中的工具链。
那么，JetBrains 会在自己的其他工具中使用 Compose 吗？事实上，他们的 JetBrains Toolbox（用于管理已安装的 IDE）已经在使用 Compose，但 Igotti 表示短时间内 Compose 还无法取代 IntelliJ IDEA 等现有框架。“编辑器是其中最复杂也最重要的组件，经历了 20 年的发展演进，我们几乎不可能在中途进行重写了。无论是 JetBrains 还是我个人，都不打算强迫每个人都转而使用 Compose。我们的目标是为原有框架选项满足不了的用户提供新的解决方案。”
写在最后
那么，为什么除了 Flutter 之外，我们还需要另一个跨平台框架？虽然谷歌的 Flutter 最开始主要面向移动设备，但现在也开始向桌面及 iOS 进军，甚至比 Compose 还抢先了一步。不过，根据 StackOverflow 的最新调查， Flutter 使用的语言为 Dart；尽管 Dart 语言的人气正在增长（正是受到 Flutter 的推动），但仍然无法与 Kotlin 相提并论。
Compose 代表着一种独特的 UI 构建方法，也许最期待 Compose 跨平台功能的受众，正是那些曾在 Android 上使用过它、又特别喜欢这种 UI 构建体验的开发者。
想要进一步了解 Compose，国内 Android 开发者可访问以下链接查看中文手册：
延伸阅读：
网站题目：flutter安全,fluttering
浏览地址：http://ybzwz.com/article/dsohhee.html
