解决Windows 10应用商店无法加载页面,打不开

Windows 10系统想要下载应用和游戏都需要在应用商店Microsoft Store中下载,但是很多用户反馈应用商店打不开,无法加载页面,请稍后重试的错误,下面通常还有一些代码什么的,不过参考意义不大,下面就教大家如何解决这个问题。

继续阅读解决Windows 10应用商店无法加载页面,打不开

Python-移除PNG透明图的alpha通道

在利用 Photoshop 等得到的 PNG 透明图中,一般都是包含 alpha channel 的.

但是IOS图标不允许图标中包含 Alpha通道。

下面的代码实现的功能:Remove PNG Transparency

From: Remove transparency/alpha from any image using PIL - stackoverflow

参考链接


Python - 移除PNG透明图的alpha通道

Flutter 2.8.1本地化/国际化应用程序名称

Flutter 多国语言支持,参考 Flutter 2.8.1/Android Studio Bumblebee 2021.1.1多国语支持配置和使用

本地化/国际化应用程序名称 Android

系统与开发环境 macOS Big Sur 11.6.3/Android Studio Bumblebee 2021.1.1

Android下本地化应用程序名比较简单,只需要修改 AndroidManifest.xml 里的 application 标签下的 android:label 即可,如下图:

继续阅读Flutter 2.8.1本地化/国际化应用程序名称

Flutter项目中的pubspec.lock文件是什么?

每次我们运行一个新的 Flutter 项目并运行它时,我们都会看到一条消息:

问题是:当我们获得新的依赖项时会发生什么?

正如我们在上一篇文章中看到的《深入研究 Flutter Pubspec.yaml 文件》我们有不同的方法来向项目添加依赖项,但我们还没有讨论的一件事是为什么我们有时会添加插入^符号在我们的依赖版本之前:

这个符号有什么作用?它与pubspec.lock文件有什么关系?

灵活的依赖版本

正如Dart官方文档中所见,有几种不同的方式来定义包的版本:

  • any 或为空 - 这将导致包版本被定义为最新版本或确定相对于其他包约束应该使用哪个版本

  • <><=>= - 允许我们选择更低、更高、更低且等于或更高且等于规定版本的版本

但是,如果我们想要有灵活性和一些稳定性的保证,我们应该考虑使用插入^符号。如文档中所定义:

^version 表示/保证向后兼容指定版本的所有版本的范围。

因此,遵循语义版本指南(其中1.2.3是Major 1、Minor 2 和Patch 3),这意味着:

  • 对于没有主要版本的依赖项,例如0.12.30.0.2-> 插入符号将查找包含在同一次要版本中的依赖项。所以^0.12.3会满足所有版本>= 0.12.3 < 0.13.0

  • 对于具有主要版本的依赖项,例如1.2.3,插入符号将查找包含在同一主要版本中的依赖项。所以^1.2.3会满足所有版本:>=1.2.3 <2.0.0

理论上(因为在实践中一些库可以打破这个规则),我们不会有从to或 from to 的破坏性更改,这就是为什么 Dart 冒昧地为我们升级这些版本。0.12.30.12.61.2.31.6.90

现在,这引出了两个不同的问题:

  • Dart 什么时候更新我们的依赖版本?
  • 它如何为项目选择合适的版本?
  • 在哪里可以找到与应用程序一起使用的特定版本?

要回答这些问题,我们必须了解什么是pubspec.lock文件。

pubspec.lock文件的剖析

与其尝试从整体上查看文件,不如换一种方式——我们创建一个新项目,提交它,然后添加一个新的依赖项:

之后,我们运行flutter pub get并查看pubspec.lock文件的差异内容:

我们一点一点来分析一下:

  • 在顶部,我们有库名称定义,在本例中为version_banner
  • 接着是dependency类型,它告诉我们它是一个direct依赖项,即我们通过pubspec.yaml文件添加的,还是一个transitive依赖项(如package_info锁定文件中的依赖项所示),它是一个依赖项的依赖项;
  • description将相关的依赖性的类型的其他信息(GIT,本地或托管),无论是路径依赖,在git的承诺散列和URL存储库,或托管依赖的URL,在这种情况下, , pub.dev;
  • source告诉我们如何将依赖项添加到项目中。在本例中,我们通过 pub.dev(托管)添加它,但我们也可以使用sourceaspathgit;
  • 最后,version将告诉我们我们正在使用的具体版本是什么。

如果我们仔细查看version,我们会发现虽然我们在pubspec.yamlversion 中定义了^0.2.0,但从锁定文件中解析出来的版本是0.2.1,这意味着 Dart 能够接受并使用最新版本的库,尊重它的次要版本。

为什么我们应该使用^

如果我们只使用一个依赖,使用的好处^只是让我们拥有最新最好的版本。然而,^在我们的依赖项中使用还有另一个很好的理由——它允许 Dart 足够灵活地选择一个与所有瞬态(或依赖项的依赖项)依赖项一致的依赖项版本。

想象一下以下场景 - 您http在应用程序中使用最新版本的包 - http: 0.13.0. 但是,您还使用了另一个名为 library_b 的库,它也依赖于http,但它使用的是更新版本!http: 0.13.3.

那么如果我们选择使用确切的版本会发生什么http: 0.13.3

由于我们使用的是硬依赖版本,Dart 将无法找到同时满足这两个约束的版本。但是如果我们添加^到应用程序的依赖项中呢?从理论上讲,这意味着应用程序会说“我可以有一个灵活的 http 版本,所以找到一个既满足又不引起冲突的版本”。

就这样,我们运行flutter pub get命令:

查看pubspec.lock应用程序的文件,我们看到它现在使用更新版本0.13.3

但是,如果版本不同会发生什么?让我们看看http应用程序版本高于库版本的情况:

该^符号只能找到等于或高于我们声明的版本的版本,这意味着如果我们运行,flutter pub get我们将看到以下错误消息:

解决这个问题的一个唯一的办法就是让这两个库和应用程序依赖于一个^版本,让他们找到一个版本,同时满足。

如果我们无法^在我们正在使用的依赖项中添加表示法,我们总是可以dependency_overrides在我们的pubspec.yaml文件中使用 a ,正如我们在深入研究 Pubspec.yaml 文件中所讨论的那样。

升级我们的版本

因此,如果通过运行flutter pub get我们没有看到通过pubspec.lock文件对我们的包进行任何更新,那么我们如何更新我们的依赖项?

答案是使用flutter pub upgrade

让我们以以下应用程序依赖项为例,并假设pubspec.lock文件使用相同的版本:

如果我们运行,flutter pub upgrade我们会看到所有依赖项都将具有更高版本,符合以下标准^

通过查看差异,我们可以看到这些版本已更新到较新的版本:

但是如果我们不想升级所有的依赖呢?如果我们只想测试特定包的最新版本怎么办?幸运的是,该upgrade命令允许我们使用flutter pub upgrade <package_name>.

让我们通过使用来测试它flutter pub upgrade shared_preferences

正如我们所看到的,命令行告诉我们,虽然有一个更新的版本可用于flutter_bloc,但它没有被应用。我们可以通过查看差异来验证这一点:

查看flutter pub upgrade命令的最后一行,我们看到它提到了该flutter pub outdated命令。如果我们希望pubspec.yaml直接更新我们的文件,此命令可用于检查我们软件包的所有最新和兼容版本:

锁文件在应用中的重要性

现在我们可能会问:为什么有一个锁文件这么重要?

答案很简单:

如果我们正在开发一个应用程序,该lock文件保证每个有权访问该项目的人都能够使用我们正在使用的相同版本的库来运行它。它是我们使用的真实版本的“真相来源”。

这意味着即使我们使用^符号,我们也不会在不同机器上有相同依赖项的不同解析版本,这使得与其他开发人员并行开发项目变得更容易。

但是,如果我们查看Dart 官方文档中的What not to commit,我们会看到不应提交pubspec.lock文件:

不要将库包的锁文件检查到源代码管理中,因为库应该支持一系列依赖版本。库包的直接依赖项版本约束应尽可能宽,同时仍确保依赖项将与测试的版本兼容。

结论

了解这个pubspec.lock文件已经很长时间了,但我们已经成功了

我们现在可以清楚地看到它的重要性——有一种明确的方法来查明我们的应用程序的依赖关系。

此外,我们看到了为什么^在声明依赖项时应该考虑使用该符号 - 它使我们更加灵活,具有更少的依赖项错误,并尝试我们正在使用的库的更新版本。

但是,在本文中,我们只探讨了使用 pub.dev 中的依赖项。如果我们考虑使用我们自己的git依赖项,我们将不仅知道version提交哈希,而且知道提交哈希。通过让我们回答一个非常重要的问题,这些信息可以为我们节省无数的调试时间 - 应用程序无法运行是因为我们没有使用每个库的最新版本吗?

在结束之前还有一件事需要考虑——正如Mark O'Sullivan指出的那样,^在其他技术中使用这种符号会导致Node.js 应用程序中的安全漏洞。您可以在 Chris Laughlin 的演讲中了解更多相关信息:您所有的包都属于我们——保护您的 npm 依赖项。

所以现在您知道如何使用pubspec.lock文件的力量——它将成为您项目的真实来源,以及一种共享和保持应用程序锁定在相同库版本中的方法。

参考链接


Flutter 项目中的pubspec.lock 文件是什么?

Flutter 2.8.1/Android Studio Bumblebee 2021.1.1多国语支持配置和使用

早期版本参考 Flutter 1.22最新的多国语支持配置和使用 ,整个的配置过程比较麻烦。

Flutter 2.8.1/Android Studio Bumblebee 2021.1.1 可以通过 Flutter Intl进行简化处理,完成多语言的配置。

插件安装(Android Studio Bumblebee 2021.1.1)

Flutter Intl插件安装:

依次点击:Android Studio—>Preference—>Plugins—>Marketplace,搜索Flutter Intl

继续阅读Flutter 2.8.1/Android Studio Bumblebee 2021.1.1多国语支持配置和使用

禁止ubuntu 20.04/21.10自动休眠

ubuntu 20.04/21.10使用 RDP 远程登陆之后,如果系统较长时间不操作,系统就自动休眠了。

如果重启之后,从来都没有登陆,就不会出现系统自动休眠的情况。

观察系统日志,发现类似如下的内容:

发现是触发了systemd的自动休眠功能,检查休眠功能的状态以及历史记录,如下:

普通桌面应用这个情况问题不大,但是如果是作为服务器使用的时候,我们一般远程访问系统,这个功能就会导致我们无法远程控制服务器,因此我们需要关闭这个功能。

执行关闭休眠功能的命令,如下:

再次观察系统休眠状态,如下:

发现自动休眠功能已经被关闭,不会出现自动休眠导致远程控制无法访问的情况了。

参考链接


禁止ubuntu 20.04自动休眠

使用allowInsecureProtocol属性解决gradle的仓库地址不安全警告

使用 allowInsecureProtocol 属性解决 gradle 的仓库地址不安全警告,在 IDEATerminal 中使用命令

可以打印出当前 gradle 存在的所有警告信息。

如果有报以下警告:

说明你配置了除 maven 中央仓库之外的其他不安全的仓库(至于“不安全”在这里的定义,我也不是很清楚,一些国内的镜像仓库例如阿里的也是“不安全”的)gradle 中有一个属性可以允许 gradle 使用“不安全”的仓库并且不报警告信息,该属性是 allowInsecureProtocol,官方的

翻译过来就是指定通过不安全的HTTP连接与仓库通信是否可接受,如果该属性的值设置为 true,则表示接受“不安全”的仓库地址。

目前,升级项目的 gradle 7.0.2 版本之后,报错如下:

只需要在 build.gradle 中进行如下的配置即可:

参考链接


使用 allowInsecureProtocol 属性解决 gradle 的仓库地址不安全警告

How to repair a broken/unmountable btrfs filesystem

最近磁盘上的Btrfs分区在调整大小的时候,报错:

How to repair a broken/unmountable btrfs filesystem

The below are the recommended steps for any major btrfs filesystem issue, especially if its unmountable. Reading dmesg or syslog might help you identify which step you could skip to in order to fix a particular problem, but the initial steps are normally useful regardless as btrfs scrub is a very safe repair tool.

  • Boot to a suitable alternative system, such as a rescue shell, different installation of openSUSE, a liveCD, or an openSUSE installation DVD. The installation DVD for the version of openSUSE you are running is usually a good choice as it will certainly use the same kernel/btrfs version. A recent Tumbleweed disk might be better as it will include newer kernel/btrfs
  • Go to a suitable console and make sure you do the below as root
  • Try to mount your partition to /mnt, just to confirm it's really broken

  • If it mounts - are you sure it's broken? if Yes - run

to scrub the system, and

to monitor it

  • If it doesn't mount, try to scrub the device just in case it works

and

to monitor. Once complete, try mounting, if yes, you're fixed.

  • If scrubbing is not an option or does not resolve the issue

then instead try mount -o usebackuproot

Warning: All of the above steps are considered safe and should make no destructive changes to disk. If the above doesn't fix things for you, you can continue with the below steps but the situation is serious enough to justify a bug report, please!

  • Run "btrfs check <device>"

This isn't going to help, but save the log somewhere, it will be useful for the bug report.

  • Seriously consider running "btrfs restore <device> <somewhereto copy data>"

This won't fix anything but it will scan the filesystem and recover everything it can to the mounted device. This especially useful if your btrfs issues are actually caused by failing hardware and not btrfs fault.

  • Run "btrfs rescue super-recover <device>"

Then try to mount the device normally. If it works, stop going.

  • Run "btrfs rescue zero-log <device>"

Then try to mount the device normally. If it works, stop going.

  • Run "btrfs rescue chunk-recover <device>"

This will take a LONG while. Then try to mount the device normally. If it works, stop going.

  • If you didn't run it earlier, be sure to now run "btrfs restore <device> <somewhere to copy data>"

  • Failure to use btrfs restore at this point but continuing to attempt repairs means you are at a very high risk of data loss. It is advisable to use btrfs restore to recover as much data as possible before continuing.

Warning: The above tools had a small chance of making unwelcome changes. Below this point there is a higher risk of damage. Do not continue unless you're prepared to accept the consequences of your choice.

  • Now, ONLY NOW, try btrfsck aka "btrfs check --repair <device>"

最后,上面的步骤都不能解决问题,因此最终是把磁盘上的文件全部拷贝出来,然后重新格式化分区,再把文件全部拷贝回去,解决问题。

参考链接


Flutter单元测试报错“Error: Not found: 'dart:ui'”

开发环境:macOS Big Sur (11.6.2)/Flutter 2.8.1/Android Studio Atrctic Fox (2020.3.1 Patch 4)

参照 将Flutter module集成到Android项目(Android Studio Arctic Fox 2020.3.1/Flutter 2.8.1) 建立项目,在执行 Flutter 单元测试代码的时候报错

继续阅读Flutter单元测试报错“Error: Not found: 'dart:ui'”

Android Studio 2020.3.1 编译报错 "Installed Build Tools revision 32.0.0 is corrupted"

最近,在使用升级老项目的 compileSdkVersion 32 进行 Android 12L适配的时候,报错

详细的报错信息如下:

报错产生的原因是从 Android SDK 31.0.0 开始,SDK里面的构建工具 dx.jar 被改名成 d8.jar,早期(7.x之前)的构建工具在尝试调用的时候找不到原来的的 dx.jar 导致报错。

解决方法有两种:

  1. 升级根目录下的 build.gradle 中的 'com.android.tools.build:gradle:4.1.3'7.0.4 以及以上的版本。
  2. 复制或者创建快捷方式把 d8.jar 复制并改名成 dx.jar

参考链接


Android Studio error "Installed Build Tools revision 31.0.0 is corrupted"