上篇文章讲的是状态管理（传送门）提到了 Flutter BLoC ，相比与原生的 setState() 及Provider等有哪些优缺点，并结合实际项目写了一个简单的使用，接下来本篇文章来讲 Flutter 大型项目是如何进行分层设计的，费话不多说，直接进入正题哈。

为啥需要分层设计

其实这个没有啥固定答案，也许只是因为某一天看到手里的代码如同屎山一样，如下图，而随着业务功能的增加，不停的往这上面堆，这个屎山也会愈发庞大和混乱，如果这样继续下去，直到某一天因为一个小小的Bug，你需要花半天的时间来排查问题出在哪里，最后当你觉得问题终于改好了的时候，却不料碰了不该碰的地方，结果就是 fixing 1 bug will create 10 new bugs，甚至程序的崩溃。

随着这种问题的凸显，于是团队里的显眼包A提出了要求团队里的每个人都必须负责完成给自己写的代码添加注释和文档，规范命名等措施，一段时间后，发现代码是规范了，但问题依然存在，这时候才发现如果工程的架构分层没有做好，再规范的代码和注释也只是在屎山上雕花，治标不治本而已。

请原谅我打了一个这么俗的比方，但话糙理不糙，那么啥是应用的分层设计呢？

简单的来说，应用的分层设计是一种将应用程序划分为不同层级的方法，每个层级负责特定的功能或责任。其中表示层（Presentation Layer）负责用户界面和用户交互，将数据呈现给用户并接收用户输入；业务逻辑层（Business Logic Layer）处理应用程序的业务逻辑，包括数据验证、处理和转换；数据访问层（Data Access Layer）负责与数据存储交互，包括数据库或文件系统的读取和写入操作。

这样做有什么好处呢？一句话总结就是为了让代码层级责任清晰，维护、扩展和重用方便，每个模块能独立开发、测试和修改。

App 原生开发的分层设计

说到 iOS、Android 的分层设计，就会想到如 MVC、MVVM 等，它们主要是围绕着控制器层（Controller）、视图层（View）、和数据层（Model），还有连接 View 和 Model 之间的模型视图层（ViewModel）这些来讲的。

然而，MVC、MVVM 概念还不算完整的分层架构，它们只是关注的 App 分层设计当中的应用层（Applicaiton Layer）组织方式，对于一个简单规模较小的App来说，可能单单一个应用层就能搞定，不用担心业务增量和复杂度上升对后期开发的压力，而一旦 App 上了规模之后就有点应付不过来了。

当 App 有了一定规模之后，必然会涉及到分层的设计，还有模块化、Hybrid 机制、数据库、跨项目开发等等，拿 iOS 的原生分层设计落地实践来说，通常会将工程拆分成多个Pod私有库组件，拆分的标准视情况而定，每一个分层组件是独立的开发和测试，再在主工程添加 Pod 私有库依赖来做分层设计开发。

此处应该有 Pod 分层组件化设计的配图，但是太懒了，就没有一个个的去搭建新项目和 Pod 私有库，不过 iOS 原生分层设计不是本篇文章的重点，本篇主要谈论的是 Flutter App 的分层设计。

Flutter 的分层设计

分层架构设计的理念其实是相通的，差别在于语言的特性和具体项目实施上，Flutter 项目也是如此。试想一下，当各种逻辑混合在一次的时候，即便是选择了像 Bloc 这样的状态管理框架来隔离视图层和逻辑实现层，也很难轻松的增强代码的拓展性，这时候选择采用一个干净的分层架构就显得尤为重要，怎样做到这一点呢，就需要将代码分成独立的层，并依赖于抽象而不是具体的实现。

Flutter App 想要实现分层设计，就不得不提到包管理工具，如果在将所有分层组件代码放在主工程里面，那样并不能达到每个组件单独开发、维护和测试的目的，而如果放在新建的 Dart Package 中，没发跨多个组件改代码和测试，无法实现本地包链接和安装。使用 melos 就能解决这个问题，类似于 iOS 包管理工具 Pod, 而 melos 是 Flutter 项目的包管理工具。

组件包管理工具

Flutter 分层设计实践

接下来介绍一下上面创建的几个组件库。

• app：项目的主工程，存放业务逻辑代码、 UI 页面和 Bloc，还有 styles、colors 等等。


• domain：实体类（entity）组件包，还有一些接口类，如 repository、usercase等。


• data：数据提供组件包，主要有：api_request，database、shared_preference等，该组件包所有的调用实现都在 domain 中接口 repository 的实现类 repository_impl 中。


• shared：工具类组件包，包括：util、helper、enum、constants、exception、mixins等等。


• resources：资源类组件包，有intl、公共的images等


• initializer：模块初始化组件包。


• widgets：公共的 UI 组件包，如常用的：alert、button、toast、slider 等等。

它们之间的调用关系如下图：

其中 shared 和 resources 作为基础组件包，本身不依赖任何组件，而是给其它组件包提供支持。

作为主工程 App 也不会直接依赖 data 组件包，其调用是通过 domain 组件包中 UseCase 来实现，在 UseCase 会获取数据、处理列表数据的分页、参数校验、异常处理等等，获取数据是通过调用抽象类 repository 中相关函数，而不是直接调用具体实现类，此时App 的 pubspec.yaml 中配置是这样的：

name: app

description: A new Flutter project.

publish_to: 'none' # Remove this line if you wish to publish to pub.dev

version: 1.0.0+1



environment:

  sdk: ">=2.17.0 <3.0.0"



dependencies:

  flutter:

    sdk: flutter

  cupertino_icons: ^1.0.2

  widgets:

    path: ../widgets

  shared:

    path: ../shared

  domain:

    path: ../domain

  resources:

    path: ../resources

  initializer:

    path: ../initializer



dev_dependencies:

  flutter_test:

    sdk: flutter



flutter:

  uses-material-design: true

  generate: false

  assets:

    - assets/images/

提供的数据组件包 data 实现了抽象类 repository 中相关函数，只负责调用 Api 接口获取数据，或者从数据库获取数据。当上层调用的时候不需要关心数据是从哪里来的，全部交给 data 组件包负责。

initializer 作为模块初始化组件包，仅有一个 AppInitializer 类，其主要目的是将其它的模块的初始化收集起来放在 AppInitializer 类中 init() 函数中，然后在主工程入口函数：main() 调用这个 init() 函数，常见的初始化如：GetIt 初始化、数据库 objectbox 初始化、SharedPreferences初始化，这些相关的初始会分布在各自的组件包中。

class AppInitializer {

  AppInitializer();



  Future<void> init() async {

    await SharedConfig.getInstance().init();

    await DataConfig.getInstance().init();

    await DomainConfig.getInstance().init();

  }

}

widgets 作为公共的 UI 组件库，不处理业务逻辑，在多项目开发时经常会使用到。上图中的 Other Plugin Module 指的的是其它组件包，特别是需要单独开发与原生交互的插件时会用到，

这种分层设计出来的架构或许在开发过程中带来一下不便，如调用一个接口，第一步：需要先在抽象类 repository 写好函数声明；第二步：然后再去Api Service 写具体请求代码，并在repository_impl 实现类中调用；第三步：还需要在 UserCase 去做业务调用，错误处理等；最后一步：在bloc的event中调用。这么一趟下来，确实有些繁琐或者说是过度设计。但是如果维度设定在大的项目中多人合作开发的时候，却能规避很多问题，每个分层组件都有自己的职责互不干扰，都支持单独的开发测试，尽可能的做到依赖于抽象而不是具体的实现。

本篇文章就到这里，源码后面这个系列的文章里放出来，感谢您的阅读，也希望您能关注我的公众号 Flutter技术实践，原创不易，您的关注是我更新下去最大的动力。

前一段时间有个 App 很火，是 Android App 利用了 Android 系统漏洞，获得了系统权限，做了很多事情。想看看这些个 App 在利用系统漏洞获取系统权限之后，都干了什么事，于是就有了这篇文章。由于准备仓促，有些 Code 没有仔细看，感兴趣的同学可以自己去研究研究，多多讨论，对应的文章和 Code 链接都在下面：

关于这个 App 是如何获取这个系统权限的，Android 反序列化漏洞攻防史话，这篇文章讲的很清楚，就不再赘述了，我也不是安全方面的专家，但是建议大家多读几遍这篇文章

序列化和反序列化是指将内存数据结构转换为字节流，通过网络传输或者保存到磁盘，然后再将字节流恢复为内存对象的过程。在 Web 安全领域，出现过很多反序列化漏洞，比如 PHP 反序列化、Java 反序列化等。由于在反序列化的过程中触发了非预期的程序逻辑，从而被攻击者用精心构造的字节流触发并利用漏洞从而最终实现任意代码执行等目的。

这篇文章主要来看看 XXX apk 内嵌提权代码，及动态下发 dex 分析 这个库里面提供的 Dex ，看看 App 到底想知道用户的什么信息？总的来说，App 获取系统权限之后，主要做了下面几件事（正常 App 无法或者很难做到的事情），各种不把用户当人了。

另外也可以看到，这个 App 对于各个手机厂商的研究还是比较深入的，针对华为、Oppo、Vivo、Xiaomi 等终端厂商都有专门的处理，这个也是值得手机厂商去反向研究和防御的。

最好我还加上了这篇文章在微信公众号发出去之后的用户评论，以及知乎回答的评论区（问题已经被删了，但是我可以看到：如何评价拼多多疑似利用漏洞攻击用户手机，窃取竞争对手软件数据，防止自己被卸载？ - Gracker 的回答 - 知乎 http://www.zhihu.com/question/58… 2471 个赞）可以说是脑洞大开（关于 App 如何作恶）。

0. Dex 文件信息

本文所研究的 dex 文件是从 XXX apk 内嵌提权代码，及动态下发 dex 分析 这个仓库获取的，Dex 文件总共有 37 个，不多，也不大，慢慢看。这些文件会通过后台服务器动态下发，然后在 App 启动的时候进行动态加载，可以说是隐蔽的很，然而 Android 毕竟是开源软件，要抓你个 App 的行为还是很简单的，这些 Dex 就是被抓包抓出来的，可以说是人脏货俱全了。

由于是 dex 文件，所以直接使用 github.com/tp7309/TTDe… 这个库的反编译工具打开看即可，比如我配置好之后，直接使用 showjar 这个命令就可以

showjar 95cd95ab4d694ad8bdf49f07e3599fb3.dex

默认是用 jadx 打开，就可以看到反编译之后的内容，我们重点看 Executor 里面的代码逻辑即可

打开后可以看到具体的功能逻辑，可以看到一个 dex 一般只干一件事，那我们重点看这件事的核心实现部分即可

1. 通知监听和通知权限相关

1.1 获取 Xiaomi 手机通知内容

1. 反射拿到 ServiceManager

一般我们会通过 ServiceManager 的 getService 方法获取系统的 Service，然后进行远程调用

2. 通过 NotificationManagerService 获取通知的详细内容

通过 getService 传入 NotificationManagerService 获取 NotificationManager 之后，就可以调用 getActiveNotifications 这个方法了，然后具体拿到 Notification 的下面几个字段

可能有人不知道这玩意是啥，下面这个图里面就是一个典型的通知

其代码如下

可以看到 getActiveNotifications 这个方法，是 System-only 的，普通的 App 是不能随便读取 Notification 的，但是这个 App 由于有权限，就可以获取

当然微信的防撤回插件使用的一般是另外一种方法，比如辅助服务，这玩意是合规的，但是还是推荐大家能不用就不用，它能帮你防撤回，他就能获取通知的内容，包括你知道的和不知道的

1.2. 打开 Xiaomi 手机上的通知权限（Push）

这么看来这个应该还是蛮实用的，你个调皮的用户，我发通知都是为了你好，你怎么忍心把我关掉呢？让我帮你偷偷打开吧

App 调用 NotificationManagerService 的 setNotificationsEnabledForPackage 来设置通知，可以强制打开通知

frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java

然后查看 NotificationManagerService 的 setNotificationsEnabledForPackage 这个方法，就是查看用户是不是打开成功了

frameworks/base/services/core/java/com/android/server/notification/NotificationManagerService.java

还有针对 leb 的单独处理～细 ！

1.3. 打开 Vivo 机器上的通知权限（Push）

核心和上面那个是一样的，只不过这个是专门针对 vivo 手机的

1.4 打开 Oppo 手机的通知权限

没有反编译出来，看大概的逻辑应该是打开 App 在 oppo 手机上的通知权限

1.5 Notification 监听

这个就有点厉害了，在监听 App 的 Notification 的发送，然后进行统计

监听的核心代码

这个咱也不是很懂，是时候跟做了多年 SystemUI 和 Launcher 的老婆求助了....@史工

1.6 App Notification 监听

上面那个是 UdNotificationListenerExecutor ， 这个是 NotificationListenerExecutor，UD 是啥？

这个反射调用的 setNotificationListenerAccessGranted 是个 SystemAPI，获得通知的使用权，果然有权限就可以为所欲为

1.7 打开华为手机的通知监听权限

华为也无法幸免，哈哈哈

1.8 打开华为手机通知权限

2. Backup 状态

2.1. 鸿蒙 OS 上 App Backup 状态相关，保活用？

这个看了半天，应该是专门针对华为手机的，收到 IBackupSessionCallback 回调后，执行 PackageManagerEx.startBackupSession 方法

查了下这个方法的作用，启动备份或恢复会话

2.2. Vivo 手机 Backup 状态相关

3. 文件相关

3.1 获取华为手机 SLog 和 SharedPreferences 内容

拿这个干嘛呢？拿去做数据分析？

获取 SharedPreferences

获取 slog

4. 用户数据

4.1 获取用户使用手机的数据

看核心逻辑是同 usagestates 服务，来获取用户使用手机的数据，难怪我手机安装了什么 App、用了多久这些，其他 App 了如指掌

那么他可以拿到哪些数据呢？应有尽有～，包括但不限于 App 启动、退出、挂起、Service 变化、Configuration 变化、亮灭屏、开关机等，感兴趣的可以看一下：

frameworks/base/core/java/android/app/usage/UsageEvents.java

    private static String eventToString(int eventType) {

        switch (eventType) {

            case Event.NONE:

                return "NONE";

            case Event.ACTIVITY_PAUSED:

                return "ACTIVITY_PAUSED";

            case Event.ACTIVITY_RESUMED:

                return "ACTIVITY_RESUMED";

            case Event.FOREGROUND_SERVICE_START:

                return "FOREGROUND_SERVICE_START";

            case Event.FOREGROUND_SERVICE_STOP:

                return "FOREGROUND_SERVICE_STOP";

            case Event.ACTIVITY_STOPPED:

                return "ACTIVITY_STOPPED";

            case Event.END_OF_DAY:

                return "END_OF_DAY";

            case Event.ROLLOVER_FOREGROUND_SERVICE:

                return "ROLLOVER_FOREGROUND_SERVICE";

            case Event.CONTINUE_PREVIOUS_DAY:

                return "CONTINUE_PREVIOUS_DAY";

            case Event.CONTINUING_FOREGROUND_SERVICE:

                return "CONTINUING_FOREGROUND_SERVICE";

            case Event.CONFIGURATION_CHANGE:

                return "CONFIGURATION_CHANGE";

            case Event.SYSTEM_INTERACTION:

                return "SYSTEM_INTERACTION";

            case Event.USER_INTERACTION:

                return "USER_INTERACTION";

            case Event.SHORTCUT_INVOCATION:

                return "SHORTCUT_INVOCATION";

            case Event.CHOOSER_ACTION:

                return "CHOOSER_ACTION";

            case Event.NOTIFICATION_SEEN:

                return "NOTIFICATION_SEEN";

            case Event.STANDBY_BUCKET_CHANGED:

                return "STANDBY_BUCKET_CHANGED";

            case Event.NOTIFICATION_INTERRUPTION:

                return "NOTIFICATION_INTERRUPTION";

            case Event.SLICE_PINNED:

                return "SLICE_PINNED";

            case Event.SLICE_PINNED_PRIV:

                return "SLICE_PINNED_PRIV";

            case Event.SCREEN_INTERACTIVE:

                return "SCREEN_INTERACTIVE";

            case Event.SCREEN_NON_INTERACTIVE:

                return "SCREEN_NON_INTERACTIVE";

            case Event.KEYGUARD_SHOWN:

                return "KEYGUARD_SHOWN";

            case Event.KEYGUARD_HIDDEN:

                return "KEYGUARD_HIDDEN";

            case Event.DEVICE_SHUTDOWN:

                return "DEVICE_SHUTDOWN";

            case Event.DEVICE_STARTUP:

                return "DEVICE_STARTUP";

            case Event.USER_UNLOCKED:

                return "USER_UNLOCKED";

            case Event.USER_STOPPED:

                return "USER_STOPPED";

            case Event.LOCUS_ID_SET:

                return "LOCUS_ID_SET";

            case Event.APP_COMPONENT_USED:

                return "APP_COMPONENT_USED";

            default:

                return "UNKNOWN_TYPE_" + eventType;

        }

    }

4.2 获取用户使用数据

上面那个是 UsageEventAllExecutor，这个是 UsageEventExecutor，主要拿用户使用 App 相关的数据，比如什么时候打开某个 App、什么时候关闭某个 App，6 得很，真毒瘤

4.3 获取用户使用数据

看样子是注册了 App Usage 的权限，具体 Code 没有出来，不好分析

5. Widget 和 icon 相关

经吃瓜群众提醒，App 可以通过 Widget 伪造一个 icon，用户在长按图标卸载这个 App 的时候，你以为卸载了，其实是把他伪造的这个 Widget 给删除了，真正的 App 还在 （不过我没有遇到过，这么搞真的是脑洞大开，且不把 Android 用户当人）

5.1. Vivo 手机添加 Widget

这个比较好理解，在 Vivo 手机上加个 Widget

5.2 获取 icon 相关的信息

这个好理解，获取 icon 相关的信息，比如在 Launcher 的哪一行，哪一列，是否在文件夹里面。问题是获取这玩意干嘛？？？迷

5.3 Oppo 手机添加 Widget

5.4 Xiaomi 手机更新图标？

小米手机上的桌面 icon 、shorcut 相关的操作，小米的同学来认领

6. 自启动、关联启动、保活相关

6.1 打开 Oppo 手机自启动

看下面这一堆就知道是和自启动相关的，看来自启动权限是每个 App 都蛋疼的东西啊

6.2 打开 Vivo 关联启动权限

看名字就是和关联启动相关的权限，vivo 的同学来领了

直接写了个节点进去

6.3 关闭华为耗电精灵

看名字和实现，应该是和华为的耗电精灵有关系，华为的同学可以来看看

6.4 Vivo 机型保活相关

猜测和保活相关，Vivo 的同学可以来认领一下

7. 安装卸载相关

7.1 Vivo 手机回滚卸载

这个看上去像是用户卸载 App 之后，回滚到预置的版本，好吧，这个是常规操作

7.2 Vivo 手机 App 卸载

看名字和实现，也是和卸载回滚相关的

7.3 Vivo 手机 App 卸载相关

同上

其他

SyncExecutor

没看懂是干嘛的，核心应该是 Utils.updateSid ，但是没看到实现的地方

UdParseNotifyMessageExecutor

看名字应该是解析从远端传来的 Notify Message，具体功能未知

TDLogcatExecutor

没太看懂这个是干嘛的，像是保活又不像，后面有时间了再慢慢分析

QueryLBSInfoExecutor

获取 LBS Info

WriteSettingsExecutor

看名字应该是个工具类，写 Settings 字段的，至于些什么应该是动态下发的

OppoSettingExecutor

Setting 代理？？没看懂干嘛的，Oppo 的同学来认领，难道是另外一种形式的保活？

CheckAsterExecutor

Check aster ？不是很懂

OppoCommunityIdExecutor

获取 Oppo 用户的 ID？要这玩意干么？

GetSettingsUsernameExecutor

获取 Oppo 手机用户的 username，话说你要这个啥用咧？

LogcatExecutor

配置 Log 的参数

VivoBrowserSettingsExecutor

Vivo 浏览器相关的设置，不太懂要干嘛

评论区比文章更精彩

微信公众号评论区

知乎评论区

知乎回答已经被删了，我通过主页可以看到，但是点进去是已经被删了：如何评价拼多多疑似利用漏洞攻击用户手机，窃取竞争对手软件数据，防止自己被卸载？ - Gracker 的回答 - 知乎 http://www.zhihu.com/question/58…

iOS 和 Android 哪个更安全？

这里就贴一下安全大佬 sunwear 的评论

关于我 && 博客

一个人可以走的更快 ， 一群人可以走的更远

背景

在半年前的某一天，一个运行一年的项目被人提了建议，希望有一个tabs页面，因为他需要多个页面找东西。

我：滚，自己开浏览器标签页（此处吹牛逼）

项目经理：我审核的时候也需要看别人提交的数据是否正确，我也需要看，很多人提了建议

我：作为一个合格的外包，肯定以项目经理体验为主（狗头保命）

1 React的Keepalive

简单实现React KeepAlive不依赖第三方库(附源码)React KeepAlive 实现，不依赖第三方库，支持 - 掘金
神说要有光《React通关秘籍》

....还有一些没有收藏的keepalive实现

代码不想多赘述，我找了很多资料基本思路讲一下

基本是通过react-router来实现

• 弄一个map来存储{path:<OutLet|useOutlet>}


• 然后根据当前路由path来决定哪些组件需要渲染，不渲染的hidden


• 然后在最外层布局套一层Tabs布局用react的context来传递

出现的问题是：

就是当依赖项是一个公共数据的时候，useEffect会触发，如图片中的searchParams同名的key、存在state内存中的同名key之类的

详情页打开多个，地址栏清一色pkId的情况

使用的是ant design pro v6，也是看到有加配置就可以用Keepalive，大家可以掘金找找，我测试过也是有一样的问题，但是和目前能找到功能差不多了，免去自己封装

看很多react Keepalive的实现目前是还没找到什么方案，也皮厚的找过神光，但是要是知道我是被人忽悠了，绝对不会去打扰大佬

tip：先自己敲，再问，不要让自己陷于蠢逼的尴尬

发现问题后，我去问日常开发Vue的童鞋们，因为我两年没写vue了，我说：你们是怎么实现tabs布局的，Vue的Keepalive是怎么实现只有显示哪个页面，别的组件存储而不运行watch的，然后说了一下我在react开发tabs的时候尴尬。

Vueer：vue不会有这个问题，自带的Keepalive封装的很完美，react没有这个功能吗？

就这样我信了半年,但是这个bug我说，我只能到这种程度了，要是说新项目还可以再useEffect再封装一层自定义的hooks，增加一点心智负担，让别人用封装的来，再useEffect内做判断是否是显示的path之类的。

这边年来反正这个功能做了一个开关，项目经理自己用，别人要是没问也不告诉别人有开发这东西，嘿嘿嘿

之所以又捞起来是别的几个项目也有人问，然后问我能不能迁移给别的项目，那他妈不得王炸，别的项目有的还是umi3没升级的。

2 vue3的Keepalive

先说结论吧：vue的Keepalive也能解决这个问题，纯属胡扯

实在想不到什么好的方案，闲余时间，就用vue写了一个demo，想看看vue是怎么实现的，因为react除了就是hidden，或者超出overflow 然后切换是平移像轮播图一样，实在想不出什么方案能保存原本的数据了。

<template>

  home

  <ul>

    <li v-for="item in router.getRoutes().filter(r=>r.path!=='/')" @click="liHandler(item)">

      {{ item.path }}

    </li>

  </ul>

</template>

<script lang="ts" setup>

import {useRouter} from "vue-router";



const router = useRouter()



const liHandler = (route) => {

  router.push({name: route.name, query: {path: route.path}})

}

</script>

简单来个demo的目录结构和代码，代码是会有问题的代码，不用细看...

两年没写vue还是遇到几个坑，先记录一下

2.1 vue3的routerview不能写在keepAlive内

// home.vue

<template>

  <!--  <RouterView v-slot="{Component}">-->

  <!--    <KeepAlive>-->

  <!--      <component :is="Component"/>-->

  <!--    </KeepAlive>-->

  <!--  </RouterView>-->



  <KeepAlive>

    <RouterView></RouterView>

  </KeepAlive>

</template>

注释掉的是正确的，这里不提一嘴，vue的console.log的体验感很ok，下面列的就是正确的，我还去百度了为啥Keepalive无效，直到截这张图写这文的时候才看到，人家都谢了，哈哈哈哈

2.2 router.push地址不变

主要原因是路由创建的是
createMemoryHistory 这玩意不知道是啥 没用过，我是复制vueRoute官网demo的，一开始没注意，改成createWebHistory就好

import {createRouter, createWebHistory} from "vue-router";



const routes = [

    {path: "/", component: () => import("./components/Home.vue")},

    {path: "/aaa", component: () => import("./components/Aaa.vue"), name: 'aaa'},

    {path: "/bbb", component: () => import("./components/Bbb.vue"), name: 'bbb'},

    {path: "/ccc", component: () => import("./components/Ccc.vue"), name: 'ccc'},

    {path: "/ddd", component: () => import("./components/Ddd.vue"), name: 'ddd'},

]

const router = createRouter({

    history: createWebHistory(),

    routes,

})



export default router

2.3 router.push不拼接?传参

router.push(path, query: {path}})

一开始是这么写的，用path+query，这个问题纯粹弱智了，太久没写有点菜，改成name+query就行

2.4 vue Keepalive测试

我先点了去aaa，然后返回首页点ccc，这里可以看到，aaa页面的watch触发了！触发了！触发了！

然后去看了下源码，简约版如下

const KeepAliveImpl = {

  name: `KeepAlive`,



  // 私有属性 标记 该组件是一个KeepAlive组件

  __isKeepAlive: true,

  props: {

    // 用于匹配需要缓存的组件

    include: [String, RegExp, Array],

    // 用于匹配不需要缓存的组件

    exclude: [String, RegExp, Array],

    // 用于设置缓存上线

    max: [String, Number]

  },

  setup(props, { slots }) {

    // 省略部分代码...



    // 返回一个函数

    return () => {

      if (!slots.default) {

        return null

      }

      

      // 省略部分代码...

      

      // 获取子节点

      const children = slots.default()

      // 获取第一个子节点

      const rawVNode = children[0]

      // 返回原始Vnode

      return rawVNode

    }

  }

}

这不就是存下来了children，但是有个有意思的是

前面说过，react是通过缓存住组件，然后用hidden来控制展示哪个隐藏哪个，vue这边的dom渲染出来不是。

官网也说了动态组件是会卸载的

3 分析一波

直接用光哥的代码跑起来，这么一比可以看出来dom上的差异

然后把代码的显示改成判断语句渲染，测试一下

测试图：

然后去首页，再回到/bbb，发现数字又变回0了

先来看下React的渲染，通过卡颂大佬的文章，找到了react在render阶段

500行左右

这是判断是mountd还是update的一个标志，然而我们已经卸载了，这里肯定是null，那么就会去创建组建，仅仅是创建。

而vue因为自身有keepalive，在render阶段，是有对标志为keepalive的做patch的逻辑

所以keepalive的组件不会再走created和mounted，而是直接进行diff进行parch

总结

• 公共参数无论是vue还是react都会被监听到


• react想要实现像vue一样的效果只能等react官方适配

也是有提过啦

《如何写出高质量的前端代码》学习笔记

在日常开发中，我们经常会遇到需要修改同事代码的情况。有时可能会花费很长时间却只改动了几行代码，而且改完后还可能引发新的bug。我们聊聊导致代码难以维护的常见原因，以及相应的解决方案。

常见问题及解决方案

1. 单文件代码过长

问题描述：

• 单个文件动辄几千行代码


• 包含大量DOM结构、JS逻辑和样式


• 需要花费大量时间才能理解代码结构

解决方案： 将大文件拆分成多个小模块，每个模块负责独立的功能。

以一个品牌官网为例，可以这样拆分：

<template>

  <div>

    <Header/>

    <main>

      <Banner/>

      <AboutUs/>

      <Services/> 

      <ContactUs/>

    </main>

    <Footer/>

  </div>

</template>

2. 模块耦合严重

问题描述：

• 模块之间相互依赖


• 修改一处可能影响多处


• 难以进行单元测试

❌ 错误示例：

<script>

export default {

  methods: {

    getUserDetail() {

      // 错误示范：多处耦合

      let userId = this.$store.state.userInfo.id 

        || window.currentUserId

        || this.$route.params.userId;

      

      getUser(userId).then(res => {

        // 直接操作子组件内部数据

        this.$refs.userBaseInfo.data = res.baseInfo;

        this.$refs.userArticles.data = res.articles;

      })

    }

  }

}

</script>

✅ 正确示例：

<template>

  <div>

    <userBaseInfo :base-info="baseInfo"/>

    <userArticles :articles="articles"/>

  </div>

</template>



<script>

export default {

  props: ['userId'],

  data() {

    return {

      baseInfo: {},

      articles: []

    }

  },

  methods: {

    getUserDetail() {

      getUser(this.userId).then(res => {

        this.baseInfo = res.baseInfo；

        this.articles = res.articles；

      })

    }

  }

}

</script>

3. 职责不单一

问题描述：

• 一个方法承担了多个功能


• 代码逻辑混杂在一起


• 难以复用和维护

❌ 错误示例：

<script>

export default {

  methods: {

    getUserData() {

      userService.getUserList().then(res => {

        this.userData = res.data；

        // 一个方法中做了太多事情

        let vipCount = 0；

        let activeVipsCount = 0；

        let activeUsersCount = 0；

        

        this.userData.forEach(user => {

          if(user.type === 'vip') {

            vipCount++

          }

          if(dayjs(user.loginTime).isAfter(dayjs().subtract(30, 'day'))) {

            if(user.type === 'vip') {

              activeVipsCount++

            }

            activeUsersCount++

          }

        })

        

        this.vipCount = vipCount；

        this.activeVipsCount = activeVipsCount；

        this.activeUsersCount = activeUsersCount；

      })

    }

  }

}

</script>

✅ 正确示例：

<script>

export default {

  computed: {

    // 将不同统计逻辑拆分为独立的计算属性

    activeUsers() {

      return this.userData.filter(user => 

        dayjs(user.loginTime).isAfter(dayjs().subtract(30, 'day'))

      )

    },

    vipCount() {

      return this.userData.filter(user => user.type === 'vip').length

    },

    activeVipsCount() {

      return this.activeUsers.filter(user => user.type === 'vip').length

    },

    activeUsersCount() {

      return this.activeUsers.length

    }

  },

  methods: {

    getUserData() {

      // 方法只负责获取数据

      userService.getUserList().then(res => {

        this.userData = res.data；

      })

    }

  }

}

</script>

4. 代码复制代替复用

问题描述：

• 发现相似功能就直接复制代码


• 维护时需要修改多处相同的代码


• 容易遗漏修改点，造成bug

解决方案：

• 提前抽取公共代码


• 将重复逻辑封装成独立函数或组件


• 通过参数来处理细微差异

5. 强行复用/假装复用

问题描述：

将不该复用的代码强行糅合在一起，比如：

• 将登录弹窗和修改密码弹窗合并成一个组件


• 把一个实体的所有操作（增删改查）都塞进一个方法

❌ 错误示例：

<template>

  <div>

    <UserManagerDialog ref="UserManagerDialog"/>

  </div>

</template>



<script>

export default {

  methods: {

    addUser() {

      this.$refs.UserManagerDialog.showDialog({

        type: 'add'

      })

    },

    editName() {

      this.$refs.UserManagerDialog.showDialog({

        type: 'editName'

      })

    },

    deleteUser() {

      this.$refs.UserManagerDialog.showDialog({

        type: 'delete'

      })

    }

  }

}

</script>

✅ 正确做法：

• 不同业务逻辑使用独立组件


• 只抽取真正可复用的部分（如表单验证规则、公共UI组件等）


• 保持每个组件职责单一

6. 破坏数据一致性

问题描述： 使用多个关联状态来维护同一份数据，容易造成数据不一致。

❌ 错误示例：

<script>

export default {

  data() {

    return {

      sourceData: [], // 原始数据

      tableData: [], // 过滤后的数据

      name: '', // 查询条件

      type: ''

    }

  },

  methods: {

    nameChange(name) {

      this.name = name;

      // 手动维护 tableData，容易遗漏

      this.tableData = this.sourceData.filter(item => 

        (!this.name || item.name === this.name) && 

        (!this.type || item.type === this.type)

      );

    },

    typeChange(type) {

      this.type = type;

      // 重复的过滤逻辑

      this.tableData = this.sourceData.filter(item => 

        (!this.name || item.name === this.name) && 

        (!this.type || item.type === this.type)

      );

    }

  }

}

</script>

✅ 正确示例：

<script>

export default {

  data() {

    return {

      sourceData: [],

      name: '',

      type: ''

    }

  },

  computed: {

    // 使用计算属性自动维护派生数据

    tableData() {

      return this.sourceData.filter(item =>

        (!this.name || item.name === this.name) && 

        (!this.type || item.type === this.type)

      )

    }

  }

}

</script>

7. 解决方案不“正统”

问题描述：

使用不常见或不合理的方案解决问题，如：

• 直接修改 node_modules 中的代码，更好的实践：
  
  
  
  
  • 优先使用框架/语言原生解决方案
  
  
  • 遵循最佳实践和设计模式
  
  
  • 进行方案评审和代码审查
  
  
  • 对于第三方库的 bug：
    
    
    
    
    • 向作者提交 issue 或 PR
    
    
    • 将修改后的包发布到企业内部仓库
    
    
    • 寻找替代方案
    
    
    
    
  
  
  
  


• 使用 JS 实现纯 CSS 可实现的效果

❌ 错误示例：

// 不恰当的鼠标悬停效果实现

element.onmouseover = function() {

  this.style.color = 'red';

}

element.onmouseout = function() {

  this.style.color = 'black';

}

✅ 正确示例：

/* 使用 CSS hover 伪类 */

.element:hover {

  color: red;

}

• 过度使用全局变量

如何进行代码重构

重构的原则

重构示例

以下展示如何一步步重构上面的统计代码：

第一步：抽取 vipCount

• 删除data中的vipCount


• 增加计算属性vipCount，将getUserData中关于vipCount的逻辑挪到这里


• 删除getUserData中vipCount的计算逻辑

<script>

export default {

  computed: {

    vipCount() {

      return this.userData.filter(user => user.type === 'vip').length

    }

  },

  methods: {

    getUserData() {

      userService.getUserList().then(res => {

        this.userData = res.data；

        let activeVipsCount = 0；

        let activeUsersCount = 0；

        

        this.userData.forEach(user => {

          if(dayjs(user.loginTime).isAfter(dayjs().subtract(30, 'day'))) {

            if(user.type === 'vip') {

              activeVipsCount++

            }

            activeUsersCount++

          }

        })

        

        this.activeVipsCount = activeVipsCount；

        this.activeUsersCount = activeUsersCount；

      })

    }

  }

}

</script>

完成本次更改后，测试下各项数据是否正常，不正常查找原因，正常我们继续。

第二步：抽取 activeVipsCount

• 删除data中的activeVipsCount


• 增加计算属性activeVipsCount，将getUserData中activeVipsCount的计算逻辑迁移过来


• 删除getUserData中关于activeVipsCount计算的代码

<script>

export default {

  computed: {

    vipCount() {

      return this.userData.filter(user => user.type === 'vip').length

    },

    activeVipsCount() {

      return this.userData.filter(user => 

        user.type === 'vip' && 

        dayjs(user.loginTime).isAfter(dayjs().subtract(30, 'day'))

      ).length

    }

  },

  methods: {

    getUserData() {

      userService.getUserList().then(res => {

        this.userData = res.data；

        let activeUsersCount = 0；

        

        this.userData.forEach(user => {

          if(dayjs(user.loginTime).isAfter(dayjs().subtract(30, 'day'))) {

            activeUsersCount++

          }

        })

        

        this.activeUsersCount = activeUsersCount；

      })

    }

  }

}

</script>

...

最终版本：

<script>

export default {

  computed: {

    activeUsers() {

      return this.userData.filter(user => 

        dayjs(user.loginTime).isAfter(dayjs().subtract(30, 'day'))

      )

    },

    vipCount() {

      return this.userData.filter(user => user.type === 'vip').length

    },

    activeVipsCount() {

      return this.activeUsers.filter(user => user.type === 'vip').length

    },

    activeUsersCount() {

      return this.activeUsers.length

    }

  },

  methods: {

    getUserData() {

      userService.getUserList().then(res => {

        this.userData = res.data；

      })

    }

  }

}

</script>

总结

要写出易维护的代码，需要注意：

记住：重构是一个渐进的过程，不要试图一次性完成所有改进。在保证功能正常的前提下，通过小步快跑的方式逐步优化代码质量。

前言

本文介绍通过抓包的方式，分析出某影音app的去广告逆向点，难度极低，适合新手上路。

所谓逆向，三分逆，七分猜。

分析过程

首先打开app，可以看到不时有广告弹出。我们的目标就是去除这些广告。

首先想到的思路是定位到加载广告的代码删掉即可，使用 MT 管理器查看安装包的 dex 文件，可以看到大量 a、b、c 的目录，可见代码被混淆过的，直接上手分析太费劲了。

接着猜测，既然 app 能动态加载各种广告，必然会发起 http 网络请求，只需要分析出哪些请求是和广告相关的，将其拦截，即可实现去广告的目的。

所以接下来尝试抓包分析一下。

抓 http 请求推荐使用 Burp Suite，使用社区版即可。

打开 Burp Suite，切换到 Proxy 页。Proxy 即创建一个代理服务器，配置所有的网络请求连接到这个代理服务器，就可以看到所有经过代理服务器的 http 请求，并且能拦截修改请求、丢弃请求。

打开 Proxy settings，编辑默认的代理服务器地址配置。

端口号我这里填写 8888，地址选择当前机器的 ip 地址，与 ipconfig 命令显示的 ip 保持一致。

确定后选择导出 DER 格式的证书。

任意取名，文件扩展名为 .cer。

由于抓包需要电脑与手机在同一网络环境下， 因此建议使用安卓模拟器。

将 cer 文件导入到安卓模拟器中，之后打开设置 - 安全 - 加密与凭据 - 从SD卡安装（不同安卓会有所不同）。

选择 cer 文件后，随意命名，凭据用途选择 WLAN。确定后安装成功。

编辑当前连接的 wifi，设置代理为手动，主机名和端口填我们在 Burp Suite 中填写的内容。

打开 Burp Suite 打开代理拦截。

此时重新打开app，可以看到 Burp Suite 成功拦截了一条网络请求，并且app卡在启动页上。

此时点击 Drop （丢弃该请求），该请求会重发又被拦截，全部 Drop 掉。

此时惊喜的发现，进入了app首页，并且没有任何广告弹窗了。

由此可见，启动app时首先会加载 json 配置，根据配置去加载广告，只要将这条请求去掉就可以达到去广告的目的。只需要到app中反编译搜索拦截到的请求 url ，即可定位到拉取广告的代码。

搜索 sjmconfig，即可定位到目标代码。

将域名修改为 localhost，那么这条请求将永远不会成功。

之后保存修改、签名，重新安装，完事收工。

在Web开发中，将HTML页面转换为PDF文件是一项常见的需求。无论是生成报告、发票、还是其他任何需要打印或以PDF格式分发的文档，开发者都需要一个既简单又可靠的解决方案。幸运的是，pdfmake.js库以其轻量级、高性能和易用性，成为了许多开发者的首选。本文将介绍如何使用这个拥有11K Star的GitHub项目来实现HTML到PDF的转换。

什么是pdfmake.js

pdfmake.js是一个基于JavaScript的库，用于在客户端和服务器端生成PDF文档。它允许开发者使用HTML和CSS来设计PDF文档的布局和样式，使得创建复杂的PDF文档变得异常简单。

为什么选择pdfmake.js

• pdfmake.js的文件大小仅为11KB（压缩后），这使得它成为Web应用中一个非常轻量级的解决方案


• 拥有超过11K Star的GitHub项目，pdfmake.js得到了广泛的社区支持和认可，稳定性和可靠性值得信任


• 功能丰富，它支持表格、列表、图片、样式、页眉页脚等多种元素，几乎可以满足所有PDF文档的需求。


• pdfmake.js可以轻松集成到任何现有的Web应用中，无论是使用Node.js、Angular、React还是Vue.js。

快速开始

安装

通过npm安装pdfmake.js非常简单：

npm install pdfmake

或者，如果你使用yarn：

yarn add pdfmake

创建PDF文档

创建一个PDF文档只需要几个简单的步骤：

import  pdfMake from 'pdfmake/build/pdfmake';



//引入中文字体，避免转换的PDF中文乱码

pdfMake.fonts = {

    AlibabaPuHuiTi: {

        normal: 'https://xx/AlibabaPuHuiTi-3-55-Regular.ttf',

        bold: 'https://xxx/AlibabaPuHuiTi-3-65-Medium.ttf',

        italics: 'https://xxx/AlibabaPuHuiTi-3-55-Regular.ttf',

        bolditalics: 'https://xxx/AlibabaPuHuiTi-3-65-Medium.ttf'

    }

};

const dd = {

  content: [

    'Hello, 我是程序员凌览',

    { text: 'This is a simple PDF document.', fontSize: 12 },

    { text: 'It is generated using pdfmake.js.', bold: true }

  ],

  //设置默认字体

  defaultStyle: {

    font: 'AlibabaPuHuiTi'

  },

};

const pdf = pdfMake.createPdf(dd);

pdf.getBlob((buffer) => {

   const file = new File([blob], filename, { type: blob.type })

   //上传服务器

});



//或直接下载

pdf.download('文件名.pdf')

生成的pdf效果：

想动手体验，请访问pdfmake.org/playground.…。

html-to-pdfmake 强强联合

当PDF文档内容非固定，content字段内的结构要随时可变，不能再像下方代码块一样写死，html-to-pdfmake即为解决这类问题而产生的。

const dd = {

  content: [

    'Hello, 我是程序员凌览',

    { text: 'This is a simple PDF document.', fontSize: 12 },

    { text: 'It is generated using pdfmake.js.', bold: true }

  ],

  //设置默认字体

  defaultStyle: {

    font: 'AlibabaPuHuiTi'

  },

};

安装

通过npm安装：

npm install html-to-pdfmake

或者，如果你使用yarn：

yarn add html-to-pdfmake

HTML字符串转pdfmake格式

import  pdfMake from 'pdfmake/build/pdfmake';

import  htmlToPdfmake from 'html-to-pdfmake';



//引入中文字体，避免转换的PDF中文乱码

pdfMake.fonts = {

    AlibabaPuHuiTi: {

        normal: 'https://xx/AlibabaPuHuiTi-3-55-Regular.ttf',

        bold: 'https://xxx/AlibabaPuHuiTi-3-65-Medium.ttf',

        italics: 'https://xxx/AlibabaPuHuiTi-3-55-Regular.ttf',

        bolditalics: 'https://xxx/AlibabaPuHuiTi-3-65-Medium.ttf'

    }

};



//它会返回pdfmake需要的数据结构

const html = htmlToPdfmake(`

  <div>

    <h1>程序员凌览</h1>

    <p>

      This is a sentence with a <strong>bold word</strong>, <em>one in italic</em>,

      and <u>one with underline</u>. And finally <a href="https://www.somewhere.com">a link</a>.

    </p>

  </div>

`);

const dd = {

  content:html.content, 

  //设置默认字体

  defaultStyle: {

      font: 'AlibabaPuHuiTi'

  },

};

const pdf = pdfMake.createPdf(dd);

pdf.download()

生成的pdf效果：

添加图片要额外设置:

const ret = htmlToPdfmake(`<img src="https://picsum.photos/seed/picsum/200">`, {

  imagesByReference:true

});

// 'ret' contains:

//  {

//    "content":[

//      [

//        {

//          "nodeName":"IMG",

//          "image":"img_ref_0",

//          "style":["html-img"]

//        }

//      ]

//    ],

//    "images":{

//      "img_ref_0":"https://picsum.photos/seed/picsum/200"

//    }

//  }



const dd = {

  content:ret.content,

  images:ret.images

}

pdfMake.createPdf(dd).download();

最后

通过上述步骤，我们可以看到pdfmake.js及其配套工具html-to-pdfmake为Web开发者提供了一个强大而灵活的工具，以满足各种PDF文档生成的需求。无论是静态内容还是动态生成的内容，这个组合都能提供简洁而高效的解决方案。

程序员凌览的技术网站linglan01.cn/；关注公粽号【程序员凌览】回复"1"，获取编程电子书

引言

近期整理技术栈，将陆续总结分享一些项目实战中用到的实用工具。本篇分享开发流程中必不可缺的一个环节，提测。

闲聊一下

当然，对于打包，我们可以直接使用命令行直接打包例如：

flutter build apk --verbose

只是，相比输入命令行，我更倾向于一键操作，更倾向写一个打包脚本，我可以在脚本里编辑个性化操作，例如：瘦身、修改产物（apk、ipa）名称、指定打包成功后事务等等。

比如在项目里新建一个文件夹，如 script, 当需要打包发布时，右键 Run 就 Ok 了。

下面，小编整理了基础款 dart 脚本，用于 打包 和 上传蒲公英。有需要的同学可自行添加个性化处理。

Android 打包脚本

该脚本用于 apk 打包，apk 以当前时间戳名称，打包成功后可选直接打开文件夹或发布蒲公英。

import 'dart:io';

import 'package:intl/intl.dart';

import 'package:yaml/yaml.dart' as yaml;

import 'pgy_tool.dart'; //蒲公英发布脚本，下面会给出



void main(List<String> args) async {

  //是否上传蒲公英

  bool uploadPGY = true;



  // 获取项目根目录

  final _projectPath = await Process.run(

    'pwd',

    [],

  );

  final projectPath = (_projectPath.stdout as String).replaceAll(

    '\n',

    '',

  );

  // 控制台打印项目目录

  stdout.write('项目目录：$projectPath 开始编译\n');



  final process = await Process.start(

    'flutter',

    [

      'build',

      'apk',

      '--verbose',

    ],

    workingDirectory: projectPath,

    mode: ProcessStartMode.inheritStdio,

  );

  final buildResult = await process.exitCode;

  if (buildResult != 0) {

    stdout.write('打包失败，请查看日志');

    return;

  }

  process.kill();



  //开始重命名

  final file = File('$projectPath/pubspec.yaml');

  final fileContent = file.readAsStringSync();

  final yamlMap = yaml.loadYaml(fileContent) as yaml.YamlMap;



  //获取当前版本号

  final version = (yamlMap['version'].toString()).replaceAll(

    '+',

    '_',

  );

  final appName = yamlMap['name'].toString();



  // apk 的输出目录

  final apkDirectory = '$projectPath/build/app/outputs/flutter-apk/';

  const buildAppName = 'app-release.apk';

  final timeStr = DateFormat('yyyyMMddHHmm').format(

    DateTime.now(),

  );



  final resultNameList = [

    appName,

    version,

    timeStr,

  ].where((element) => element.isNotEmpty).toList();



  final resultAppName = '${resultNameList.join('_')}.apk';

  final appPath = apkDirectory + resultAppName;



  //重命名apk文件

  final apkFile = File(apkDirectory + buildAppName);

  await apkFile.rename(appPath);

  stdout.write('apk 打包成功 >>>>> $appPath \n');



  if (uploadPGY) {

    // 上传蒲公英

    final pgyPublisher = PGYTool(

      apiKey: '蒲公英控制台内你的应用的apiKey',

      buildType: 'android',

    );

    final uploadSuccess = await pgyPublisher.publish(appPath);

    if (uploadSuccess) {

      File(appPath).delete();

    }

  } else {

    // 直接打开文件

    await Process.run(

      'open',

      [apkDirectory],

    );

  }

}

Ipa 打包脚本

ipa 打包脚本和 apk 打包脚本类似，只是过程中多了一步操作，删除之前的构建文件，如下：

import 'dart:io';

import 'package:yaml/yaml.dart' as yaml;

import 'package:intl/intl.dart';



import 'pgy_tool.dart';



void main() async {

  const originIpaName = '你的应用名称';

  //是否上传蒲公英

  bool uploadPGY = true;



  // 获取项目根目录

  final _projectPath = await Process.run(

    'pwd',

    [],

  );

  final projectPath = (_projectPath.stdout as String).replaceAll(

    '\n',

    '',

  );

  // 控制台打印项目目录

  stdout.write('项目目录：$projectPath 开始编译\n');



  // 编译目录

  final buildPath = '$projectPath/build/ios';



  // 切换到项目目录

  Directory.current = projectPath;



  // 删除之前的构建文件

  if (Directory(buildPath).existsSync()) {

    Directory(buildPath).deleteSync(

      recursive: true,

    );

  }



  final process = await Process.start(

    'flutter',

    [

      'build',

      'ipa',

      '--target=$projectPath/lib/main.dart',

      '--verbose',

    ],

    workingDirectory: projectPath,

    mode: ProcessStartMode.inheritStdio,

  );



  final buildResult = await process.exitCode;

  if (buildResult != 0) {

    stdout.write('ipa 编译失败，请查看日志');

    return;

  }



  process.kill();

  stdout.write('ipa 编译成功！\n');



  //开始重命名

  final file = File('$projectPath/pubspec.yaml');

  final fileContent = file.readAsStringSync();

  final yamlMap = yaml.loadYaml(fileContent) as yaml.YamlMap;



  //获取当前版本号

  final version = (yamlMap['version'].toString()).replaceAll(

    '+',

    '_',

  );

  final appName = yamlMap['name'].toString();



  // ipa 的输出目录

  final ipaDirectory = '$projectPath/build/ios/ipa/';

  const buildAppName = '$originIpaName.ipa';

  final timeStr = DateFormat('yyyyMMddHHmm').format(

    DateTime.now(),

  );



  final resultNameList = [

    appName,

    version,

    timeStr,

  ].where((element) => element.isNotEmpty).toList();



  final resultAppName = '${resultNameList.join('_')}.ipa';

  final appPath = ipaDirectory + resultAppName;



  //重命名ipa文件

  final ipaFile = File(ipaDirectory + buildAppName);

  await ipaFile.rename(appPath);

  stdout.write('ipa 打包成功 >>>>> $appPath \n');



  if (uploadPGY) {

    // 上传蒲公英

    final pgyPublisher = PGYTool(

      apiKey: '蒲公英控制台内你的应用的apiKey',

      buildType: 'ios',

    );

    pgyPublisher.publish(appPath);

  } else {

    // 直接打开文件

    await Process.run(

      'open',

      [ipaDirectory],

    );

  }

}

蒲公英发布脚本

上面打包脚本中上传到蒲公英都调用了这句代码：

// 上传蒲公英

    final pgyPublisher = PGYTool(

      apiKey: '蒲公英控制台内你的应用的apiKey',

      buildType: 'ios',

    );

    pgyPublisher.publish(appPath);

• appPath：就是打包成功的 apk/ipa 本地路径


• buildType：分别对应两个值 android、ios


• apiKey：蒲公英控制台内你的应用对应的apiKey，如下所示

PGYTool 对应的发布脚本如下：

import 'dart:async';

import 'dart:io';

import 'package:dio/dio.dart';

import 'package:rxdart/rxdart.dart';



// 蒲公英工具类

class PGYTool {

  final getTokenPath = 'https://www.pgyer.com/apiv2/app/getCOSToken';

  final getAppInfoPath = 'https://www.pgyer.com/apiv2/app/buildInfo';

  final String apiKey;

  final String buildType; //android、ios



  PGYTool({

    required this.apiKey,

    required this.buildType,

  });



  //发布应用

  Future<bool> publish(String appFilePath) async {

    final dio = new Dio();

    stdout.write('开始获取蒲公英token');

    final tokenResponse = await _getToken(dio);

    if (tokenResponse == null) {

      stdout.write('>>>>>> 获取token失败 \n');

      return false;

    }

    stdout.write('>>>>>> 获取token成功 \n');

    final endpoint = tokenResponse['data']['endpoint'] ?? '';

    final params = tokenResponse['data']['params'] ?? {};

    stdout.write('蒲公英上传地址：$endpoint\n');

    Map<String, dynamic> map = {

      ...params,

    };

    map['file'] = await MultipartFile.fromFile(appFilePath);

    final controller = StreamController<MapEntry<int, int>>();

    controller.stream

        .throttleTime(const Duration(seconds: 1), trailing: true)

        .listen(

      (event) => stdout.write(

        '${event.key}/${event.value}  ${(event.key.toDouble() / event.value.toDouble() * 100).toStringAsFixed(2)}% \n',

      ),

      onDone: () {

        controller.close();

      },

      onError: (e) {

        controller.close();

      },

    );

    final uploadRsp = await dio.post(

      endpoint,

      data: FormData.fromMap(map),

      onSendProgress: (count, total) {

        controller.sink.add(

          MapEntry<int, int>(

            count,

            total,

          ),

        );

      },

    );

    await Future.delayed(const Duration(seconds: 1));

    if (uploadRsp.statusCode != 204) {

      stdout.write('>>>>> 蒲公英上传失败 \n');

      return false;

    }

    stdout.write('>>>>> 蒲公英上传成功 \n');

    await Future.delayed(const Duration(seconds: 3));

    await _getAppInfo(dio, tokenResponse['data']['key']);

    return true;

  }



  // 获取蒲公英token

  Future<Map<String, dynamic>?> _getToken(Dio dio) async {

    Response<Map<String, dynamic>>? tokenResponse;

    try {

      tokenResponse = await dio.post<Map<String, dynamic>>(

        getTokenPath,

        queryParameters: {

          '_api_key': apiKey,

          'buildType': buildType,

        },

      );

    } catch (_) {

      stdout.write('_getToken error : $_');

    }

    if (tokenResponse == null) return null;

    final responseJson = tokenResponse.data ?? {};

    final tokenCode = responseJson['code'] ?? 100;

    if (tokenCode != 0) {

      return null;

    } else {

      return responseJson;

    }

  }



  // tokenKey 是获取token中的返回值Key

  Future<void> _getAppInfo(Dio dio, String tokenKey, {int retryCount = 3}) async {

    final response = await dio.get<Map<String, dynamic>>(

      getAppInfoPath,

      queryParameters: {

        '_api_key': apiKey,

        'buildKey': tokenKey,

      },

    ).then((value) {

      return value.data ?? {};

    });

    final responseCode = response['code'];

    if (responseCode == 1247 && retryCount > 0) {

      //应用正在发布中，间隔 3 秒重新获取

      stdout.write('>>>>> 应用正在发布中，间隔 3 秒重新获取发布信息\n');

      await Future.delayed(const Duration(seconds: 3));

      return _getAppInfo(dio, tokenKey, retryCount: retryCount - 1);

    }

    final appName = response['data']['buildName'];

    final appVersion = response['data']['buildVersion'];

    final appUrl = response['data']['buildShortcutUrl'];

    final updateTime = response['data']['buildUpdated'];

    if (appName != null) {

      stdout.write('$appName 版本更新（$appVersion）\n');

      stdout.write('下载地址：https://www.pgyer.com/$appUrl\n');

      stdout.write('更新时间：$updateTime\n');

    }

  }

}

运行发布脚本后，控制台会将应用的上传成功后的下载地址打印出来。

背景

小程序是一种全新的业务形态，特别是微信小程序，既结合了 Web 动态化特性，又拥有 Native 丰富的设备能力支持。

在微信这个宿主上，小程序不仅有稳定的分发渠道，更拥有完善的生命周期、数据、AI 能力支持。

在该微信上开发小程序，一般使用以下两种方法：

• JavaScript + WXML + WCSS


• Taro + React + JavaScript

本文要介绍的是使用 Flutter Framework 开发小程序的方法，以及该方法背后的技术原理。

技术挑战

尽管 Flutter 官方已经提供 Flutter Web 实现，Flutter Web 本身就是基于 dart2js 运行的，微信小程序可以运行 JavaScript，在原理上跑起 Flutter Web 是没有问题的。

但仍然存在以下技术挑战：

• 微信小程序没有 W3C 标准的 JavaScript 对象，Flutter Web 不能直接运行。


• 微信小程序也没有 DOM 实现，Flutter Web HTML Renderer 不能直接渲染。


• 微信小程序对包大小的限制十分严格，主包不能超过 2M，而 Flutter Web 所编译的 main.dart.js 初始体积就有 1.3 M，必须有合理的分包机制才能上传。

我们在 MPFlutter 1.x 版本中，针对上述问题已有一定的探索，1.x 版本的解决方法如下：

• 使用微信开源的 kbone 库，模拟 W3C 实现，并通过模拟的 DOM 对象渲染出符合 WXML 要求的视图树。


• 通过 Shadow Element Tree 的方式，使用 JSON 在 Dart 与 JavaScript 上下文同步视图树。


• Fork Flutter Framework，并对其进行外科手术式的裁剪，使 main.dart.js 初始体积降低到 600K。

MPFlutter 1.x 方案已经良好的运行了两年，也收到了开发者非常多的反馈，开发者常诟病于裁剪后的 Flutter Framework 不兼容 Flutter 生态上的插件，同时 material 库也无法使用，需要从头开始编写 UI。

在 MPFlutter 2.0 版本，我们重新思考在小程序上运行 Flutter 的最佳方式，并在最终使用 CanvasKit Renderer 解决以上全部问题。

技术方案

Summary

通过裁剪 Skia 生成符合微信小程序分包要求的 CanvasKit，使用 Flutter Web + W3C BOM + WebGL Canvas 跑通渲染流程。

技术选型

在介绍技术选型前，需要先介绍 Flutter Web 的两种 Renderer。

HTML Renderer

原理是 Flutter Framework 通过 dart:js 库调用 Document 对象，并基于此将各种 RenderObject 转换为对应的 Element + CSS 添加到 DOM 树中。

该方案优点在于兼容性很好，几乎没有额外的依赖；缺点是性能不佳，并且渲染内容一致性难以与 Native Flutter 对齐。

CanvasKit Renderer

原理是通过 WebGL + Skia 渲染界面，该渲染方式与 Native Flutter 是完全一致的。

该方案优点在于渲染性能非常好，一致性与 Native Flutter 几乎没有差别；缺点是内存占用大，且需要从远端加载字体。

MPFlutter 2.0 选型

我们在 1.x 版本中用的是 HTML Renderer，通过 kbone 运行的 DOM 模拟层存在很多的问题，最令人诟病的是数据更新后界面刷新慢。当然问题的并不在于 kbone，而是 MPFlutter 1.x 本身对于 Element Tree 的序列化、反序列化的处理存在天然的缺陷，尽管已经通过 Dirty 和 Diff 等手段优化。

在 2.x 版本中，我们直接抛弃 HTML Renderer 的想法，使用 CanvasKit Renderer。

使用 CanvasKit Renderer 有这几个大前提：

• 微信小程序已支持 WebAssembly 并支持 Brotli 压缩；


• 微信小程序 Canvas 的性能相比最初的版本有质的提升，并支持 WebGL；


• 微信小程序全部分包限制放宽到 20M，足够使用。

Skia 裁剪

Skia 是 Google 开源的 2D 渲染库，凭借良好的跨设备能力，优秀的性能表现，在 Google 多个产品中被使用，包括 Chrome / Flutter / Android / Fuchsia 都有 Skia 的身影。

Skia 屏蔽了不同设备、平台的具体实现，对外统一以标准的 RenderObject、RenderCommand 开放。

Skia 其中一个 Render Target 是 WebGL，也就是 CanvasKit。

然而 Flutter Web 默认使用的 CanvasKit 足有 6M 之大，即使使用 Brotli 压缩后仍然不符合小程序分包要求。

我们可以通过指定编译选项的方式裁剪 CanvasKit 尺寸，以下是 MPFlutter 使用的 build 配置：

./modules/canvaskit/compile.sh release no_skottie no_sksl_trace no_alias_font no_effects_deserialization no_encode_jpeg no_encode_png no_encode_webp legacy_draw_vertices no_embedded_font no_woff2

从配置可见，我们去掉了 skottie、image encoder、内置字体等不必要的功能，这些功能我们可以使用微信小程序 API 补充回来。

Brotli 压缩后的 wasm 文件刚好符合 2M 分包要求。

CanvasKit 加载

Skia 构建完成后，会得到两个产物，canvaskit.wasm 和 canvaskit.js。

canvaskit.js 暴露了 wasm 中的各个 c++ 方法调用，同时也提供加载 wasm 的脚手架。

但是 canvaskit.js 的实现默认是 Web 的，我们需要将其中的 fetch 以及 WebAssembly 替换为微信小程序对应的实现。

这里提供一个使用 Skia 绘制红色矩形的微信小程序工程，有兴趣的同学可以下载到本地研究。

mpflutter.feishu.cn/wiki/LWhrw3…

Flutter Web 在微信中运行

要使 Flutter Web 在微信中运行，最大难点在于 Flutter Web 要求的 Web API 如何补充完整。

特别是 Document 、Window、Navigator 这些类，这些类我已经在 GitHub 上开源了，感兴趣的可以逐个文件阅读。

github.com/mpflutter/m…

这里举一个 window 的文件节选段落讲解：

export class FlutterMiniProgramMockWindow {

  // screens

  get devicePixelRatio() {

    return wxSystemInfo.pixelRatio;

  }



  get innerWidth() {

    return wxSystemInfo.windowWidth;

  }



  get innerHeight() {

    return wxSystemInfo.windowHeight;

  }



  // webs

  navigator = {

    appVersion: "",

    platform: "",

    userAgent: "",

    vendor: "",

    language: "zh",

  };

  

  // 还有更多。。。

}

Flutter Web 在运行过程中，会通过 window.innerWidth / window.innerHeight 获取当前窗口宽高，以便下一步创建合适大小的画布用于渲染。

在微信小程序中，我们需要使用 wx.getSystemInfoSync() 获取对应宽高，并在 MockWindow 中返回给 Flutter。

关于 BOM 的文件，就不详细展开，都是一些胶水代码。

而 Flutter 的 main.dart.js 也需要有一些改造才可以跑在小程序上，主要的改造是通过 export main.dart.js 中的 main 函数，使其适配 CommonJS 可暴露给 Page 调用。

字体的加载

CanvasKit 最大的问题在于字体加载，目前来看是无法复用系统本身的字体的。

我们的做法是通过裁剪 NotoSansSC 字体，只包含常用的 9000+ 汉字，内置于小程序包中优先加载它。

这样有一个好处，小程序不需要强制从 gstatic 下载字体，省流省加载时间。

后续，我们还会研究通过 Canvas 2D 的方式，从本地加载字体。

分包

关于分包，其实是最好做的，因为 Flutter Web 本身就有 defered load 编译能力。

开发者可以轻松地将 main.dart.js 切分成若干个 JS 文件，我们做的就是在 Flutter Web 编译完成后，智能地将这些 JS 文件分配到不同的分包就好了。

资源分包也同理，资源通过 brotli 压缩也可以减少包体积。

总结

整整一套下来，Flutter 已经可以在微信小程序里跑起来了，我们来总结一下做了什么？

我们通过裁剪 Skia 使得 CanvasKit 可以很好地跑在小程序上，通过 BOM 兼容的方法，使得 Flutter Web 可以在微信小程序中找到对应实现，通过字体内置、智能分包的方式很好地解决了微信包体积限制。

该方案目前已经完全跑通，并已可用，同学们可以在 v2.mpflutter.com 文档站了解到更多用法。

如果对方案有任何疑问，也欢迎添加微信交流，感谢大家的关注。