MacBook Pro 2023(Apple M2 Pro) 从 Intel 版本 MacBook Pro 2013 通过 TimeMachine 迁移后运行模拟器，启动就崩溃。
崩溃的原因是原来运行的模拟器是通过 Intel HAXM 来加速的，但是 MacBook Pro 2023(Apple M2 Pro) 已经是 ARM 指令集了。这样的组合就诱发了虚拟机的崩溃。
此处，我们需要手工卸载已经安装的 Intel x86 Emulator Accelerator(HAXM installer) 与 Android Emulator 之后重新安装即可解决。
如下图：
继续阅读从Intel版本MacBook Pro 2013迁移到MacBook Pro 2023(Apple M2 Pro)后运行Android模拟器崩溃
当在团队开发中使用版本控制系统时，商定一个统一的工作流程是至关重要的。Git 的确可以在各个方面做很多事情，然而，如果在你的团队中还没有能形成一个特定有效的工作流程，那么混乱就将是不可避免的。
基本上你可以定义一个完全适合你自己项目的工作流程，或者使用一个别人定义好的。
在这章节中我们将一起学习一个当前非常流行的工作流程 git-flow。
一旦安装安装 git-flow，你将会拥有一些扩展命令。这些命令会在一个预定义的顺序下自动执行多个操作。是的，这就是我们的工作流程！
git-flow 并不是要替代 Git，它仅仅是非常聪明有效地把标准的 Git 命令用脚本组合了起来。
严格来讲，你并不需要安装什么特别的东西就可以使用 git-flow 工作流程。你只需要了解，哪些工作流程是由哪些单独的任务所组成的，并且附带上正确的参数，以及在一个正确的顺序下简单执行那些对应的 Git 命令就可以了。当然，如果你使用 git-flow 脚本就会更加方便了，你就不需要把这些命令和顺序都记在脑子里。
最新的git bash已经支持，不用安装，或者使用 Sourcetree。
要了解安装 git-flow 细节，请阅读下面这个文档 official documentation。
当你想把你的项目 “切换” 到 git-flow 上后，Git 还是可以像往常一样工作的。这完全是取决于你在仓库上使用特殊的 git-flow 命令或是普通的 Git 命令。换句话说，git-flow 它不会以任何一种戏剧性的方式来改变你的仓库。
话虽如此，git-flow 却存在一些限制。让我们开始在一个新的项目上初始化它吧，之后我们就会有所发现：
|
1 2 3 4 5 6 7 8 9 |
$ git flow init Initialized empty Git repository in /Users/tobi/acme-website/.git/ Branch name for production releases: [master] Branch name for "next release" development: [develop] How to name your supporting branch prefixes? Feature branches? [feature/] Release branches? [release/] Hotfix branches? [hotfix/] |
当在项目的根目录执行 “git flow init” 命令时（它是否已经包括了一个 Git 仓库并不重要），一个交互式安装助手将引导您完成这个初始化操作。听起来是不是有点炫，但实际上它只是在你的分支上配置了一些命名规则。
尽管如此，这个安装助手还是允许你使用自己喜欢的名字。我强烈建议你使用默认的命名机制，并且一步一步地确定下去。
git-flow 模式会预设两个主分支在仓库中：
这两个分支被称作为 长期分支。它们会存活在项目的整个生命周期中。而其他的分支，例如针对功能的分支，针对发行的分支，仅仅只是临时存在的。它们是根据需要来创建的，当它们完成了自己的任务之后就会被删除掉。
让我们开始探索一些在现实应用中可能遇到的案例吧！
对于一个开发人员来说，最平常的工作可能就是功能的开发。这就是为什么 git-flow 定义了很多对于功能开发的工作流程，从而来帮助你有组织地完成它。
让我们开始开发一个新功能 “rss-feed”：
|
1 2 3 4 5 6 |
$ git flow feature start rss-feed Switched to a new branch 'feature/rss-feed' Summary of actions: - A new branch 'feature/rss-feed' was created, based on 'develop' - You are now on branch 'feature/rss-feed' |
概念
在这些命令的输出文本中，git-flow 会对刚刚完成的操作打印出一个很有帮助的概述
当你需要帮助的时候，你可以随时请求帮助。例如：
正如上面这个新功能一样，git-flow 会创建一个名为 “feature/rss-feed” 的分支（这个 “feature/” 前缀 是一个可配置的选项设置）。你已经知道了，在你做新功能开发时使用一个独立的分支是版本控制中最重要的规则之一。
git-flow 也会直接签出这个新的分支，这样你就可以直接进行工作了。
经过一段时间艰苦地工作和一系列的聪明提交，我们的新功能终于完成了：
|
1 2 3 4 5 6 7 8 |
$ git flow feature finish rss-feed Switched to branch 'develop' Updating 6bcf266..41748ad Fast-forward feed.xml | 0 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 feed.xml Deleted branch feature/rss-feed (was 41748ad). |
最重要的是，这个 “feature finish” 命令会把我们的工作整合到主 “develop” 分支中去。在这里它需要等待：
之后，git-flow 也会进行清理操作。它会删除这个当下已经完成的功能分支，并且换到 “develop” 分支。
Release 管理是版本控制处理中的另外一个非常重要的话题。让我们来看看如何利用 git-flow 创建和发布 release。
当你认为现在在 “develop” 分支的代码已经是一个成熟的 release 版本时，这意味着：第一，它包括所有新的功能和必要的修复；第二，它已经被彻底的测试过了。如果上述两点都满足，那就是时候开始生成一个新的 release 了：
|
1 2 |
$ git flow release start 1.1.5 Switched to a new branch 'release/1.1.5' |
请注意，release 分支是使用版本号命名的。这是一个明智的选择，这个命名方案还有一个很好的附带功能，那就是当我们完成了release 后，git-flow 会适当地自动去标记那些 release 提交。
有了一个 release 分支，再完成针对 release 版本号的最后准备工作（如果项目里的某些文件需要记录版本号），并且进行最后的编辑。
现在是时候按下那个危险的红色按钮来完成我们的release了：
|
1 |
git flow release finish 1.1.5 |
这个命令会完成如下一系列的操作：
从 Git 的角度来看，release 版本现在已经完成。依据你的设置，对 “master” 的提交可能已经触发了你所定义的部署流程，或者你可以通过手动部署，来让你的软件产品进入你的用户手中。
很多时候，仅仅在几个小时或几天之后，当对 release 版本作做全面测试时，可能就会发现一些小错误。
在这种情况下，git-flow 提供一个特定的 “hotfix” 工作流程（因为在这里不管使用 “功能” 分支流程，还是 “release” 分支流程都是不恰当的）。
|
1 |
$ git flow hotfix start missing-link |
这个命令会创建一个名为 “hotfix/missing-link” 的分支。因为这是对产品代码进行修复，所以这个 hotfix 分支是基于 “master” 分支。
这也是和 release 分支最明显的区别，release 分支都是基于 “develop” 分支的。因为你不应该在一个还不完全稳定的开发分支上对产品代码进行地修复。
就像 release 一样，修复这个错误当然也会直接影响到项目的版本号！
在把我们的修复提交到 hotfix 分支之后，就该去完成它了：
|
1 |
$ git flow hotfix finish missing-link |
这个过程非常类似于发布一个 release 版本：
还是和产生 release 的流程一样，现在需要编译和部署你的产品（如果这些操作不是自动被触发的话）。
最后，在结束这个章节之前，我要再次强调几个重点。
首先，git-flow 并不会为 Git 扩展任何新的功能，它仅仅使用了脚本来捆绑了一系列 Git 命令来完成一些特定的工作流程。
其次，定义一个固定的工作流程会使得团队协作更加简单容易。无论是一个 “版本控制的新手” 还是 “Git 专家”，每一个人都知道如何来正确地完成某个任务。
记住，使用 git-flow 并不是必须的。当积攒了一定的使用经验后，很多团队会不再需要它了。当你能正确地理解工作流程的基本组成部分和目标的之后，你完全可以定义一个属于你自己的工作流程。
我们使用 Git Flow 来进行版本管理控制，它相对于 GitHub Flow 更适合在产品开发中快速迭代，这种代码管理模式应该已经广泛使用了。
另外，我们鼓励使用 Git 客户端 SourceTree，它集成了 Git Flow 的一些基本操作。如果严格遵循 Git Flow 的流程进行版本管理控制，那么我们只用管开始和结束一个 Feature/Release/Hotfix，基本上是不用手动 merge 分支的。
Pull Request是当功能开发者完成一个新功能后向项目维护者发送合并请求通知的机制。它的使用过程如下：
功能开发者可以通过Gitlab页面发送pull request开发管理员自己或组织其他的团队成员审查、讨论和修改代码开发管理员合并新增功能分支到develop分支，然后关闭pull request，并且可以选择删除新增分支1. 由开发管理员负责在Gitlab上创建空白的仓库，并clone到本地，在sourcetree的git flow菜单中选择初始化仓库，并push到远端。
2. 在Gitlab上设置保护分支，把master、develop分支保护起来，只有指定人可push。
3. 功能开发者clone代码到本地，先在sourcetree的git flow菜单中选择初始化仓库。
4. 然后再开始新建功能分支，进行开发工作。
5. 新功能开发全部完成或部分完成后，功能开发者把最新代码push到远端同样的新功能分支里，并在Gitflow发起pull request给开发管理员
6. 开发管理员review代码，选择合并代码到develop，并可选择删除已经合并的新功能分支
7. 当开发管理员处理完合并请求后，开发者,切换到develop分支，直接删除自己的本地分支及远程分支，不要点击完成(Finish Feature)，此时开发者pull远端develop分支最新代码即可，可忽视本地的push提醒。
8. release、hotfix分支和feature分支操作类似。
9. 不可点击完成新功能、完成发布版本、完成修复补丁，因为这样会导致自动合并代码到master或develop分支
到此为止，我们发现整个的工作流还算可以接受，但是执行 git flow release 的时候，会发现由于 Git Flow 总是假定我们合并的分支可以立即部署到生产环境，所以如果我们的工作流程符合这个过程，是很简单的。
但是更多的时候，我们会遇到同时开发可功能模块A、B、C，最终上线只上线A、C的情况，这种情况下，会涉及到版本会退的问题，这个时候 git flow 反倒是不方便使用了。
这种情况下，GitLab Flow 流程可能更适合我们的工作流程。
树莓派4的GPIO接口保留了以前型号的标准功能，也引入了一些额外的功能。下面让我们来看看这个标准的40针接口都有哪些变化，具体都是哪些功能？
Apache2 的目录浏览功能 列出的文件名不完整，修改设置参考如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
< Directory "设置你的路径"> Options +Indexes +Includes +FollowSymLinks +MultiViews AllowOverride All #Require local IndexOptions Charset=UTF-8 #编码格式,防止中文乱码 IndexOptions NameWidth=* #根据文件名自动调整列宽 Allow from all </ Directory > |
一直通过 Android Studio 3.6.3/4.0/4.1/4.2配置Robolectric-3.8/4.3.1/4.5.1/4.6.1 Powermock-1.6.6单元测试环境 配置 Powermock 进行单元测试。
虽然配置起来稍显复杂，但是也是够用的。
但是当升级到Android Studio Flamingo | 2022.2.1 Patch 2 之后，内置的 Java 版本被升级到 Java 17 ，使用这个 Java 版本执行单元测试，会报错如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
Failed to instantiate DeepCloner. The DeepCloner implementation must have a one-arg constructor taking a Classloader as parameter. java.lang.RuntimeException: Failed to instantiate DeepCloner. The DeepCloner implementation must have a one-arg constructor taking a Classloader as parameter. at org.powermock.classloading.AbstractClassloaderExecutor.createDeepCloner(AbstractClassloaderExecutor.java:91) at org.powermock.classloading.AbstractClassloaderExecutor.executeWithClassLoader(AbstractClassloaderExecutor.java:55) at org.powermock.classloading.SingleClassloaderExecutor.execute(SingleClassloaderExecutor.java:67) at org.powermock.classloading.AbstractClassloaderExecutor.execute(AbstractClassloaderExecutor.java:43) at org.powermock.modules.junit4.rule.PowerMockStatement.evaluate(PowerMockRule.java:75) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.robolectric.RobolectricTestRunner$HelperTestRunner$1.evaluate(RobolectricTestRunner.java:591) at org.robolectric.internal.SandboxTestRunner$2.lambda$evaluate$0(SandboxTestRunner.java:274) at org.robolectric.internal.bytecode.Sandbox.lambda$runOnMainThread$0(Sandbox.java:88) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833) Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480) at org.powermock.classloading.AbstractClassloaderExecutor.createDeepCloner(AbstractClassloaderExecutor.java:89) ... 12 more Caused by: java.lang.ExceptionInInitializerError at com.thoughtworks.xstream.XStream.setupConverters(XStream.java:845) at com.thoughtworks.xstream.XStream.<init>(XStream.java:574) at com.thoughtworks.xstream.XStream.<init>(XStream.java:496) at com.thoughtworks.xstream.XStream.<init>(XStream.java:465) at com.thoughtworks.xstream.XStream.<init>(XStream.java:411) at com.thoughtworks.xstream.XStream.<init>(XStream.java:350) at org.powermock.classloading.DeepCloner.<init>(DeepCloner.java:33) ... 18 more Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field protected java.lang.reflect.InvocationHandler java.lang.reflect.Proxy.h accessible: module java.base does not "opens java.lang.reflect" to unnamed module @5a69b2d1 at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178) at java.base/java.lang.reflect.Field.setAccessible(Field.java:172) at com.thoughtworks.xstream.core.util.Fields.locate(Fields.java:40) at com.thoughtworks.xstream.converters.extended.DynamicProxyConverter.<clinit>(DynamicProxyConverter.java:42) ... 25 more |
可是 Powermock 已经长时间没有新版本发布，没有及时跟进 Java 版本的更新。
当时引入 Powermock 的原因是为了解决静态函数的测试问题，但是从 Mockito 3.4.0 版本开始，Mockito 已经支持静态函数测试。
因此，完全可以只使用 Mockto 进行测试。
|
1 2 |
// https://mvnrepository.com/artifact/org.mockito/mockito-core testImplementation 'org.mockito:mockito-core:5.3.1' |
待测试代码如下:
|
1 2 3 4 5 6 7 8 9 10 |
public class StaticUtils { public static String name() { return "name"; } public static String getString(String s) { return s; } } |
测试代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
import org.junit.Assert; import org.junit.Test; import org.mockito.ArgumentMatchers; import org.mockito.MockedStatic; import org.mockito.Mockito; public class StaticUtilsTest { @Test public void givenStaticMethodWithNoArgs_whenMocked_thenReturnsMockSuccessfully() { Assert.assertEquals(StaticUtils.name(), "name"); try (MockedStatic<StaticUtils> utils = Mockito.mockStatic(StaticUtils.class)) { utils.when(StaticUtils::name).thenReturn("uname"); Assert.assertEquals(StaticUtils.name(), "uname"); utils.when(() -> StaticUtils.getString(ArgumentMatchers.anyString())).thenReturn("target"); Assert.assertEquals(StaticUtils.getString("123"), "target"); } Assert.assertEquals(StaticUtils.name(), "name"); Assert.assertEquals(StaticUtils.getString("123"), "123"); } } |
虽然本次 I/O 的核心 keynote 主要是 AI ，但是按照惯例依然发布了新的 Flutter 稳定版，不过并非大家猜测的 4.0，而是 3.10 ，Flutter 的版本号依然那么的出人意料。
Flutter 3.10 主要包括有对 Web、mobile、graphics、安全性等方面的相关改进，核心其实就是：
ThinkCenter M820z用户指南和硬件维护手册(拆机指南）
Android 7.0 之前，文件的 Uri 以 file:// 形式提供给其他 app 访问。
Android 7.0 之后，分享文件的 Uri 发生了变化。为了安全起见，file:// 形式的Uri 不能正常访问。官方提供了 FileProvider，FileProvider生成的Uri会以content://的形式分享给其他app使用。
content形式的Uri可以让其他app临时获得读取(Read)和写入(Write)权限，只要我们在创建 Intent 时，使用 Intent.setFlags() 添加权限。只要接收Uri的app在接收的Activity任务栈中处于活动状态，添加的权限就会一直有效，直到app被任务栈移除。
在7.0 以前，为了访问 file:// 形式的 Uri，我们必须修改文件的权限。修改后的权限对所有 app 都是有效的，这样的行为是不安全的。content://形式的Uri让Android的文件系统更安全，对于分享的文件，接收方 app 只拥有临时的权限，减少了我们app内部的文件被其他 app 恶意操作的行为。
在manifest文件<application>标签中添加pvodier标签，配置如下。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<manifest> ... <application> <activity> ..... </activity> <provider android:name="androidx.core.content.FileProvider" android:authorities="com.example.app.fileprovider" android:exported="false" android:grantUriPermissions="true"> <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/file_paths" /> </provider> </application> </manifest> |
android:name指定Provider所在的位置。官方自带的FileProvider已经相当完善，所以我们不需要像Service、Broadcast一样自定义，直接使用自带的就行，直接输入privoder会自动出现提示。
android:authorities相当于一个用于认证的暗号，在分享文件生成Uri时，会通过它的值生成对应的Uri。值是一个域名，一般格式为<包名>.fileprovider。
android:exported设置为false，FileProvider不需要公开。
android:grantUriPermissions设置为true，这样就能授权接收端的app临时访问权限了。
在res/xml中创建一个资源文件（如果xml目录不存在，先创建），名字随便（一般叫file_paths.xml）。
|
1 2 3 4 5 |
<?xml version="1.0" encoding="utf-8"?> <paths xmlns:android="http://schemas.android.com/apk/res/android"> <files-path name="my_logs" path="logs/"/> ... </paths> |
<paths>必须有1个或多个子标签，每个子标签代表要请求的私有文件目录。不同的子标签代表不同的目录类型。
在<provider>标签中添加<meta-data>子标签。
|
1 2 3 4 5 6 7 8 9 |
<provider android:name="androidx.core.content.FileProvider" android:authorities="com.example.app.fileprovider" android:exported="false" android:grantUriPermissions="true"> <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/file_paths" /> </provider> |
设置<meta-data>的属性android:name值为android.support.FILE_PROVIDER_PATHS,属性android:resouce的值为刚才我们创建的path文件名。
<paths>的每个子标签必须有path属性，代表content Uris的路径。name不需要和path保持一样，只是一个名称。
子标签有以下几种。
|
1 |
<files-path name="my_files" path="path" /> |
代表内部存储的files目录，与Context.getFilesDir()获取的路径对应。
最终生成的Uri格式为：authorities/pathname/filename
示例：
|
1 |
content://com.example.app.fileprovider/my_files/filexxx.jpg |
|
1 |
<cache-path name="name" path="path" /> |
代表内部存储的cache目录，与Context.getCacheDir()获取的路径对应。
|
1 |
<external-path name="name" path="path" /> |
代表外部存储(sdcard)的cache目录，与Environment.getExternalStorageDirectory()获取的路径对应。
|
1 |
<external-files-path name="name" path="path" /> |
代表app的外部存储的根目录，与Context#getExternalFilesDir(String) Context.getExternalFilesDir(null)获取的路径对应。
|
1 |
<external-cache-path name="name" path="path" /> |
代表app外部缓存区域的根目录，与Context.getExternalCacheDir()获取的路径对应。
|
1 |
<external-media-path name="name" path="path" /> |
代表app外部存储媒体区域的根目录，与Context.getExternalMediaDirs()获取的路径对应。
注意： 这个目录只在API 21（也就是Android 5.0）以上的系统上才存在。
为了让其他app使用Content Uri，我们的app必须提前生成Uri。
|
1 2 3 4 |
File filePath = new File(Context.getFilesDir(), "my_log"); File newFile = new File(filePath, "my_log.log"); // 生成Uri Uri contentUri = FileProvider.getUriForFile(getContext(), "com.example.app.fileprovider", newFile); |
这里注意获取目录，在配置paths时我们讲了，paths的子标签必须和获取目录的代码保持对应。这里我们用的是Context.getFilesDir(),所以paths文件中必须包含files-path子标签，不然别的app获取uri时会出现异常。
最终生成Uri是使用的FileProvider.getUriForFile()。第一个参数就是provider中设置的authorities属性值。
分享一般只有这读取和写入2种权限，根据需要传入Intent.addFlags()中。
|
1 2 3 |
// 这里用的是发送文件。 Intent intent = new Intent(Intent.ACTION_SEND); intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION); |
有好几种传入的方式，根据不同的场景使用不同的方式。
|
1 |
intent.putExtra(Intent.EXTRA_STREAM, contentUri); |
使用Intent.setDate或Intent.setClipData()。
|
1 |
intent.setClipDataClipData.newRawUri("", contentUri); |
最后使用startActivity(intent)启动分享操作。
目前遇到一个问题，mysql 使用 source 命令导入 *.sql 数据文件时，运行的很慢，大概一秒钟插入一两百条左右的样子，对于大的文件来说这个太慢了。
1.登入mysql
|
1 |
$ mysql -uroot -p*** |
2.查看mysql中对于参数 innodb_flush_log_at_trx_commit 的配置
|
1 |
show global variables where variable_name = 'innodb_flush_log_at_trx_commit'; |
3.修改
|
1 |
SET GLOBAL innodb_flush_log_at_trx_commit = 0; |
修改完成后在次执行相同的文件，200M大约200w+条的数据在1分钟左右。
对于该参数的不同值的说明：
1.innodb_flush_log_at_trx_commit参数为 0
binlog_group_flush && thd_flush_log_at_trx_commit(NULL) == 0 条件成立，因此直接return了，那么这种情况下log_buffer_flush_to_disk函数不会调用，因此不会做redo刷盘。依赖master线程。
2.innodb_flush_log_at_trx_commit参数为 1
!binlog_group_flush || thd_flush_log_at_trx_commit(NULL) == 1 返回为1即为True，因此调用log_buffer_flush_to_disk(True)，因此需要做redo刷盘，也要做sync。
3.innodb_flush_log_at_trx_commit参数为 2
!binlog_group_flush || thd_flush_log_at_trx_commit(NULL) == 1 返回为0即为Flase，因此调用log_buffer_flush_to_disk(Flase)，因此需要做redo刷盘，不做sync。依赖OS的刷盘机制。
参考例子如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
mysql -u root -p -h 127.0.0.1 mysql> use test; Database changed mysql> set global innodb_flush_log_at_trx_commit=0; Query OK, 0 rows affected (0.03 sec) mysql> set global sync_binlog=0; Query OK, 0 rows affected (0.03 sec) mysql> set global max_allowed_packet=1024*1024*512; Query OK, 0 rows affected (0.00 sec) mysql> set global bulk_insert_buffer_size=512*1024*1024; Query OK, 0 rows affected (0.00 sec) mysql> set global innodb_buffer_pool_size=512*1024*1024; Query OK, 0 rows affected, 1 warning (0.09 sec) mysql> source /root/test.sql |
实际测试结果感觉还是不够快。
Flutter 2.x 升级到 3.10.1 版本之后，原来正常编译的项目，iOS环境下（Xcode Version 13.2.1 (13C100)），编译报错：
|
1 2 3 4 5 |
$ ios % pod install Analyzing dependencies [!] Unable to find a target named `RunnerTests` in project `Runner.xcodeproj`, did find `Runner`. [!] Automatically assigning platform `iOS` with version `11.0` on target `Runner` because no platform was specified. Please specify a platform for this target in your Podfile. See `https://guides.cocoapods.org/syntax/podfile.html#platform`. |
继续阅读Unable to find a target named `RunnerTests` in project `Runner.xcodeproj`, did find `Runner`