大家好 👋🏻, 新的一年即将开始, 我不想错过这个机会, 与大家分享一篇题为《2024年的安卓现代开发》的文章. 🚀

如果你错过了我的上一篇文章, 可以看看2023年的安卓现代开发并回顾一下今年的变化.

免责声明

📝 本文反映了我的个人观点和专业见解, 并参考了 Android 开发者社区中的不同观点. 此外, 我还定期查看 Google 为 Android 提供的指南.

🚨 需要强调的是, 虽然我可能没有明确提及某些引人注目的工具, 模式和体系结构, 但这并不影响它们作为开发 Android 应用的宝贵替代方案的潜力.

Kotlin 无处不在 ❤️

Kotlin是由JetBrains开发的一种编程语言. 由谷歌推荐, 谷歌于 2017 年 5 月正式发布(查看这里). 它是一种与 Java 兼容的现代编程语言, 可以在 JVM 上运行, 这使得它在 Android 应用开发中的采用非常迅速.

无论你是不是安卓新手, 都应该把 Kotlin 作为首选, 不要逆流而上 🏊🏻 😎, 谷歌在 2019 年谷歌 I/O 大会上宣布了这一做法. 有了 Kotlin, 你就能使用现代语言的所有功能, 包括协程的强大功能和使用为 Android 生态系统开发的现代库.

请查看Kotlin 官方文档

Kotlin 是一门多用途语言, 我们不仅可以用它来开发 Android 应用, 尽管它的流行很大程度上是由于 Android 应用, 我们可以从下图中看到这一点.

KotlinConf ‘23

Kotlin 2.0 要来了

另一个需要强调的重要事件是Kotlin 2.0的发布, 它近在眼前. 截至本文发稿之日, 其版本为 2.0.0-beta4

新的 K2 编译器 也是 Kotlin 2.0 的另一个新增功能, 它将带来显著的性能提升, 加速新语言特性的开发, 统一 Kotlin 支持的所有平台, 并为多平台项目提供更好的架构.

请查看 KotlinConf '23 的回顾, 你可以找到更多信息.

Compose 🚀

Jetpack Compose 是 Android 推荐的用于构建本地 UI 的现代工具包. 它简化并加速了 Android 上的 UI 开发. 通过更少的代码, 强大的工具和直观的 Kotlin API, 快速实现你的应用.

• Jetpack Compose 文档

Jetpack Compose 是 Android Jetpack 库的一部分, 使用 Kotlin 编程语言轻松创建本地UI. 此外, 它还与 LiveData 和 ViewModel 等其他 Android Jetpack 库集成, 使得构建具有强反应性和可维护性的 Android 应用变得更加容易.

Jetpack Compose 的一些主要功能包括

资源:

• Jetpack Compose 文档


• Compose 与 Kotlin 的兼容性图谱


• Jetpack Compose 路线图


• 课程


• Jetpack Compose 中@Composable的API 指南

Android Jetpack ⚙️

Jetpack是一套帮助开发者遵循最佳实践, 减少模板代码, 编写在不同Android版本和设备上一致运行的代码的库, 这样开发者就可以专注于他们的业务代码.

_ Android Jetpack 文档

其中最常用的工具有:

• ViewModel


• Room


• DataStore


• WorkManager


• Navigation


• CameraX


• Compose


• Media3


• Glance

Material You / Material Design 🥰

Material You 是在 Android 12 中引入并在 Material Design 3 中实现的一项新的定制功能, 它使用户能够根据个人喜好定制操作系统的视觉外观. Material Design 是一个由指南, 组件和工具组成的可调整系统, 旨在坚持UI设计的最高标准. 在开源代码的支持下, Material Design 促进了设计师和开发人员之间的无缝协作, 使团队能够高效地创造出令人惊叹的产品.

目前, Material Design 的最新版本是 3, 你可以在这里查看更多信息. 此外, 你还可以利用Material Theme Builder来帮助你定义应用的主题.

代码仓库

使用 Material 3 创建主题

SplashScreen API

Android 中的SplashScreen API对于确保应用在 Android 12 及更高版本上正确显示至关重要. 不更新会影响应用的启动体验. 为了在最新版本的操作系统上获得一致的用户体验, 快速采用该 API 至关重要.

Clean架构

Clean架构的概念是由Robert C. Martin提出的. 它的基础是通过将软件划分为不同层次来实现责任分离.

特点

依赖规则

作者在他的博文Clean代码中很好地描述了依赖规则.

依赖规则是使这一架构得以运行的首要规则. 这条规则规定, 源代码的依赖关系只能指向内部. 内圈中的任何东西都不能知道外圈中的任何东西. 特别是, 外圈中声明的东西的名称不能被内圈中的代码提及. 这包括函数, 类, 变量或任何其他命名的软件实体.

• 博文Clean代码

安卓中的Clean架构:

Presentation 层: Activitiy, Composable, Fragment, ViewModel和其他视图组件.
Domain层: 用例, 实体, 仓库接口和其他Domain组件.
Data层: 仓库的实现类, Mapper, DTO 等.

Presentation层的架构模式

架构模式是一种更高层次的策略, 旨在帮助设计软件架构, 其特点是在一个可重复使用的框架内为常见的架构问题提供解决方案. 架构模式与设计模式类似, 但它们的规模更大, 解决的问题也更全面, 如系统的整体结构, 组件之间的关系以及数据管理的方式等.

在Presentation层中, 我们有一些架构模式, 我想重点介绍以下几种:

• MVVM


• MVI

我不想逐一解释, 因为在互联网上你可以找到太多相关信息. 😅

此外, 你还可以查看应用架构指南.

依赖注入

依赖注入是一种软件设计模式, 它允许客户端从外部获取依赖关系, 而不是自己创建依赖关系. 它是一种在对象及其依赖关系之间实现控制反转(IoC)的技术.

• Hilt ❤️


• Dagger


• Koin

模块化

模块化是一种软件设计技术, 可将应用划分为独立的模块, 每个模块都有自己的功能和职责.

模块化的优势

可重用性: 拥有独立的模块, 就可以在应用的不同部分甚至其他应用中重复使用.

严格的可见性控制: 模块可以让你轻松控制向代码库其他部分公开的内容.

自定义交付: Play特性交付 使用应用Bundle的高级功能, 允许你有条件或按需交付应用的某些功能.

可扩展性: 通过独立模块, 可以添加或删除功能, 而不会影响应用的其他部分.

易于维护: 将应用划分为独立的模块, 每个模块都有自己的功能和责任, 这样就更容易理解和维护代码.

易于测试: 有了独立的模块, 就可以对它们进行隔离测试, 从而便于发现和修复错误.

改进架构: 模块化有助于改进应用的架构, 从而更好地组织和结构代码.

改善协作: 通过独立的模块, 开发人员可以不受干扰地同时开发应用的不同部分.

构建时间: 一些 Gradle 功能, 如增量构建, 构建缓存或并行构建, 可以利用模块化提高构建性能.

更多信息请参阅官方文档.

网络

• OkHttp


• Retrofit


• Ktor

序列化

在本节中, 我想提及两个我认为非常重要的工具: 与 Retrofit 广泛结合使用的Moshi, 以及 JetBrains 的 Kotlin 团队押宝的Kotlin Serialization.

• Moshi


• Kotlin Serialization

Moshi 和 Kotlin Serialization 是用于 Kotlin/Java 的两个序列化/反序列化库, 可将对象转换为 JSON 或其他序列化格式, 反之亦然. 这两个库都提供了友好的接口, 并针对移动和桌面应用进行了优化. Moshi 主要侧重于 JSON 序列化, 而 Kotlin Serialization 则支持包括 JSON 在内的多种序列化格式.

图像加载

要从互联网上加载图片, 有几个第三方库可以帮助你处理这一过程. 图片加载库为你做了很多繁重的工作; 它们既处理缓存(这样你就不用多次下载图片), 也处理下载图片并将其显示在屏幕上的网络逻辑.

_ 官方安卓文档

• Coil


• Glide

响应/线程管理

说到响应式编程和异步进程, Kotlin协程凭借其suspend函数和Flow脱颖而出. 然而, 在 Android 应用开发中, 承认 RxJava 的价值也是至关重要的. 尽管协程和 Flow 的采用率越来越高, 但 RxJava 仍然是多个项目中稳健而受欢迎的选择.

对于新项目, 请始终选择Kotlin协程❤️. 可以在这里探索一些Kotlin协程相关的概念.

本地存储

在构建移动应用时, 重要的一点是能够在本地持久化数据, 例如一些会话数据或缓存数据等. 根据应用的需求选择合适的存储选项非常重要. 我们可以存储键值等非结构化数据, 也可以存储数据库等结构化数据. 请记住, 这一点并没有提到我们可用的所有本地存储类型(如文件存储), 只是提到了允许我们保存数据的工具.

建议:

• S̶h̶a̶r̶e̶d̶P̶r̶e̶f̶e̶r̶e̶n̶c̶e̶s̶


• DataStore


• EncryptedSharedPreferences

测试 🕵🏼

软件开发中的测试对于确保产品质量至关重要. 它能检测错误, 验证需求并确保客户满意. 下面是一些最常用的测试工具::

• JUnit 5


• Mockk


• Kotest


• Kluent


• Turbine


• Espresso


• Robolectric


• Maestro

工具文档的测试部分

截屏测试 📸

Android 中的截屏测试涉及自动捕获应用中各种 UI 元素的屏幕截图, 并将其与基线图像进行比较, 以检测任何意外的视觉变化. 它有助于确保不同版本和配置的应用具有一致的UI外观, 并在开发过程的早期捕捉视觉回归.

• Paparazzi


• Roborazzi

R8 优化

R8 是默认的编译器, 可将项目的 Java 字节码转换为可在 Android 平台上运行的 DEX 格式. 通过缩短类名及其属性, 它可以帮助我们混淆和减少应用的代码, 从而消除项目中未使用的代码和资源. 要了解更多信息, 请查看有关 缩减, 混淆和优化应用 的 Android 文档. 此外, 你还可以通过ProGuard规则文件禁用某些任务或自定义 R8 的行为.

• 代码缩减


• 缩减资源


• 混淆


• 优化

第三方工具

• DexGuard

Play 特性交付

Google Play 的应用服务模式称为动态交付, 它使用 Android 应用Bundle为每个用户的设备配置生成并提供优化的 APK, 因此用户只需下载运行应用所需的代码和资源.

• Android 文档

自适应布局

随着具有不同外形尺寸的移动设备使用量的增长, 我们需要一些工具, 使我们的 Android 应用能够适应不同类型的屏幕. 因此, Android 为我们提供了Window Size Class, 简单地说, 就是三大类屏幕格式, 它们是我们开发设计的关键点. 这样, 我们就可以避免考虑许多屏幕设计的复杂性, 从而将可能性减少到三组, 它们是 Compat, Medium和Expanded.

Window Size Class

支持不同的屏幕尺寸

我们拥有的另一个重要资源是Canonical Layout, 它是预定义的屏幕设计, 可用于 Android 应用中的大多数场景, 还为我们提供了如何将其适用于大屏幕的指南.

其他相关资源

• 2022 年谷歌 I/O 大会形式因素的三件事


• 播放列表: 2022 年谷歌 I/O 大会上的Form-Factor

Form-Factor培训

本地化 🌎

本地化包括调整产品以满足不同地区不同受众的需求. 这包括翻译文本, 调整格式和考虑文化因素. 其优势包括进入全球市场, 增强用户体验, 提高客户满意度, 增强在全球市场的竞争力以及遵守当地法规.

注: BCP 47 是安卓系统使用的国际化标准.

参考资料

• 支持不同语言和文化


• 本地化应用


• 每个应用的语言首选项


• 每个应用的语言偏好 - 第一部分


• 每个应用的语言偏好 - 第二部分

性能 🔋⚙️

在开发 Android 应用时, 我们必须确保用户体验更好, 这不仅体现在应用的开始阶段, 还体现在整个执行过程中. 因此, 我们必须使用一些工具, 对可能影响应用性能的情况进行预防性分析和持续监控:

• 基准


• 基准配置文件


• 应用启动


• Firebase 性能监控


• JankStats 库

应用内更新

当你的用户在他们的设备上不断更新你的应用时, 他们可以尝试新功能, 并从性能改进和错误修复中获益. 虽然有些用户会在设备连接到未计量的连接时启用后台更新, 但其他用户可能需要提醒才能安装更新. 应用内更新是 Google Play 核心库的一项功能, 可提示活跃用户更新你的应用*.

运行 Android 5.0(API 等级 21)或更高版本的设备支持应用内更新功能. 此外, 应用内更新仅支持 Android 移动设备, Android 平板电脑和 Chrome OS 设备.

- 应用内更新文档

应用内评论

Google Play 应用内评论 API 可让你提示用户提交 Play Store 评级和评论, 而无需离开你的应用或游戏.

一般来说, 应用内评论流程可在用户使用应用的整个过程中随时触发. 在流程中, 用户可以使用 1-5 星系统对你的应用进行评分, 并添加可选评论. 一旦提交, 评论将被发送到 Play Store 并最终显示出来.

*为保护用户隐私并避免 API 被滥用, 你的应用应严格遵守有关何时请求应用内评论和评论提示的设计的规定.

- 应用内评论文档

可观察性 👀

在竞争日益激烈的应用生态系统中, 要获得良好的用户体验, 首先要确保应用没有错误. 确保应用无错误的最佳方法之一是在问题出现时立即发现并知道如何着手解决. 使用 Android Vitals 来确定应用中崩溃和响应速度问题最多的区域. 然后, 利用 Firebase Crashlytics 中的自定义崩溃报告获取更多有关根本原因的详细信息, 以便有效地排除故障.

工具

• 谷歌分析


• Android Vitals


• Firebase Crashlytics


• Firebase 性能监控

辅助功能

辅助功能是软件设计和构建中的一项重要功能, 除了改善用户体验外, 还能让有辅助功能需求的人使用应用. 这一概念旨在改善的不能包括: 有视力问题, 色盲, 听力问题, 灵敏性问题和认知障碍等.

考虑因素:

• 增加文字的可视性(颜色对比度, 可调整文字大小)


• 使用大而简单的控件


• 描述每个UI元素

更多详情请查看辅助功能 - Android 文档

安全性 🔐

在开发保护设备完整性, 数据安全性和用户信任的应用时, 安全性是我们必须考虑的一个方面, 甚至是最重要的方面.

• 使用凭证管理器登录用户: 凭据管理器 是一个 Jetpack API, 在一个单一的 API 中支持多种登录方法, 如用户名和密码, 密码匙和联合登录解决方案(如谷歌登录), 从而简化了开发人员的集成.


• 加密敏感数据和文件: 使用EncryptedSharedPreferences 和EncryptedFile.


• 应用基于签名的权限: 在你可控制的应用之间共享数据时, 使用基于签名的权限.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

    package="com.example.myapp">

    <permission android:name="my_custom_permission_name"

                android:protectionLevel="signature" />

• 不要将密钥, 令牌或应用配置所需的敏感数据直接放在项目库中的文件或类中. 请使用local.properties.


• 实施 SSL Pinning: 使用 SSL Pinning 进一步确保应用与远程服务器之间的通信安全. 这有助于防止中间人攻击, 并确保只与拥有特定 SSL 证书的受信任服务器进行通信.

res/xml/network_security_config.xml

<?xml version="1.0" encoding="utf-8"?>

<network-security-config>

    <domain-config>

        <domain includeSubdomains="true">example.com</domain>

        <pin-set expiration="2018-01-01">

            <pin digest="SHA-256">ReplaceWithYourPin</pin>

            <!-- backup pin -->

            <pin digest="SHA-256">ReplaceWithYourPin</pin>

        </pin-set>

    </domain-config>

</network-security-config>

• 实施运行时应用自我保护(RASP): 这是一种在运行时保护应用免受攻击和漏洞的安全技术. RASP 的工作原理是监控应用的行为, 并检测可能预示攻击的可疑活动:
  
  
  
  
  • 代码混淆.
  
  
  • 根检测.
  
  
  • 篡改/应用钩子检测.
  
  
  • 防止逆向工程攻击.
  
  
  • 反调试技术.
  
  
  • 虚拟环境检测
  
  
  • 应用行为的运行时分析.
  
  
  
  

想了解更多信息, 请查看安卓应用中的运行时应用自我保护技术(RASP). 还有一些 Android 安全指南.

版本目录

Gradle 提供了一种集中管理项目依赖关系的标准方式, 叫做版本目录; 它在 7.0 版中被试验性地引入, 并在 7.4 版中正式发布.

优点:

• 对于每个目录, Gradle 都会生成类型安全的访问器, 这样你就可以在 IDE 中通过自动补全轻松添加依赖关系.


• 每个目录对构建过程中的所有项目都是可见的. 它是声明依赖项版本的中心位置, 并确保该版本的变更适用于每个子项目.


• 目录可以声明 dependency bundles, 即通常一起使用的 "依赖关系组".


• 目录可以将依赖项的组和名称与其实际版本分开, 而使用版本引用, 这样就可以在多个依赖项之间共享一个版本声明.

请查看更多信息

Secret Gradle 插件

Google 强烈建议不要将 API key 输入版本控制系统. 相反, 你应该将其存储在本地的 secrets.properties 文件中, 该文件位于项目的根目录下, 但不在版本控制范围内, 然后使用 Secrets Gradle Plugin for Android 来读取 API 密钥.

日志

日志是一种软件工具, 用于记录程序的执行信息, 重要事件, 错误调试信息以及其他有助于诊断问题或了解程序运行情况的信息. 日志可配置为将信息写入不同位置, 如日志文件, 控制台, 数据库, 或将信息发送到日志记录服务器.

• Klogging


• Timber

Linter / 静态代码分析器

Linter 是一种编程工具, 用于分析程序源代码, 查找代码中的潜在问题或错误. 这些问题可能是语法问题, 代码风格不当, 缺乏文档, 安全问题等, 它们会对代码的质量和可维护性产生影响.

• Android Lint


• Detekt ⏫


• Ktlint ⏫


• Konsist

Google Play Instant

Google Play Instant 使本地应用和游戏无需安装即可在运行 Android 5.0(API 等级 21)或更高版本的设备上启动. 你可以使用 Android Studio 构建这类体验, 称为即时应用和即时游戏. 通过允许用户运行即时应用或即时游戏(即提供即时体验), 你可以提高应用或游戏的发现率, 从而有助于吸引更多活跃用户或安装.

• Google Play Instant 概述

新设计中心

安卓团队提供了一个新的设计中心, 帮助创建美观, 现代的安卓应用, 这是一个集中的地方, 可以了解安卓在多种形态因素方面的设计.

点击查看新的设计中心

人工智能

Gemini和PalM 2是谷歌开发的两个最先进的人工智能(AI)模型, 它们将改变安卓应用开发的格局. 这些模型具有一系列优势, 将推动应用的效率, 用户体验和创新.

• Gemini


• PalM 2

人工智能编码助手工具

Studio Bot

Studio Bot 是你的 Android 开发编码助手. 它是 Android Studio 中的一种对话体验, 通过回答 Android 开发问题帮助你提高工作效率. 它采用人工智能技术, 能够理解自然语言, 因此你可以用简单的英语提出开发问题. Studio Bot 可以帮助 Android 开发人员生成代码, 查找相关资源, 学习最佳实践并节省时间.

Studio Bot

Github Copilot

GitHub Copilot 是一个人工智能配对程序员. 你可以使用 GitHub Copilot 直接在编辑器中获取整行或整个函数的建议.

Amazon CodeWhisperer

这是亚马逊的一项服务, 可根据你当前代码的上下文生成代码建议. 它能帮助你编写更高效, 更安全的代码, 并发现新的 API 和工具.

Kotlin Multiplatform 🖥 📱⌚️ 🥰 🚀

最后, 同样重要的是, Kotlin Multiplatform 🎉 是本年度最引人注目的新产品. 它是跨平台应用开发领域的有力竞争者. 虽然我们的主要重点可能是 Android 应用开发, 但 Kotlin Multiplatform 为我们提供了利用 KMP 框架制作完全本地 Android 应用的灵活性. 这一战略举措不仅为我们的项目提供了未来保障, 还为我们提供了必要的基础架构, 以便在我们选择多平台环境时实现无缝过渡. 🚀

如果你想深入了解 Kotlin Multiplatform, 我想与你分享这几篇文章. 在这些文章中, 探讨了这项技术的现状及其对现代软件开发的影响:

• Kotlin Multiplatform - 是这样的


• Kotlin Multiplatform的现状 - 2023年网络研讨会

1. 背景

项目需要做一个安卓app，而且不需要上架应用市场，部门也没有安卓开发，想着就套个webview就行了吧。没有选择react native之类的是因为这些工具需要安装很多环境工具，我只是开发一个壳子没必要这么复杂。

用webview也方便快速修复页面问题。

所以最后选择了uniapp，但是uniapp本身就是套在一个大的webview下的， 所以再套一个webview难免会有一些意想不到的问题，下面就是一些踩过的坑记录。

2. 项目初始化

新建项目就默认模板就行，我只需要壳子。

 启动了之后可以看到有两个调试工具

第一个就是网页上常用的vue调试工具，可以看到vue组件属性啥的，第二个就是类似chrome的控制台，但是无法查看元素，还有就是必须让设备和电脑在同一个网段下才行，不然连接不上。

hbuilder的控制台本身也有一些输出，比如页面的console

但是这里输出对象的时候不是很方便查看，如果你需要的话就打开上面说的第二个调试工具。

3. webview使用

整个项目很简单，大概就这样一个页面

<template>

	<web-view :src='PROJECT_PATH' @message="onMessage">web-view>

template>

<script>

    // ...

script>

3.1 网页与app通信

这是最重要的一个功能，可以参考官方文档。

网页和app交互总结起来就是这两点：

• 网页 -> APP：window.uni.postMessage();
• APP -> 网页：webview.evalJS()

3.1.1. 网页 -> APP

首先要在项目中引入uni.webview.js，这个就相当于jsbridge，可以让网页操作uniapp。

初始化完成后会在window上挂载一个uni对象，通过uni.postMessage就能往app发送消息，app中监听onMessage就行。

这里有几个小坑：

1. 发送的格式window.uni.postMessage({ data: 数据 })，必须要有个字段data，这样app才能收到数据。源码

 2. 发送的数据不需要序列化成字符串，uniapp会转换json。 3. app在message事件中接收到事件参数应该这样解构

function onMessage(e) {

    const {

            type,

            data

    } = e.detail.data[0]

}

3.1.2. APP -> 网页

app向网页传输消息就直接调用网页的js就行了。这里我统一封装了一个函数：

// app向网页发送消息

const deliverMessage = (msg) => {

    // 调用webview中的deliverMessage函数

    // 这个函数是我在网页挂载的一个全局函数，调用deliverMessage后会触发页面中的一些事件

    currentWebview.evalJS(`deliverMessage(${JSON.stringify(msg)})`)

}

上面的代码例子中出现的currentWebview需要我们自己去获取。

// vue2中

const rootWebview = this.$scope.$getAppWebview()

this.currentWebview = rootWebview.children()[0]



// vue3中

import {

    getCurrentInstance,

    ref,

} from "vue";

const currentWebview = ref(null)

const vueInstance = getCurrentInstance()

const rootWebview = vueInstance.proxy.$scope.$getAppWebview()

currentWebview.value = rootWebview.children()[0]

这里也有一个坑，rootWebview.children()如果你一渲染就获取是无法获取到webview实例的，具体原因没有深入研究，估计是异步的原因

这里提供两个思路：

1. 加一个定时器，延迟获取webview，这个方法虽然听起来不保险，但是实际测试还是挺稳当的。关键是简单。

setTimeout(() => {

    currentWebview.value = rootWebview.children()[0]

}, 1000)

2. 你要是觉得定时器不保险，那就使用plus的api手动创建webview。但是消息处理这块比较麻烦。官网参考

<template>

    

template>

// 我这里vue3为例

onMounted(() => {

    plus.globalEvent.addEventListener('plusMessage', ({data: {type, args}}) => {

        // 是网页调用uni的api

        if(type === 'WEB_INVOKE_APPSERVICE') {

            const {data: {name, arg}} = args

            // 是发送消息事件

            if(name === 'postMessage') {

                // arg就是传过来的数据

            }

        }

    })

    const wv = plus.webview.create("", "webview", {

        'uni-app': 'none',

    })

    wv.loadURL(网页地址)

    rootWebview.append(wv);

})

plus.globalEvent.addEventListener这个是翻源码找到的，主要是我不想改uni.webview.js的源码，所以只有找到正确的监听事件。

WEB_INVOKE_APPSERVICE是uniapp内部定义的一个名字，反正就是用来交互操作的命名空间。

这样基础的互操作就有了。

3.1.3. 整个流程

1. 网页调用window.uni.postMessage({ data }) => app监听（用组件的onMessage或者自定义的globalEvent）
2. app调用网页定义的函数deliverMessage并传递参数，网页中的deliverMessage内部处理监听

// 网页中的deliverMessage

window.deliverMessage = (msg) => {

  // 触发网页注册的监听器

  eventListeners.forEach((listener) => {

    

  });

};

3.2. 返回拦截

默认情况下，手机按下返回键，app会响应提示是否退出，但是实际我需要网页进入二级路由的时候，按下手机返回键是返回上一级路由而不是退出。当路由是一级路由时才提示是否退出app

import {

    onBackPress,

    onShow,

} from '@dcloudio/uni-app'

// 页面当前的路由信息

const pageRoute = shallowRef()

onBackPress(() => {

    // tab页正常app返回逻辑

    if (pageRoute.value?.isTab) {

        return false

    } else {

        // 二级路由拦截app返回

        return true

    }

})

pageRoute是页面当前路由信息，页面通过监听路由变化触发routeChange事件，将路由信息传给app。当按下返回键的时候，判断当前路由配置是不是tab页，如果是就正常退出，不是就拦截返回。

4. 总结

有了通信功能，很多操作就可以实现了，比如获取设备safeArea，获取设备联网状态等等。

作者：头上有煎饺
来源：juejin.cn/post/7313740940773097482

背景

刚接触鸿蒙开发不久，从iOS转过来的，经常会遇到在一个公共的类里，会想要给当前window上添加一个全屏的自定义视图，那在鸿蒙中应该如何实现这一个效果呢？

这里介绍一下我自己想到的实现方式，不一定是最优解，大家有其他更好的方式或者问题，欢迎指正。

代码是基于鸿蒙next和模拟器

思路

在鸿蒙中，虽然可以通过下面的系统方法获取到window，但是目前我不知道如何像iOS一样，在其上添加自定义的组件。所以，在研究了系统的window之后，想到是否可以直接弹出一个全屏的window，然后在这个自定义的window上，添加我们的自定义组件。类似于iOS的三方库SwiftEntryKit

import { window } from '@kit.ArkUI'

function findWindow(name: string): Window;

实现步骤

代码

公共模块：

import { window } from '@kit.ArkUI'

import { common } from '@kit.AbilityKit'



export class HDEntryKit {

  static display(use: EKAttributes) {

    HDWindowProvider.instance().display(use)

  }



  static dismiss(complete?: (() => void)) {

    HDWindowProvider.instance().dismiss(complete)

  }

}



class HDWindowProvider {

  private static windowProvider: HDWindowProvider

  context: common.UIAbilityContext = getContext(this) as common.UIAbilityContext;

  windowName: string = "HDEntryWindow"



  static instance() {

    if (!HDWindowProvider.windowProvider) {

      HDWindowProvider.windowProvider = new HDWindowProvider();

    }

    return HDWindowProvider.windowProvider;

  }



  display(use: EKAttributes) {

    let windowClass: window.Window

    window.createWindow({

      name: this.windowName,

      windowType: window.WindowType.TYPE_DIALOG,

      ctx: this.context

    }, (err, data) => {

      if (err.code == 0) {

        windowClass = data

        windowClass.setWindowLayoutFullScreen(true)

        let bundleName = this.context.applicationInfo.name

        let page = `@bundle:${bundleName}/uicomponents/ets/HDEntryKit/HDEntryPage`

        let storage: LocalStorage = new LocalStorage()

        storage.setOrCreate('use', use)

        windowClass.loadContent(page, storage, err => {

          if (err.code == 0) {

            windowClass.setWindowBackgroundColor(use.backgroundColor?.toString())

          }

        })

        windowClass.showWindow(() => {

        })

      }

    })

  }



  dismiss(complete?: (() => void)) {

    window.findWindow(this.windowName).destroyWindow((err, e) => {

      if (err.code == 0 && complete) {

        complete()

      }

    })

  }

}



export class Size {

  width: Length | null = null

  height: Length | null = null

  margin: Length | Padding = 0

}



export class EKAttributes {

  name?: string

  entry?: CustomBuilder

  position: FlexAlign = FlexAlign.Center

  backgroundColor: ResourceColor = "#99000000"

  displayDuration: number = 1000

  size: Size = new Size()

}

import { EKAttributes, HDEntryKit } from './HDEntryKit'



let storage = LocalStorage.getShared()

@Entry(storage)

@Component

struct HDEntryPage {

  @BuilderParam entryView: CustomBuilder

  @LocalStorageProp('use') use: EKAttributes = new EKAttributes()



  build() {

    Column() {

      Row() {

        Column() {

          if (this.entryView) {

            this.entryView()

          }

        }

        .width('100%')

        .onClick(e => {})

      }

      .width(this.use.size.width)

      .height(this.use.size.height)

      .margin(this.use.size.margin)

      .backgroundColor(Color.Blue)

    }

    .width('100%')

    .height('100%')

    .justifyContent(this.use.position)

    .onClick(event => {

      HDEntryKit.dismiss()

    })

  }



  aboutToAppear(): void {

    this.entryView = this.use.entry

  }

调用方：

/// 弹框的配置

let use = new EKAttributes()

use.size.height = 100

use.size.margin = 20

use.position = FlexAlign.End

use.entry = this.text.bind(this)

HDEntryKit.display(use)



/// 自定义的弹框组件

@Builder text() {

  Row() {

    Text("123")

      .backgroundColor('#ff0000')

      .onClick(() => {

        this.test()

      })

  }

  .width('100%')

  .justifyContent(FlexAlign.Start)

}



/// 弹框组件中的页面跳转事件

test() {

  HDEntryKit.dismiss(() => {

    let bundleName = this.context.applicationInfo.name

    let loginPage = `@bundle:${bundleName}/login/ets/pages/LoginRegisterPage`

    router.pushUrl({url: loginPage})

  })

}

注意

通过自定义window方法弹出页面后，如果在调用router.push，则是默认在这个自定义的window进行页面跳转，当你销毁这个window的时候，打开的页面都会被关闭。所以，在demo里是在window销毁后，再进行页面跳转

前言

在日常的工作中，很多工作和操作其实都是重复的，这个时候，就会想，能不能通过工具进行一键操作。

由于本人是Android开发，寻找解决方案时发现了compose-multiplatform，于是就写个工具玩一玩。

软件介绍

AdbDevTools 是支持windows和mac的，并且支持浅色模式和暗黑模式，下面的截图都是在暗黑模式下。

• 目的：都是为了减少重复性工作，节省开发者时间。


• 简化Hprof文件管理：轻松一键导出、管理和分析Hprof文件，全面支持LeakCanary数据处理。


• 内存泄漏分析：对 Hprof 文件进行内存泄漏分析，快速定位问题根源。


• 位图资源管理：提供位图预览、分析和导出功能。


• Deep Link快速调用：管理和测试Deep Link，提高开发和调试速度。


• 开发者选项快捷操作：包含多项开发者选项的快捷操作。

功能介绍

内存快照文件管理和分析

常规操作：

• 打开AS Memory Profiler，dump 出内存快照文件，等待内存快照文件生成，查看泄露的 Activity 或者 Fragment。


• Android 8以下还可以有个 BitmapPreview 预览 Bitmap，但是每次只能预览一个 Bitmap。


• 如果重新打开 AS，刚刚生成的 hprof 文件在哪里？？


• 所以如果想保存刚刚生成的 hprof 文件，就得在生成文件后，手动点击把文件保存一下到电脑上。


• 如果想找到 LeakCanary 生成的文件，得找到对应的文件目录，然后再用 adb pull 一下到电脑上。。

懒人操作：

• 一键 dump 出内存快照，自动化分析，生成一份报告。


• Android 8以下的快照文件，可以一键导出所有 Bitmap 实例，方便预览。


• 通过工具，管理最近打开的 hprof 文件


• 一键导出 LeakCanary 生成的文件，无需手动操作。

开发者选项快捷操作

在日常的开发工作中，可能要经常打开开发者选项页面，打开某一个开关。

常规操作：打开设置页面，找到开发者选项，点击进入开发者页面，上下滑动，找到某一个开关，进行调整。这一系列的操作，有点繁琐。

懒人操作：在PC软件内，一键操作，直接打开开关。一步到位，不需要在手机里找来找去和点点点。

开发

代码架构设计

github.com/theapache64…，基于这个库，可以使用 Android 的开发方式，去开发一个桌面软件。

简单的这样理解。

对于单个桌面应用，其实就是类似 Android 的 Application。

对于应用内的窗口，其实就是类似 Android 的 Activity。

对于窗口内的各种子页面，其实就是类似 Android 的 Fragment，这边当成一个个的 Component 实现。

Application

• 基类 Application。提供一个 startActivity 方法，用于打开某个页面。


• 自定义 MyApplication，继承 Application，在 onCreate 方法里面，执行一些应用初始化操作。


• 比如 onCreate 的时候，启动 MainActivity。


• main() 方法，调用 MyApplication 的 onCreate 方法即可。

open class Application  {



    protected fun startActivity(intent: Intent) {

        val activity = intent.to.java.newInstance()

        activity.intent = intent

        activity.onCreate()

    }



    open fun onCreate() {



    }

}



class MyApplication(args: AppArgs) : Application() {



    override fun onCreate() {

        super.onCreate()

        

        Arbor.d("onCreate")



        val splashIntent = MainActivity.getStartIntent()

        startActivity(splashIntent)

    }

}



fun main() {

    MyApplication(appArgs).onCreate()

}

Activity

• 自定义 MainActivity，在 onCreate 方法里面，创建和展示 Window 。

class MainActivity : Activity() {



    companion object {

        fun getStartIntent(): Intent {

            return Intent(MainActivity::class).apply {

                // putExtra

            }

        }

    }



    @OptIn(ExperimentalComposeUiApi::class)

    override fun onCreate() {

        super.onCreate()



        val lifecycle = LifecycleRegistry()

        val root = NavHostComponent(DefaultComponentContext(lifecycle))



        application {



            val intUiThemes by mainActivityViewModel.intUiThemes.collectAsState()

            val themeDefinition = if (intUiThemes.isDark()) {

                JewelTheme.darkThemeDefinition()

            } else {

                JewelTheme.lightThemeDefinition()

            }



            IntUiTheme(

                themeDefinition,

                styling = ComponentStyling.decoratedWindow(

                    titleBarStyle = when (intUiThemes) {

                        IntUiThemes.Light -> TitleBarStyle.light()

                        IntUiThemes.LightWithLightHeader -> TitleBarStyle.lightWithLightHeader()

                        IntUiThemes.Dark -> TitleBarStyle.dark()

                        IntUiThemes.System -> if (intUiThemes.isDark()) {

                            TitleBarStyle.dark()

                        } else {

                            TitleBarStyle.light()

                        }

                    }

                )

            ) {

                DecoratedWindow(visible = mainWindowVisible,

                    onCloseRequest = {

                        ::exitApplication

                        mainActivityViewModel.exitMainWindow()

                    }, state = rememberWindowState(),

                    title = "${MyApplication.appArgs.appName} (${MyApplication.appArgs.version})",

                    onPreviewKeyEvent = {

                        if (

                            it.key == Key.Escape &&

                            it.type == KeyEventType.KeyDown

                        ) {

                            root.onBackClicked()

                            true

                        } else {

                            false

                        }

                    }

                ) {

                    TitleBarView(intUiThemes)

                    root.render()

                }



            }

            

        }

    }

}

Component

Component：组件，可以是一个窗口，也是可以是窗口中的某一个页面，都可以当成组件处理。

对应单个组件，每个组件封装对应的业务逻辑处理，驱动相应的UI进行显示。

对于业务逻辑的处理，可以采用 Store+Reducer 这种偏前端思想的方式，也可以采用 Android 现在比较流行的 MVI 进行处理。

状态管理容器，只需要提供一些可观察对象就行了，驱动View层进行重组，刷新UI。

组件树：应用中的多个窗口，窗口中的多个页面，可以分别拆分成多个组件，每个组件封装处理各自的逻辑，最后构成一棵组件树的结构。

比如这个应用，被我拆成若干个Componet，分别处理相应的业务逻辑。

@Singleton

@Component(

    modules = [

        PreferenceModule::class

    ]

)

interface AppComponent {



    fun inject(splashScreenComponent: SplashScreenComponent)



    fun inject(mainScreenComponent: MainScreenComponent)



    fun inject(adbScreenComponent: AdbScreenComponent)



    fun inject(analyzeScreenCompoment: AnalyzeScreenCompoment)



    fun inject(updateScreenComponent: UpdateScreenComponent)



    fun inject(importLeakCanaryComponent: ImportLeakCanaryComponent)

}

ViewModel

• ViewModel 这个比较简单，只是一个普通的类，用于处理业务逻辑，并维护UI层所需的状态数据。


• ViewModel 的创建和销毁，这个会利用到 DisposableEffect 这个东西。DisposableEffect 的主要作用是在组合函数的启动和销毁时执行一些清理工作，以确保资源正确释放。


• 在组合函数启动的时候，创建 ViewModel，并进行初始化。


• 在组合函数销毁的时候，销毁 ViewModel，释放 ViewModel 的资源，类似 Android 中 ViewModel 的 clear 方法。

class AnalyzeViewModel @Inject constructor(

    val hprofRepo: HprofRepo

) {



    private lateinit var viewModelScope: CoroutineScope



    fun init(scope: CoroutineScope) {

        this.viewModelScope = scope

    }



    fun analyze(

        heapDumpFile: File, proguardMappingFile: File?

    ) {

        viewModelScope.launch(Dispatchers.IO) {

           //耗时方法，分析文件

        }

    }





    fun dispose() {

        viewModelScope.cancel()

    }

}

/**

 * 分析内存数据

 */

class AnalyzeScreenCompoment(

    appComponent: AppComponent,

    private val componentContext: ComponentContext,

    private val hprofFile: String,

    private val onBackClicked: () -> Unit,

) : Component, ComponentContext by componentContext {





    init {

        appComponent.inject(this)

    }



    @Inject

    lateinit var analyzeViewModel: AnalyzeViewModel



    @Composable

    override fun render() {

        val scope = rememberCoroutineScope()



        DisposableEffect(analyzeViewModel) {

            //初始化ViewModel

            analyzeViewModel.init(scope)

            //调用ViewModel里面的方法

            analyzeViewModel.analyze(heapDumpFile = File(hprofFile), proguardMappingFile = null)



            onDispose {

                //销毁ViewModel

                analyzeViewModel.dispose()

            }

        }



        //观察ViewModel，实现UI逻辑

        analazeScreen(analyzeViewModel)



    }

}

adb 功能开发

比如 dump 内存快照，安装adb，一部分开发者选项控制，本质上都是可以通过 adb 命令进行设置的。

• Adb第三方库：malinskiy.github.io/adam/，这个库是 Kotlin 编写的。


• 库代码主要是协程、Flow、Channel，使用起来挺方便的。


• 一条 adb 命令就是一个 Request，内置了挺多现成的 Request 可以使用，也可以自定义 Request 编写一些复杂的命令。


• 比如使用adb devices，列出当前的设备列表，只需要一行代码即可。

val devices: List<Device> = adb.execute(request = ListDevicesRequest())

• 如果需要监听设备的连接状态变化，可以通过执行 AsyncDeviceMonitorRequest 即可，返回值是一个 Channel 。

val deviceEventsChannel: ReceiveChannel<List<Device>> = adb.execute(

    request = AsyncDeviceMonitorRequest(),

    scope = GlobalScope

)



for (currentDeviceList in deviceEventsChannel) {

    //...

}

• 安装 apk，执行 StreamingPackageInstallRequest，传入相应的参数即可。

    suspend fun installApk(file: String, serial: String): Boolean {

        Arbor.d("installApk file:$file,serial:$serial")

        try {

            val result = adb.execute(

                request = StreamingPackageInstallRequest(

                    pkg = File(file),

                    supportedFeatures = listOf(Feature.CMD),

                    reinstall = true,

                    extraArgs = emptyList()

                ),

                serial = serial

            )

            Arbor.d("installApk:$result")

            return result

        } catch (e: Exception) {

            e.printStackTrace()

            return false

        }

    }

开发者选项控制

打开过度绘制、布局边界

• 开发者选项里面的很多配置，都是系统属性。关于系统属性的部分原理，可以在这里了解一下。

Android 系统属性学习与使用 - 掘金

• 一部分系统属性，是可以支持 adb 修改，并且可以立马生效的。


• 比如布局边界的属性是 debug.layout，设置为 true 即可打开开关。


• 比如过度绘制对应的属性是 debug.hwui.overdraw，设置为 show 即可打开开关。


• 通过下面几个 adb 命令，转化成相应的代码实现即可。

//读取所有的prop,会输出所有系统属性的key和value

adb shell getprop

//读取key为propName的系统属性

adb shell getprop ${propName}

//修改key为propName的系统属性，新值为propValue

adb shell setprop ${propName} ${propValue}

• adb shell service call activity 1599295570，这个命令，主要是为了修改 prop 之后能够立马生效。

    /**

     * 修改 prop 手机配置

     */

    suspend fun changeProp(propName: String, propValue: String, serial: String) {

        adb.execute(request = ShellCommandRequest("setprop $propName $propValue"), serial = serial)

        adb.execute(request = ShellCommandRequest("service call activity 1599295570"), serial = serial)

    }

跳转到开发者选项页面

有些开关还是得手动去设置的，所以提供了这样的一个按钮，点击直接跳转到开发者选项页面。

如果使用命令是这样的。

adb shell am start -a com.android.settings.APPLICATION_DEVELOPMENT_SETTINGS

转化成对应的代码实现。

    suspend fun startDevelopActivity(serial: String){

        adb.execute(

            request = ShellCommandRequest("am start -a com.android.settings.APPLICATION_DEVELOPMENT_SETTINGS"),

            serial = serial

        )

    }

内存分析

• 这里就不细讲了，主要是使用 shark 库进行解析 Hprof 文件，然后分析内存泄露问题。


• 使用shark库解析Hprof文件：juejin.cn/post/704375…。


• 过程挺简单的，就是通过 adb dump 出内存快照文件，然后 pull 到电脑上，并删掉原文件。

1、识别本地所有应用的 packageName

2、adb shell ps | grep packageName 查看应用 pid

3、adb shell am dumpheap <PID>  <HEAP-DUMP-FILE-PATH>  开始 dump pid 进程的 hprof 文件到 path

4、adb pull 命令

• 另一种情况，如果你有使用 LeakCanary，但是 LeakCanary App是运行在手机上的，在手机上查看泄露引用链，其实不是那么方便。


• 后面分析了一下，LeakCanary 生成的文件，都放在了 /storage/emulated/0/Download 的目录下，所以搞个命令一键拉取到电脑上，在软件里面进行分析即可。

Html 文件生成

根据内存分析结果，生成一份 html 格式的文件报告，方便在浏览器中进行预览。

• 尴尬的是，自己不太会写 html，另一个是，这个软件是纯 Kotlin 开发，要引入 js 貌似也不太方便。


• github.com/Kotlin/kotl…


• 刚好官方有个 kotlinx-html 库，可以使用 Kotlin 来开发 HTML 页面。


• 引入相关依赖

    implementation("org.jetbrains.kotlinx:kotlinx-html-jvm:0.9.1")

    implementation("org.jetbrains.kotlinx:kotlinx-html:0.9.1")

• 按照官方文档进行使用，还是挺简单的。

        val html = createHTML().html {

            head {

                title { +"My HTML File" }

            }

            body {

                h1 { +"Memory Analysis Report" }

                h2 { +"Basic Info" }

                p { +"Heap dump file path: ${hprofFile}" }



                p { +"Build.VERSION.SDK_INT: ${androidMetadataMap?.get("Build.VERSION.SDK_INT")}" }

                p { +"Build.MANUFACTURER: ${androidMetadataMap?.get("Build.MANUFACTURER")}" }

                p { +"App process name: ${androidMetadataMap?.get("App process name")}" }



                h2 { +"Memory leaks" }

            }

        }

下载地址

现在只有 mac 版本，没有 windows 版本。

http://www.github.com/LXD31256949…

填写License key可以激活：9916E3FF-2189-4A8E-B721-94442CDAA215

总结

• 这篇文章，算是对这个软件的一个阶段性总结吧。


• 一个是学习 Compose 相关的知识，以及了解 compose-desktop 相关的桌面组件，并进行开发桌面应用。


• 另一个方面是 Android 这方面的知识学习。

前言

目前大多数库api设计都是Log.d("tag", "msg")这种风格，而且支持自定义日志存储的比较少，
所以作者想自己造一个轮子。

这种api风格有什么不好呢？

首先，它的tag是一个字符串，需要开发人员严格管理tag，要不然可能各种硬编码的tag满天飞。

另外，它也可能导致性能陷阱，假设有这么一段代码：

// 打印一个List

Log.d("tag", list.joinToString())

此处使用Debug打印日志，生产模式下调高日志等级，不打印这一行日志，但是list.joinToString()这一行代码仍然会被执行，有可能导致性能问题。

下文会分析作者期望的api是什么样的，本文演示代码都是用kotlin，库中好用的api也是基于kotlin特性来实现的。

作者写库有个习惯，对外开放的类或者全局方法都会加一个前缀f，一个是为了避免命名冲突，另一个是为了方便代码检索，以下文章中会出现，这里做一下解释。

期望

什么样的api才能解决上面的问题呢？我们看一下方法的签名和打印方式

inline fun <reified T : FLogger> flogD(block: () -> Any)

interface AppLogger : FLogger

flogD<AppLogger> {

    list.joinToString { it }

}

flogD方法打印Debug日志，传一个Flogger的子类AppLogger作为日志标识，同时传一个block来返回要打印的日志内容。

日志标识是一个类或者接口，所以管理方式比较简单不会造成tag混乱的问题，默认tag是日志标识类的短类名。生产模式下调高日志等级后，block就不会被执行了，避免了可能的性能问题。

实现分析

日志库的完整实现已经写好了，放在这里xlog

• 支持限制日志大小，例如限制每天只能写入10MB的日志


• 支持自定义日志格式


• 支持自定义日志存储，即如何持久化日志

这一节主要分析一下实现过程中遇到的问题。

问题：如果App运行期间日志文件被意外删除了，怎么处理？

在Android中，用java.io的api对一个文件进行写入，如果文件被删除，继续写入的话不会抛异常，这样会导致日志丢失，该如何解决？

有同学说，在写入之前先检查文件是否存在，如果存在就继续写入，不存在就创建后写入。

检查一个文件是否存在通常是调用java.io.File.exist()方法，但是它比较耗性能，我们来做一个测试：

measureTime {

    repeat(1_0000) {

        file.exists()

    }

}.let {

    Log.i("MainActivity", "time:${it.inWholeMilliseconds}")

}

14:50:33.536 MainActivity            com.sd.demo.xlog                I  time:39

14:50:35.872 MainActivity            com.sd.demo.xlog                I  time:54

14:50:38.200 MainActivity            com.sd.demo.xlog                I  time:43

14:50:40.028 MainActivity            com.sd.demo.xlog                I  time:53

14:50:41.693 MainActivity            com.sd.demo.xlog                I  time:58

可以看到1万次调用的耗时在50毫秒左右。

我们再测试一下对文件写入的耗时：

val output = filesDir.resolve("log.txt").outputStream().buffered()

val log = "1".repeat(50).toByteArray()

measureTime {

    repeat(1_0000) {

        output.write(log)

        output.flush()

    }

}.let {

    Log.i("MainActivity", "time:${it.inWholeMilliseconds}")

}

14:57:56.092 MainActivity            com.sd.demo.xlog                I  time:38

14:57:56.558 MainActivity            com.sd.demo.xlog                I  time:57

14:57:57.129 MainActivity            com.sd.demo.xlog                I  time:57

14:57:57.559 MainActivity            com.sd.demo.xlog                I  time:46

14:57:58.054 MainActivity            com.sd.demo.xlog                I  time:54

可以看到1万次调用，每次写入50个字符的耗时也在50毫秒左右。如果每次写入日志前都判断一下文件是否存在，那么实际上相当于2次写入的性能成本，这显然很不划算。

还有同学说，开一个线程，定时判断文件是否存在，这样子虽然不会损耗单次写入的性能，但是又多占用了一个线程资源，显然也不符合作者的需求。

其实Android已经给我们提供了这种场景的解决方案，那就是android.os.MessageQueue.IdleHandler，关于IdleHandler这里就不展开讨论了，简单来说就是当你在主线程注册一个IdleHandler后，它会在主线程空闲的时候被执行。

我们可以在每次写入日志之后注册IdleHandler，等IdleHandler被执行的时候检查一下日志文件是否存在，如果不存在就关闭输出流，这样子在下一次写入的时候就会重新创建文件写入了。

这里要注意每次写入日志之后注册IdleHandler，并不是每次都创建新对象，要判断一下如果原先的对象还未执行的话就不用注册一个新的IdleHandler，库中大概的代码如下：

private class LogFileChecker(private val block: () -> Unit) {

    private var _idleHandler: IdleHandler? = null



    fun register(): Boolean {

        // 如果当前线程没有Looper则不注册，上层逻辑可以直接检查文件是否存在，因为是非主线程

        Looper.myLooper() ?: return false

        

        // 如果已经注册过了，直接返回

        _idleHandler?.let { return true }

        

        val idleHandler = IdleHandler {

            // 执行block检查任务

            libTryRun { block() }

            

            // 重置变量，等待下次注册

            _idleHandler = null

            false

        }

        

        // 保存并注册idleHandler

        _idleHandler = idleHandler

        Looper.myQueue().addIdleHandler(idleHandler)

        return true

    }

}

这样子文件被意外删除之后，就可以重新创建写入了，避免丢失大量的日志。

问题：如何检测文件大小是否溢出

库支持对每天的日志大小做限制，例如限制每天最多只能写入10MB，每次写入日志之后都会检查日志大小是否超过限制，通常我们会调用java.io.File.length()方法获取文件的大小，但是它也比较耗性能，我们来做一个测试：

val file = filesDir.resolve("log.txt").apply {

    this.writeText("hello")

}

measureTime {

    repeat(1_0000) {

        file.length()

    }

}.let {

    Log.i("MainActivity", "time:${it.inWholeMilliseconds}")

}

16:56:04.090 MainActivity            com.sd.demo.xlog                I  time:61

16:56:05.329 MainActivity            com.sd.demo.xlog                I  time:80

16:56:06.382 MainActivity            com.sd.demo.xlog                I  time:72

16:56:07.496 MainActivity            com.sd.demo.xlog                I  time:79

16:56:08.591 MainActivity            com.sd.demo.xlog                I  time:78

可以看到耗时在60毫秒左右，相当于上面测试中1次文件写入的耗时。

库中支持自定义日志存储，在日志存储接口中定义了size()方法，上层通过此方法来判断当前日志的大小。

如果自定义了日志存储，避免在此方法中每次调用java.io.File.length()来返回日志大小，应该维护一个表示日志大小的变量，变量初始化的时候获取一下java.io.File.length()，后续通过写入的数量来增加这个变量的值，并在size()方法中返回。库中默认的日志存储实现类就是这样实现的，有兴趣的可以看这里

问题：文件大小溢出后怎么处理？

假设限制每天最多只能写入10MB，那超过10MB后如何处理？有同学说直接删掉或者清空文件，重新写入，这也是一种策略，但是会丢失之前的所有日志。

例如白天写了9.9MB，到晚上的时候写满10MB，清空之后，白天的日志都没了，这时候用户反馈白天遇到的一个bug，需要上传日志，那就芭比Q了。

有没有办法少丢失一些呢？可以把日志分多个文件存储，为了便于理解假设分为2个文件存储，一天10MB，那1个文件最多只能写入5MB。具体步骤如下：

这时候继续写日志的话，发现20231128.log文件不存在就会创建，又跳到了步骤1，就这样一直重复1和2两个步骤，到晚上写满10MB的时候，至少还有5MB的日志内容保存在20231128.log.1文件中避免丢失全部的日志。

分的文件数量越多，保留的日志就越多，实际上就是拿出一部分空间当作中转区，满了就向后递增数字重命名备份。目前库中只分为2个文件存储，暂时不开放自定义文件数量。

问题：打印日志的性能

性能，是这个库最关心的问题，通常来说文件写入操作是性能开销的大头，目前是用java.io相关的api来实现的，怎样提高写入性能作者也一直在探索，在demo中提供了一个基于内存映射的日志存储方案，但是稳定性未经测试，后续测试通过后可能会转正。有兴趣的读者可以看看这里。

还有一个比较影响性能的就是日志的格式化，通常要把一个时间戳转为某个日期格式，大部分人都会用java.text.SimpleDateFormat来格式化，用它来格式化年:月:日的时候问题不大，但是如果要格式化时:分:秒.毫秒那它就比较耗性能，我们来做一个测试：

val format = SimpleDateFormat("HH:mm:ss.SSS")

val millis = System.currentTimeMillis()

measureTime {

    repeat(1_0000) {

        format.format(millis)

    }

}.let {

    Log.i("MainActivity", "time:${it.inWholeMilliseconds}")

}

16:05:26.920 MainActivity            com.sd.demo.xlog                I  time:245

16:05:27.586 MainActivity            com.sd.demo.xlog                I  time:227

16:05:28.324 MainActivity            com.sd.demo.xlog                I  time:212

16:05:29.370 MainActivity            com.sd.demo.xlog                I  time:217

16:05:30.157 MainActivity            com.sd.demo.xlog                I  time:193

可以看到1万次格式化耗时大概在200毫秒左右。

我们再用java.util.Calendar测试一下：

val calendar = Calendar.getInstance()

// 时间戳1

val millis1 = System.currentTimeMillis()

// 时间戳2

val millis2 = millis1 + 1000

// 切换时间戳标志

var flag = true

measureTime {

    repeat(1_0000) {

        calendar.timeInMillis = if (flag) millis1 else millis2

        calendar.run {

            "${get(Calendar.HOUR_OF_DAY)}:${get(Calendar.MINUTE)}:${get(Calendar.SECOND)}.${get(Calendar.MILLISECOND)}"

        }

        flag = !flag

    }

}.let {

    Log.i("MainActivity", "time:${it.inWholeMilliseconds}")

}

16:11:25.342 MainActivity            com.sd.demo.xlog                I  time:35

16:11:26.209 MainActivity            com.sd.demo.xlog                I  time:35

16:11:27.316 MainActivity            com.sd.demo.xlog                I  time:37

16:11:28.057 MainActivity            com.sd.demo.xlog                I  time:25

16:11:28.825 MainActivity            com.sd.demo.xlog                I  time:18

这里解释一下为什么要用两个时间戳，因为Calendar内部有缓存，如果用同一个时间戳测试的话，没办法评估它真正的性能，所以这里每次格式化之后就切换到另一个时间戳，避免缓存影响测试。

可以看到1万次的格式化耗时在30毫秒左右，差距很大。如果要自定义日志格式的话，建议用Calendar来格式化时间，有更好的方案欢迎和作者交流。

问题：日志的格式如何显示

手机的存储资源是宝贵的，如何定义日志格式也是一个比较重要的细节。

• 优化时间显示

目前库内部是以天为单位来命名日志文件的，例如：20231128.log，所以在格式化时间戳的时候只保留了时:分:秒.毫秒，避免冗余显示当天的日期。

• 优化日志等级显示

打印的时候提供了4个日志等级：Verbose, Debug, Info, Warning, Error，一般最常用的记录等级是Info，所以在格式化的时候如果等级是Info则不显示等级标志，规则如下：

private fun FLogLevel.displayName(): String {

    return when (this) {

        FLogLevel.Verbose -> "V"

        FLogLevel.Debug -> "D"

        FLogLevel.Warning -> "W"

        FLogLevel.Error -> "E"

        else -> ""

    }

}

• 优化日志标识显示

如果连续2条或多条日志都是同一个日志标识，那么就只有第1条日志会显示日志tag

• 优化线程ID显示

如果是主线程的话，不显示线程ID，只有非主线程才显示线程ID

经过上面的优化之后，日志打印的格式是这样的：

flogI<AppLogger> { "1" }

flogI<AppLogger> { "2" }

flogW<AppLogger> { "3" }

flogI<UserLogger> { "user debug" }

thread {

    flogI<UserLogger> { "thread" }

}

19:19:43.961[AppLogger] 1

19:19:43.974 2

19:19:43.975[W] 3

19:19:43.976[UserLogger] user debug

19:19:43.977[12578] thread

API

这一节介绍一下库的API，调用FLog.init()方法初始化，初始化如果不想打印日志，可以调用FLog.setLevel(FLogLevel.Off)关闭日志

常用方法

// 初始化

FLog.init(

    //（必传参数）日志文件目录

    directory = filesDir.resolve("app_log"),



    //（可选参数）自定义日志格式

    formatter = AppLogFormatter(),

    

    //（可选参数）自定义日志存储

    storeFactory = AppLogStoreFactory(),



    //（可选参数）是否异步发布日志，默认值false

    async = false,

)



// 设置日志等级 All, Verbose, Debug, Info, Warning, Error, Off  默认日志等级：All

FLog.setLevel(FLogLevel.All)



// 限制每天日志文件大小(单位MB)，小于等于0表示不限制大小，默认限制每天日志大小100MB

FLog.setLimitMBPerDay(100)



// 设置是否打打印控制台日志，默认打开

FLog.setConsoleLogEnabled(true)



/**

 * 删除日志，参数saveDays表示要保留的日志天数，小于等于0表示删除全部日志，

 * 此处saveDays=1表示保留1天的日志，即保留当天的日志

 */

FLog.deleteLog(1)

打印日志

interface AppLogger : FLogger

flogV<AppLogger> { "Verbose" }

flogD<AppLogger> { "Debug" }

flogI<AppLogger> { "Info" }

flogW<AppLogger> { "Warning" }

flogE<AppLogger> { "Error" }



// 打印控制台日志，不会写入到文件中，不需要指定日志标识，tag：DebugLogger

fDebug { "console debug log" }

配置日志标识

可以通过FLog.config方法修改某个日志标识的配置信息，例如下面的代码：

FLog.config<AppLogger> {

    // 修改日志等级

    this.level = FLogLevel.Debug



    // 修改tag

    this.tag = "AppLoggerAppLogger"

}

自定义日志格式

class AppLogFormatter : FLogFormatter {

    override fun format(record: FLogRecord): String {

        // 自定义日志格式

        return record.msg

    }

}

interface FLogRecord {

    /** 日志标识 */

    val logger: Class<out FLogger>



    /** 日志tag */

    val tag: String



    /** 日志内容 */

    val msg: String



    /** 日志等级 */

    val level: FLogLevel



    /** 日志生成的时间戳 */

    val millis: Long



    /** 日志是否在主线程生成 */

    val isMainThread: Boolean



    /** 日志生成的线程ID */

    val threadID: String

}

自定义日志存储

日志存储是通过FLogStore接口实现的，每一个FLogStore对象负责管理一个日志文件。
所以需要提供一个FLogStore.Factory工厂为每个日志文件提供FLogStore对象。

class AppLogStoreFactory : FLogStore.Factory {

    override fun create(file: File): FLogStore {

        return AppLogStore(file)

    }

}

class AppLogStore(file: File) : FLogStore {

    // 添加日志

    override fun append(log: String) {}



    // 返回当前日志的大小

    override fun size(): Long = 0



    // 关闭

    override fun close() {}

}

结束

库目前还处于alpha阶段，如果有遇到问题可以及时反馈给作者，最后感谢大家的阅读。

作者邮箱：565061763@qq.com

上篇文章讲的是状态管理（传送门）提到了 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 的评论

关于我 && 博客

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

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

在日常开发中，我们经常会遇到需要修改同事代码的情况。有时可能会花费很长时间却只改动了几行代码，而且改完后还可能引发新的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，那么这条请求将永远不会成功。

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

前言：搞懂 Android 系统和汽车到底有什么关系。

一、基本概念

1、Android Auto

1）是什么

• Android Atuo 是一个 Android 端的 app，专门为驾驶环境设计的；


• 运行环境：需要在 Android 5.0 或者更高版本的系统，并且需要 Google 地图和 Google Play 音乐应用；

2）功能

• Android Atuo 可以用来将 Android 设备上的部分功能映射到汽车屏幕上；


• 满足了很多人在开车时会使用手机的需求；

2、Google Assistant

• Google 将 GoofleAssistant 集成到 AndroidAuto 中；


• 交互方式有键盘、触摸、语音等；


• 对于汽车来说，语音无疑是比触摸更好的交互方式；


• 在驾驶环境中，语音交换存在的优势
  
  
  
  • 用户不改变自身的物理姿势，这种交互方式不影响驾驶员对驾驶的操作；
  
  
  • 有需要多次触摸的交互时，可能只需要一条语音就可以完成；
  
  
  • 语音交互不存在入口的层次嵌套，数据更加扁平；
  
  
  • 优秀的语音系统可以利用对话的上下文完成任务，避免用户重复输入；
  
  
  
  

3、Android Automotive

1、Android Auto 和 Android Automotive 的区别

• Android Auto 是以手机为中心的
  
  
  
  • 好处：数据和应用始终是一致的，不存在需要数据同步的问题，手机上装的软件和已有数据，接到汽车上就直接有了；
  
  
  • 坏处：每次都需要拿出手机，汽车只是作为手机的一个外设；这种模式不便于对于汽车本身的控制和相关数据的获取；
  
  
  
  


• Android Automotive
  
  
  
  • 如果将系统直接内置于汽车中，会大大提升用户体验；
  
  
  • Android Automotive 就是面向这个方向进行设计的；
  
  
  • 一旦将系统内置于汽车，可以完成的功能就会大大增加；例如，直接在中控触摸屏上调整座椅和空调；同时，系统也能获取更多关于汽车的信息，例如：油耗水平、刹车使用等；
  
  
  
  

加两张中控和仪表的图片

4、App

1）App 的开发

• Android Auto 目前仅支持两类第三方应用
  
  
  
  • 音频应用：允许用户浏览和播放汽车中的音乐和语音内容；
  
  
  • 消息应用：通过 text-to-speech 朗读消息并通过语音输入回复消息；
  
  
  
  

2）App 的设计

• Google 专门为 Android Auto 上的 UI 设计做了一个指导网站：Auto UI guidelines；


• 基本指导原则（车机交互系统的借鉴）
  
  
  
  • Android Auto 上的互动步调必须由驾驶员控制；
  
  
  • 汽车界面上的触摸目标必须足够大，以便可以轻松地浏览和点击；
  
  
  • 适当的私彩对比可以帮助驾驶员快速解读信息并做出决定；
  
  
  • 应用必须支持夜间模式，因为过高的强度可能会干扰注意力；
  
  
  • Roboto 字体在整个系统中用于保持一致性并帮助提高可读性；
  
  
  • 通过触摸来进行分页应用用来作为滑动翻页的补充；
  
  
  • 有节制地使用动画来描述两个状态间的变化；
  
  
  
  

二、源码和架构

1、Android Automative的整体架构

• Android Automative 的源码包含在 AOSP 中；


• Android Automative 是在原先 Android的 系统架构上增加了一些与车相关的（图中虚线框中绿色背景的）模块；
  
  
  
  • Car App：包括 OEM 和第三方开发的 App；
    
    
    
    • OEM：就是汽车厂商利用自身掌握的核心技术负责设计和开发新产品，而具体的生产制造任务则通过合同订购的方式委托给同类产品的其他厂家进行，最终产品会贴上汽车厂商自己的品牌商标。这种生产方式被称为定牌生产合作，俗称“贴牌”。承接这种加工任务的制造商就被称为OEM厂商，其生产的产品就是OEM产品；
    
    
    
    
  
  
  • Car API：提供给汽车 App 特有的接口；
  
  
  • Car Service：系统中与车相关的服务；
  
  
  • Vehicle Network Service：汽车的网络服务；
  
  
  • Vehicle HAL：汽车的硬件抽象层描述；
  
  
  
  

1）Car App

• /car_product/build/car.mk 这个文件中列出了汽车系统中专有的模块；


• 列表中，首字母大写的模块基本上都是汽车系统中专有的 App；


• App的源码都位于 /platform/packages/services/Car/ 目录下
  
  

  # Automotive specific packages
  
  PRODUCT_PACKAGES += \
  
      vehicle_monitor_service \
  
      CarService \
  
      CarTrustAgentService \
  
      CarDialerApp \
  
      CarRadioApp \
  
      OverviewApp \
  
      CarLensPickerApp \
  
      LocalMediaPlayer \
  
      CarMediaApp \
  
      CarMessengerApp \
  
      CarHvacApp \
  
      CarMapsPlaceholder \
  
      CarLatinIME \
  
      CarUsbHandler \
  
      android.car \
  
      libvehiclemonitor-native \
  
  

  
  

2）Car API

• 开发汽车专有的App自然需要专有的API；


• 这些API对于其他平台（例如手机和平板）通常是没有意义的；


• 所以这些API没有包含在Android Framework SDK中；


• 下图列出了所有的 Car API；

• android.car：包含了与车相关的基本API。例如：车辆后视镜，门，座位，窗口等。
  
  
  
  • cabin：座舱相关API。
  
  
  • hvac：通风空调相关API。（hvac是Heating, ventilation and air conditioning的缩写）
  
  
  • property：属性相关API。
  
  
  • radio：收音机相关API。
  
  
  • pm：应用包相关API。
  
  
  • render：渲染相关API。
  
  
  • menu：车辆应用菜单相关API。
  
  
  • annotation：包含了两个注解。
  
  
  • app
  
  
  • cluster：仪表盘相关API。
  
  
  • content
  
  
  • diagnostic：包含与汽车诊断相关的API。
  
  
  • hardware：车辆硬件相关API。
  
  
  • input：输入相关API。
  
  
  • media：多媒体相关API。
  
  
  • navigation：导航相关API。
  
  
  • settings：设置相关API。
  
  
  • vms：汽车监测相关API。
  
  
  
  

3）Car Service

• Car Service并非一个服务，而是一系列的服务。这些服务都在ICarImpl.java构造函数中列了出来；

public ICarImpl(Context serviceContext, IVehicle vehicle, SystemInterface systemInterface,

        CanBusErrorNotifier errorNotifier) {

    mContext = serviceContext;

    mHal = new VehicleHal(vehicle);

    mSystemActivityMonitoringService = new SystemActivityMonitoringService(serviceContext);

    mCarPowerManagementService = new CarPowerManagementService(

            mHal.getPowerHal(), systemInterface);

    mCarSensorService = new CarSensorService(serviceContext, mHal.getSensorHal());

    mCarPackageManagerService = new CarPackageManagerService(serviceContext, mCarSensorService,

            mSystemActivityMonitoringService);

    mCarInputService = new CarInputService(serviceContext, mHal.getInputHal());

    mCarProjectionService = new CarProjectionService(serviceContext, mCarInputService);

    mGarageModeService = new GarageModeService(mContext, mCarPowerManagementService);

    mCarInfoService = new CarInfoService(serviceContext, mHal.getInfoHal());

    mAppFocusService = new AppFocusService(serviceContext, mSystemActivityMonitoringService);

    mCarAudioService = new CarAudioService(serviceContext, mHal.getAudioHal(),

            mCarInputService, errorNotifier);

    mCarCabinService = new CarCabinService(serviceContext, mHal.getCabinHal());

    mCarHvacService = new CarHvacService(serviceContext, mHal.getHvacHal());

    mCarRadioService = new CarRadioService(serviceContext, mHal.getRadioHal());

    mCarNightService = new CarNightService(serviceContext, mCarSensorService);

    mInstrumentClusterService = new InstrumentClusterService(serviceContext,

            mAppFocusService, mCarInputService);

    mSystemStateControllerService = new SystemStateControllerService(serviceContext,

            mCarPowerManagementService, mCarAudioService, this);

    mCarVendorExtensionService = new CarVendorExtensionService(serviceContext,

            mHal.getVendorExtensionHal());

    mPerUserCarServiceHelper = new PerUserCarServiceHelper(serviceContext);

    mCarBluetoothService = new CarBluetoothService(serviceContext, mCarCabinService,

            mCarSensorService, mPerUserCarServiceHelper);

    if (FeatureConfiguration.ENABLE_VEHICLE_MAP_SERVICE) {

        mVmsSubscriberService = new VmsSubscriberService(serviceContext, mHal.getVmsHal());

        mVmsPublisherService = new VmsPublisherService(serviceContext, mHal.getVmsHal());

    }

    mCarDiagnosticService = new CarDiagnosticService(serviceContext, mHal.getDiagnosticHal());

4）Car Tool

a、VMS

• VMS全称是Vehicle Monitor Service。正如其名称所示，这个服务用来监测其他进程；


• 在运行时，这个服务是一个独立的进程，在init.car.rc中有关于它的配置

service vms /system/bin/vehicle_monitor_service

   class core

   user root

   group root

   critical



on boot

    start vms

• 这是一个Binder服务，并提供了C++和Java的Binder接口用来供其他模块使用；

简介

Fusion 是新一代的混合栈管理框架，用于 Flutter 与 Native 页面统一管理，并支持页面通信、页面生命周期监听等功能。Fusion 即 融合，我们的设计初衷就是帮助开发者在使用 Flutter 与 Native 进行混合开发时尽量感受不到两者的隔阂，提升开发体验。此外，Fusion 彻底解决了混合开发过程中普遍存在的黑屏、白屏、闪屏等问题，更加适合重视用户体验的App使用。

从 4.0 开始，Fusion 已完成纯鸿蒙平台（HarmonyOS Next/OpenHarmony，以下简称 HarmonyOS）的适配，开发者可以在Android、iOS、HarmonyOS上得到完全一致的体验。（HarmonyOS 的 Flutter SDK 可以在这里获取）

Fusion 采用引擎复用方案，在 Flutter 与 Native 页面多次跳转情况下，APP 始终仅有一份 FlutterEngine 实例，因此拥有更好的性能和更低的内存占用。

Fusion 也是目前仅有的支持混合开发时应用在后台被系统回收后，所有Flutter页面均可正常恢复的混合栈框架。

开始使用

0、准备

在开始前需要按照 Flutter 官方文档，将 Flutter Module 项目接入到 Android、iOS、HarmonyOS 工程中。

1、初始化

Flutter 侧

使用 FusionApp 替换之前使用的 App Widget，并传入所需路由表，默认路由表和自定义路由表可单独设置也可同时设置。

void main() {

  runApp(FusionApp(

    // 默认路由表

    routeMap: routeMap,

    // 自定义路由表

    customRouteMap: customRouteMap,

  ));

}



// 默认路由表，使用默认的 PageRoute

// 使用统一的路由动画

final Map<String, FusionPageFactory> routeMap = {

  '/test': (arguments) => TestPage(arguments: arguments),

  kUnknownRoute: (arguments) => UnknownPage(arguments: arguments),

};



// 自定义路由表，可自定义 PageRoute

// 比如：某些页面需要特定的路由动画则可使用该路由表

final Map<String, FusionPageCustomFactory> customRouteMap = {

  '/mine': (settings) => PageRouteBuilder(

      opaque: false,

      settings: settings,

      pageBuilder: (_, __, ___) => MinePage(

          arguments: settings.arguments as Map<String, dynamic>?)),

};

P.S: kUnknownRoute表示未定义路由

注意：如果项目使用了 flutter_screenutil，需要在 runApp 前调用 Fusion.instance.install()，没有使用 flutter_screenutil则无须该步骤。

void main() {

  Fusion.instance.install();

  runApp(FusionApp(

    // 默认路由表

    routeMap: routeMap,

    // 自定义路由表

    customRouteMap: customRouteMap,

  ));

}

Android 侧

在 Application 中进行初始化，并实现 FusionRouteDelegate 接口

class MyApplication : Application(), FusionRouteDelegate {



    override fun onCreate() {

        super.onCreate()

        Fusion.install(this, this)

    }



    override fun pushNativeRoute(name: String?, arguments: Map<String, Any>?) {

        // 根据路由 name 跳转对应 Native 页面

    }



    override fun pushFlutterRoute(name: String?, arguments: Map<String, Any>?) {

        // 根据路由 name 跳转对应 Flutter 页面

        // 可在 arguments 中存放参数判断是否需要打开透明页面

    }

}

iOS 侧

在 AppDelegate 中进行初始化，并实现 FusionRouteDelegate 代理

@UIApplicationMain

@objc class AppDelegate: UIResponder, UIApplicationDelegate, FusionRouteDelegate {

    

    func application(

    _ application: UIApplication,

    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?

  ) -> Bool {

      ...

      Fusion.instance.install(self)

      ...

    return true

  }

    

    func pushNativeRoute(name: String?, arguments: Dictionary<String, Any>?) {

        // 根据路由 name 跳转对应 Native 页面

    }

    

    func pushFlutterRoute(name: String?, arguments: Dictionary<String, Any>?) {

        // 根据路由 name 跳转对应 Flutter 页面

        // 可在 arguments 中存放参数判断是否需要打开透明页面

        // 可在 arguments 中存放参数判断是 push 还是 present

    }

}

HarmonyOS 侧

在 UIAbility 中进行初始化，并实现 FusionRouteDelegate 代理

export default class EntryAbility extends UIAbility implements FusionRouteDelegate {

  private static TAG = 'EntryAbility'

  private mainWindow: window.Window | null = null

  private windowStage: window.WindowStage | null = null



  override async onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): Promise<void> {

    await Fusion.instance.install(this.context, this)

    GeneratedPluginRegistrant.registerWith(Fusion.instance.defaultEngine!)

  }



  pushNativeRoute(name: string, args: Map<string, Object> | null): void {

    // 根据路由 name 跳转对应 Native 页面

  }



  pushFlutterRoute(name: string, args: Map<string, Object> | null): void {

    // 根据路由 name 跳转对应 Flutter 页面

    // 可在 arguments 中存放参数判断是否需要打开透明页面

  }

}

2、Flutter 容器

普通页面模式

Android 侧

通过 FusionActivity（或其子类） 创建 Flutter 容器，启动容器时需要使用 Fusion 提供的 buildFusionIntent 方法，其中参数 transparent 需设为 false。其 xml 配置参考如下（如果使用 FusionActivity 则不用配置）：

        <activity

            android:name=".CustomFusionActivity"

            android:configChanges="orientation|keyboardHidden|keyboard|screenSize|smallestScreenSize|locale|layoutDirection|fontScale|screenLayout|density|uiMode"

            android:exported="false"

            android:hardwareAccelerated="true"

            android:launchMode="standard"

            android:theme="@style/FusionNormalTheme"

            android:windowSoftInputMode="adjustResize" />

iOS 侧

通过 FusionViewController （或其子类）创建 Flutter 容器，push 和 present 均支持。FusionViewController 默认隐藏了 UINavigationController。

在 iOS 中需要处理原生右滑退出手势和 Flutter 手势冲突的问题，解决方法也很简单：只需在自定义的 Flutter 容器中实现 FusionPopGestureHandler 并在对应方法中启用或者关闭原生手势即可，这样可以实现如果当前 Flutter 容器存在多个 Flutter 页面时，右滑手势是退出 Flutter 页面，而当 Flutter 页面只有一个时则右滑退出 Flutter 容器。

    // 启用原生手势

    func enablePopGesture() {

        // 以下代码仅做演示，不可直接照搬，需根据APP实际情况自行实现

        navigationController?.interactivePopGestureRecognizer?.isEnabled = true

    }



    // 关闭原生手势

    func disablePopGesture() {

        // 以下代码仅做演示，不可直接照搬，需根据APP实际情况自行实现

        navigationController?.interactivePopGestureRecognizer?.isEnabled = false

    }

HarmonyOS 侧

通过 FusionEntry（或其子类） 创建 Flutter 容器，启动容器时需要使用 Fusion 提供的 buildFusionParams 方法，也可直接使用 FusionPage。默认全屏模式。

    const params = buildFusionParams(name, args, false, backgroundColor)

    this.mainLocalStorage?.setOrCreate('params', params)

    router.pushNamedRoute({name: FusionConstant.FUSION_ROUTE_NAME})

透明页面模式

Android 侧

使用方式与普通页面模式相似，只是buildFusionIntent 方法的参数 transparent 需设为 true，其 xml 配置参考如下：

        <activity

            android:name=".TransparentFusionActivity"

            android:configChanges="orientation|keyboardHidden|keyboard|screenSize|smallestScreenSize|locale|layoutDirection|fontScale|screenLayout|density|uiMode"

            android:exported="false"

            android:hardwareAccelerated="true"

            android:launchMode="standard"

            android:theme="@style/FusionTransparentTheme"

            android:windowSoftInputMode="adjustResize" />

iOS 侧

使用方式与普通页面模式相似：

let fusionVc = CustomViewController(routeName: name, routeArguments: arguments, transparent: true)

navController?.present(fusionVc, animated: false)

HarmonyOS 侧

使用方式与普通页面模式相似：

    const params = buildFusionParams(name, args, true, backgroundColor)

    this.windowStage?.createSubWindow(FusionConstant.TRANSPARENT_WINDOW, (_, win) => {

      const record: Record<string, Object> = {

        'params': params

      }

      win.loadContentByName(FusionConstant.FUSION_ROUTE_NAME, new LocalStorage(record))

      win.showWindow()

    })

Flutter 侧

同时Flutter页面背景也需要设置为透明

子页面模式

子页面模式是指一个或多个 Flutter 页面同时嵌入到 Native 容器中的场景，如：使用Tab切换Flutter和原生页面，Fusion 支持多个 Flutter 页面嵌入同一个 Native 容器中

Android 侧

使用 FusionFragment 以支持子页面模式，创建 FusionFragment 对象需要使用 buildFusionFragment 方法

iOS 侧

与页面模式一样使用 FusionViewController

HarmonyOS 侧

与页面模式一样使用 FusionEntry，配合 buildFusionParams方法配置参数

自定义容器背景色

默认情况下容器的背景为白色，这是因为考虑到绝大多数的页面都是使用白色背景，但如果打开的首个Flutter页面的背景是其他颜色，比如夜间模式下页面为深灰色，此时是为了更好的视觉效果，可以自定义容器的背景色与首个Flutter页面的背景色一致。

Android 侧

在 buildFusionIntent 和 buildFusionFragment方法中参数 backgroundColor 设为所需背景色

iOS 侧

在创建 FusionViewController （或其子类）对象时，参数 backgroundColor 设为所需背景色

HarmonyOS 侧

在 buildFusionParams方法中参数 backgroundColor 设为所需背景色

3、路由API（FusionNavigator）

• push：将对应路由入栈，Navigator.pushNamed 与之等同，根据FusionRouteType分为以下几种方式：
  
  
  
  • flutter模式: 在当前Flutter容器中将指定路由对应的Flutter页面入栈，如果没有则跳转kUnknownRoute对应Flutter页面
  
  
  • flutterWithContainer模式: 创建一个新的Flutter容器，并将指定路由对应的Flutter页面入栈，如果没有则跳转kUnknownRoute对应Flutter页面。即执行FusionRouteDelegate的pushFlutterRoute
  
  
  • native模式: 将指定路由对应的Native页面入栈，即执行FusionRouteDelegate的pushNativeRoute
  
  
  • adaption模式: 自适应模式，默认类型。首先判断该路由是否是Flutter路由，如果不是则进入native模式，如果是再判断当前是否是页面是否是Flutter容器，如果是则进入flutter模式，如果不是则进入flutterWithContainer模式
  
  
  
  


• pop：在当前Flutter容器中将栈顶路由出栈，Navigator.pop 与之等同


• maybePop：在当前Flutter容器中将栈顶路由出栈，可被WillPopScope拦截


• replace：在当前Flutter容器中将栈顶路由替换为对应路由，Navigator.pushReplacementNamed 与之等同


• remove：在当前Flutter容器中移除对应路由

路由跳转与关闭等操作既可使用FusionNavigator的 API，也可使用Navigator中与之对应的API（仅上述提到的部分）

4、Flutter Plugin 注册

在 Android 和 iOS 平台上框架内部会自动注册插件，无须手动调用 GeneratedPluginRegistrant.registerWith 进行注册，但 HarmonyOS 必须手动调用该方法。

5、自定义 Channel

如果需要 Native 与 Flutter 进行通信，则需要自行创建 Channel，创建 Channel 方式如下（以 MethodChannel 为例）：

Android 侧

①、与容器无关的方法

在 Application 中进行注册

val channel = Fusion.defaultEngine?.dartExecutor?.binaryMessenger?.let {

    MethodChannel(

        it,

        "custom_channel"

    )

}

channel?.setMethodCallHandler { call, result -> 

}

②、与容器相关的方法

在自实现的 FusionActivity、FusionFragmentActivity、FusionFragment 上实现 FusionMessengerHandler 接口，在 configureFlutterChannel 中创建 Channel，在 releaseFlutterChannel 释放 Channel

class CustomActivity : FusionActivity(), FusionMessengerHandler {

  

    override fun configureFlutterChannel(binaryMessenger: BinaryMessenger) {

        val channel = MethodChannel(binaryMessenger, "custom_channel")

        channel.setMethodCallHandler { call, result -> 

            

        }

    }

  

    override fun releaseFlutterChannel() {

        channel?.setMethodCallHandler(null)

        channel = null

    }

}

iOS 侧

①、与容器无关的方法

在 AppDelegate 中进行注册

var channel: FlutterMethodChannel? = nil

if let binaryMessenger = Fusion.instance.defaultEngine?.binaryMessenger {

    channel = FlutterMethodChannel(name: "custom_channel", binaryMessenger: binaryMessenger)

}

channel?.setMethodCallHandler { (call: FlutterMethodCall, result: @escaping FlutterResult) in

}

②、与容器相关的方法

在自实现的 FusionViewController 上实现 FusionMessengerHandler 协议，在协议方法中创建 Channel

class CustomViewController : FusionViewController, FusionMessengerHandler {

    func configureFlutterChannel(binaryMessenger: FlutterBinaryMessenger) {

        channel = FlutterMethodChannel(name: "custom_channel", binaryMessenger: binaryMessenger)

        channel?.setMethodCallHandler { (call: FlutterMethodCall, result: @escaping FlutterResult) in

            

        }

    }

    

    func releaseFlutterChannel() {

        channel?.setMethodCallHandler(nil)

        channel = nil

    }

}

HarmonyOS 侧

①、与容器无关的方法

在 UIAbility 中进行注册

const binaryMessenger = Fusion.instance.defaultEngine?.dartExecutor.getBinaryMessenger()

const channel = new MethodChannel(binaryMessenger!, 'custom_channel')

channel.setMethodCallHandler({

  onMethodCall(call: MethodCall, result: MethodResult): void {

    

  }

})

②、与容器相关的方法

在自实现的 FusionEntry 上实现 FusionMessengerHandler 接口，在 configureFlutterChannel 中创建 Channel，在 releaseFlutterChannel 释放 Channel

export default class CustomFusionEntry extends FusionEntry implements FusionMessengerHandler, MethodCallHandler {

  private channel: MethodChannel | null = null



  configureFlutterChannel(binaryMessenger: BinaryMessenger): void {

    this.channel = new MethodChannel(binaryMessenger, 'custom_channel')

    this.channel.setMethodCallHandler(this)

  }



  onMethodCall(call: MethodCall, result: MethodResult): void {

    result.success(`Custom Channel：${this}_${call.method}`)

  }



  releaseFlutterChannel(): void {

    this.channel?.setMethodCallHandler(null)

    this.channel = null

  }

}