一、背景

工信部最近发布了新的入网要求，明确了app进网检测要求的具体变化，主要涉及到一些app权限调用，个人信息保护，软件升级以及敏感行为。为了不影响app的正常运行，依据工信部的文件进行相关整改，下文将从5个方向来阐述具体的解决思路。

二、整改

2.1 个人信息保护

2.1.1 基本模式（无权限、无个人信息获取模式）

这次整改涉及到最大的一个点就是基本模式，基本模式指的是在用户选择隐私协议弹窗时，不能点击“不同意”即退出应用，而是需要给用户提供一个除联网功能外，无任何权限，无任何个人信息获取的模式且用户能正常使用。

这个说法有点抽象，我们来看下友商已经做好的案例。

腾讯视频

从腾讯视频的策略来看，用户第一次使用app，依旧会弹出一个“用户隐私协议”弹窗供用户选择，但是和以往不同的是，“不同意”按钮替换为了“不同意并进入基本功能模式”，用户点击“不同意并进入基本功能模式”则进入到一个简洁版的页面，只提供一些基本功能，当用户点击“进入全功能模式”，则再次弹出隐私协议弹窗。当杀死进程后，再次进入则直接进入基本模式。

网易云音乐

网易云音乐和腾讯视频的产品策略略有不同，在用户在一级授权弹窗点击“不同意”，会跳转至二级授权弹窗，当用户在二级弹窗上点击“不同意，进入基本功能模式”，才会进入基本功能页面，在此页面上点击“进入完整功能模式”后就又回到了二级授权页。当用户杀死进程，重新进入app时，还是会回到一级授权页。

网易云音乐比腾讯视频多了一个弹窗，也只是为了提升用户进入完整模式的概率，并不涉及到新规。

另外，B站、酷狗音乐等都已经接入了基本模式，有兴趣的伙伴可以自行下载体验。

2.1.2 隐私政策内容

如果app存在读取并传送用户个人信息的行为，需要检查其是否具备用户个人信息收集、使用规则，并明确告知读取和传送个人信息的目的、方式和范围。

判断权限是否有读取、修改、传送行为，如果有，需要在隐私协议中明文告知。

举个例子，app有获取手机号码并且保存在服务器，需要在协议中明确声明：读取并传送用户手机号码。

2.2 app权限调用

2.2.1 应用内权限调用

1. 获取定位信息和生物特征识别信息

在获取定位信息以及生物特征识别信息时需要在调用权限前，单独向用户明示调用权限的目的，不能用系统权限弹窗替代。

如上图，申请位置权限，需要在申请之前，弹出弹窗供用户选择，用户同意调用后才可以申请位置权限。

1. 其他权限

其他权限如上面隐私政策一样，需要在调用时，声明是读取、修改、还是传送行为，如下图

2.3 应用软件升级

2.3.1 更新

应用软件或插件更新应在用户授权的情况下进行，不能直接更新，另外要明确告知用户此行为包含下载和安装。

简单来说，就是在app进行更新操作时，需要用弹窗告知用户，是否更新应用，更新的确认权交给用户，并且弹窗上需要声明此次更新有下载和安装两个操作。如下图

2.4 应用签名

需要保

在Flutter中实现IOC（Inversion of Control，控制反转）与AOP（Aspect-Oriented Programming，面向切面编程）之前，让我们先来了解一下这两个概念。

IOC（控制反转） 是一种设计原则，它将应用程序的控制权从应用程序本身转移到外部框架或容器。传统上，应用程序会自己创建和管理对象之间的依赖关系。而在IOC中，对象的创建和管理被委托给一个专门的框架或容器。框架负责创建和注入对象，以实现松耦合和可扩展的架构。通过IOC，我们可以将应用程序的控制流程反转，从而实现更灵活、可测试和可维护的代码。

AOP（面向切面编程） 是一种编程范式，用于将横切关注点（如日志记录、事务管理、性能监控等）从应用程序的主要业务逻辑中分离出来。AOP通过在特定的切入点上织入额外的代码（称为切面），从而实现对这些关注点的统一管理。这种分离和集中的方式使得我们可以在不修改核心业务逻辑的情况下添加、移除或修改横切关注点的行为。

对于Java开发者来说，IOC和AOP可能已经很熟悉了，因为在Java开发中有许多成熟的框架，如Spring，提供了强大的IOC和AOP支持。

在Flutter中，尽管没有专门的IOC和AOP框架，但我们可以利用语言本身和一些设计模式来实现类似的功能。

接下来，我们可以探讨在Flutter中如何实现IOC和AOP的一些常见模式和技术。无论是依赖注入还是横切关注点的管理，我们可以使用一些设计模式和第三方库来实现类似的效果，以满足我们的开发需求

1. 控制反转（IOC）：

依赖注入（Dependency Injection）：依赖注入是一种将依赖关系从组件中解耦的方式，通过将依赖项注入到组件中，实现控制反转的效果。在Flutter中，你可以使用get_it库来实现依赖注入。下面是一个示例：

import 'package:flutter/material.dart';

import 'package:get_it/get_it.dart';



class UserService {

  String getUser() => 'John Doe';

}



class GreetingService {

  final UserService userService;



  GreetingService(this.userService);



  String greet() {

    final user = userService.getUser();

    return 'Hello, $user!';

  }

}



void main() {

  // 注册依赖关系

  GetIt.instance.registerSingleton<UserService>(UserService());

  GetIt.instance.registerSingleton<GreetingService>(

    GreetingService(GetIt.instance<UserService>()),

  );



  runApp(MyApp());

}



class MyApp extends StatelessWidget {

  @override

  Widget build(BuildContext context) {

    final greetingService = GetIt.instance<GreetingService>();



    return MaterialApp(

      title: 'IOC Demo',

      home: Scaffold(

        appBar: AppBar(title: Text('IOC Demo')),

        body: Center(child: Text(greetingService.greet())),

      ),

    );

  }

}

在上述示例中，我们定义了UserService和GreetingService两个类。GreetingService依赖于UserService，我们通过依赖注入的方式将UserService注入到GreetingService中，并通过get_it库进行管理。

2. 面向切面编程（AOP）：

在Flutter中，可以使用Dart语言提供的一些特性，如Mixin和装饰器（Decorator）来实现AOP。

Mixin：Mixin是一种通过将一组方法和属性混入到类中来实现代码复用的方式。下面是一个示例：

import 'package:flutter/material.dart';



mixin LogMixin<T extends StatefulWidget> on State<T> {

  void log(String message) {

    print('[LOG]: $message');

  }

}



class LogButton extends StatefulWidget {

  final VoidCallback onPressed;



  const LogButton({required this.onPressed});



  @override

  _LogButtonState createState() => _LogButtonState();

}



class _LogButtonState extends State<LogButton> with LogMixin {

  @override

  Widget build(BuildContext context) {

    return ElevatedButton(

      onPressed: () {

        log('Button clicked');

        widget.onPressed();

      },

      child: Text('Click Me'),

    );

  }

}



void main() {

  runApp(MyApp());

}



class MyApp extends StatelessWidget {

  @override

  Widget build(BuildContext context) {

    return MaterialApp(

      title: 'AOP Demo',

      home: Scaffold(

        appBar: AppBar(title: Text('AOP Demo')),

        body: Center(child: LogButton(onPressed: () => print('Button pressed'))),

      ),

    );

  }

}

在上面的示例中，我们定义了一个LogMixin，其中包含了一个log方法，用于记录日志。然后我们在_LogButtonState中使用with LogMixin将日志记录功能混入到_LogButtonState中。每次按钮被点击时，会先打印日志，然后调用传入的回调函数。

装饰器：装饰器是一种将额外行为添加到方法或类上的方式。下面是一个示例：

void logDecorator(Function function) {

  print('[LOG]: Method called');

  function();

}



@logDecorator

void greet() {

  print('Hello, world!');

}



void main() {

  greet();

}

在Flutter中，虽然没有专门的IOC（控制反转）和AOP（面向切面编程）框架，但我们可以利用一些设计模式和技术来实现类似的效果。

对于IOC，我们可以使用依赖注入（Dependency Injection）的方式实现。依赖注入通过将依赖项注入到组件中，实现了控制反转的效果。在Flutter中，可以借助第三方库如get_it或kiwi来管理依赖关系，将对象的创建和管理交由依赖注入框架处理。

在AOP方面，我们可以使用Dart语言提供的Mixin和装饰器（Decorator）来实现类似的功能。Mixin是一种通过将一组方法和属性混入到类中的方式实现代码复用，而装饰器则可以在不修改被装饰对象的情况下，添加额外的行为或改变对象的行为。

通过使用Mixin和装饰器，我们可以在Flutter中实现横切关注点的管理，例如日志记录、性能监测和权限控制等。通过将装饰器应用于关键的方法或类，我们可以在应用程序中注入额外的功能，而无需直接修改原始代码。

需要注意的是，以上仅为一些示例，具体实现方式可能因项目需求和个人偏好而有所不同。在Flutter中，我们可以灵活运用设计模式、第三方库和语言特性，以实现IOC和AOP的效果，从而提升代码的可维护性、可扩展性和重用性。

总结而言，尽管Flutter没有专门的IOC和AOP框架，但我们可以借助依赖注入和装饰器等技术，结合常见的设计模式，构建灵活、可测试和可维护的应用程序。这些技术和模式为开发者提供了良好的开发体验和代码结构。

希望对您有所帮助谢谢!!

1、 前言

  当我们在应用程序中启动一个线程的时候，也是有可能发生OOM错误的。当我们看到以下log的时候，就说明系统分配线程栈失败了。

java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Out of memory

这种情况可能是两种原因导致的。

• 第一个就是系统的内存不足的时候，我们去启动一个线程。


• 第二种就是进程内运行的线程总数超过了系统的限制。

  如果是内存不足的情况，需按照堆内存治理的方式来进行解决，检查应用内存泄漏问题并优化，此情况不作为本次讨论的重点。

  本次主要讨论进程内运行的线程总数超过了系统的限制所导致的情况。出现此情况时，我们就需要通过控制并发的线程总数来解决这个问题。

  想要控制并发的线程数。最直接的一种方式就是利用回收的思路，也就是让我们的线程通过串行的方式来执行；一个线程执行完毕之后，再启动下一个线程。这样就能够让并发的线程总数达到一个可控的状态。

  另外一种方式就是通过复用来解决，让同一个线程的实例可以被反复的利用，只创建较少的线程实例，就能完成大量的异步操作。

2、异步任务的方式对比

  对比一下，在安卓平台我们比较常用的开启异步任务的方式中，有哪些是更加有利于我们进行线程总数的控制的。

  从最简单的直接创建Thread的实例的方式来说起。在Java中这种方式虽然是最简单的去开启一个线程的方式，但是在实际开发中，一旦我们通过这种方式去自己创建 Thread 类的实例，并且调用 start 来开启一个线程的话，所开启的线程会非常的难以调度和管理。这种线程也就是我们平时所说的野线程。所以我们最好不要直接的创建thread类的实例。

2.2 HandlerThread

public class HandlerThread extends Thread { }

  HandlerThread是Thread类的子类，对Thread做了很多便利的封装。它有自己的Loop，它能够进行消息循环，所以就能够做到通过Handler执行异步任务，也能够做到在不同的线程之间，通过Handler进行现成的通讯。我们可以利用Handler的post操作，让我们在一个线程内部串行的执行多个异步任务。从内存的角度来说，也就相当于对线程进行了复用。

2.3 AsyncTask

  AsyncTask是一个相对更加轻量级，专门为了完成执行异步任务，然后返回UI线程更新UI的操作而设计的。对于我们来说，AsyncTask更像是一个任务的概念，而不是一个线程的概念。我们不需要把它当做一个线程去理解。 AsyncTask的本质，其实也是对线程和Handler的封装。

• Android 1.6前，串行执行，原理：一个子线程进行任务的串行执行；


• Android 1.6到2.3，并行执行，原理：一个线程数为5的线程池并行执行，但如果前五个任务执行时间过长，会堵塞后续任务执行，故不适合大量任务并发执行；


• Android 3.0后，串行执行，原理：全局线程池进行串行处理任务；

到了Android 3.0以上版本，默认是串行执行的，但是可以结合线程值来实现有限制的并行。也可以达到一个限制线程总数的目的。

2.4 线程池

  Java语言本身也为我们提供了线程池。线程池的作用就是可以管理并发数，并且能够持续的去复用线程。如果在一个应用内部的全部异步操作，全部都采用线程池的方式来开启的话，那么我们就能够管理我们所有的异步任务了。这样一来，能够大大的降低线程治理的成本。

2.5 Kotlin协程

  在Kotlin中还引入了协程的概念。协程给传统的Java的异步编程带来最大的改变，就是能够让我们更加优雅的去实现异步任务。我们前面所说的这几种异步任务的执行方式，都需要我们额外的去写大量的样本代码。而Kotlin协程就能够做到让我们用写同步代码的方式去写异步代码。

  在语法的层面上，协程的另一个优势就是性能方面。协程能够帮助我们用更少的线程去执行更多的并发任务。同样也降低了我们治理内存的成本。从治理内存的角度来说，用线程池接管线程或者采用协程都是很好的方式。

Vue3 有没有一款好用的开发原生的工具

1.uniapp 我个人认为uniapp 适合开发小程序之类的，用这个去开发原生应用会存在一些问题

• 
  

  性能限制：由于 Uniapp 是通过中间层实现跨平台，应用在访问底层功能时可能存在性能损失。与原生开发相比，Uniapp 在处理大规模数据、复杂动画和高性能要求的应用场景下可能表现较差。

  
  


• 
  

  平台限制：不同平台有着各自的设计规范和特性，Uniapp 在跨平台时可能受到一些平台限制。有些平台特有的功能或界面设计可能无法完全实现，需要使用特定平台的原生开发方式来解决。

  
  


• 
  

  生态系统成熟度： 相比于原生开发，Uniapp 的生态系统相对较新，支持和资源相对有限。在遇到问题时，可能难以找到完善的解决方案，开发者可能需要花费更多的时间和精力来解决问题。

  
  


• 
  

  用户体验差异： 由于不同平台的设计规范和用户习惯不同，使用 Uniapp 开发的应用在不同平台上的用户体验可能存在差异。开发者需要针对每个平台进行特定的适配和调优，以提供更好的用户体验。

  
  


• 
  

  功能支持限制： Uniapp 尽可能提供了跨平台的组件和 API，但某些特定平台的功能和接口可能无法完全支持。在需要使用特定平台功能的情况下，可能需要使用原生开发或自定义插件来解决。

  
  


• 
  

  uni 文档 uniapp.dcloud.net.cn/

  
  

2.react 拥有react native 开发原生应用 Vue无法使用 http://www.reactnative.cn/

3.Cordova cordova.apache.org/ 支持原生html js css 打包成 ios android exe dmg

4.ionic 我发现这个框架支持Vue3 angular react ts 构建Android iOS 桌面程序 这不正合我意 ionicframework.com/docs

前置条件

1.安装 java 环境 和 安卓编辑器sdk

• java JKD 下载http://www.oracle.com/java/techno…


• 安卓编辑器下载 developer.android.google.cn/studio/


• 或者私信要安装包

安装完成检查环境变量

检查安卓编辑器的sdk 如果没安装就装一下

ionic

npm install -g @ionic/cli

初始化Vue3项目

安装完成后会有ionic 命令

ionic start [name] [template] [options]

#            名称      模板    类型为vue项目

ionic start app tabs --type vue

npm install #安装依赖

npm run dev 启动测试

启动完成后自带一个tabs demo

运行至android 编辑器 调试

npm run build

ionic capacitor copy android

注意检查

如果没有这个文件 删除android目录 重新执行下面命令

ionic capacitor copy android

预览

ionic capacitor open android

他会帮你打开安卓编辑器

如果报错说丢失sdk 注意检查sdk目录

.

等待编译

点击上面绿色箭头运行

热更新

如果要热更新预览App 需要一个安卓设备

一直点击你的版本号就可以开启开发者模式

开启usb调试 连接电脑

ionic capacitor run android -l --external

选择刚才的安卓设备

成功热更新

前言

总结一些日常开发中非常有用的 gradle 脚本、自定义功能实现。

实现

以下实现基于 AGP 8.0.2 版本 ,AGP 的 API 隔三岔五就会迎来一波破坏性的变更，导致脚本和插件无法使用，因此这里需要关注一下版本。

输出打包后 apk 文件路径及 apk 大小。

Android Studio 最新版本 Run 之后，每次输出的 apk 并没有在这 app/build/outputs 文件夹下（不知道 Android 官方是出于什么考虑要更改这个路径），而是移动到了 build\intermediates\apk\{flavor}\debug\ 目录下。为了方便后续快速找到每次运行完成的 apk ，可以在每次打包后输出 apk 文件路径及大小，从而可以关注一下日常开发过程中自己
的 apk 体积大概是一个什么样的范围。

static def getFileHumanSize(length) {

    def oneMB = 1024f * 1024f

    def size = String.valueOf((length / oneMB))

    def value = new BigDecimal(size)

    return value.setScale(2, BigDecimal.ROUND_HALF_UP)

}

/**

 * 打包完成后输出 apk 大小*/

android {

    applicationVariants.all { variant ->

        variant.assembleProvider.configure() {

            it.doLast {

                variant.outputs.forEach {

                    logger.error("apk fileName ==> ${it.outputFile.name}")

                    logger.error("apk filePath ==> ${it.outputFile}")

                    logger.error("apk fileSize ==> ${it.outputFile.length()} , ${getFileHumanSize(it.outputFile.length())} MB")

                }

            }

        }

    }

}

apk fileName ==> app-huawei-global-debug.apk

apk filePath ==> D:\workspace\MinApp\app\build\intermediates\apk\huaweiGlobal\debug\app-huawei-global-debug.apk

apk fileSize ==> 11987818 , 11.43 MB

可以看到 apk 的路径在 build/intermediates 目录下。当然，我们可以通过下面的方法修改这个路径，定义成我们习惯的路径。

gradle 自定义功能的模块化

日常开发中，会有很多关于 build.gradle 的修改和更新。日积月累，build.gradle 的内容越来越多，代码几乎要爆炸了。其实，可以用模块化的思路将每一个小功能单独抽取出来，这样不仅可以减少 build.gradle 的规模，同时小功能可以更加容易的复用。

比如上面定义的输出打包后 apk 文件路径及 apk 大小的功能，我们就可以把他定义在 report_apk_size_after_package.gradle 这样一个文件中，然后在要使用的 build.gradle 中导入即可。

比如我们要在 app module 中使用这个功能，那么就可以直接在其 build.gradle 文件中按照相对路径引入即可。

apply from: file("../custom-gradle/report_apk_size_after_package.gradle") // 打包完成后输出 apk 大小

修改 release 包的输出路径及文件名

输出 apk 后改名的需求，应该已经很普遍了。在最终输出的 apk 文件中，我们可以追加一些和代码相关的信息，方便通过 apk 文件名迅速确定一些内容。

def getCommit() {

    def stdout = new ByteArrayOutputStream()

    exec {

        commandLine "git"

        args "rev-parse", "--short", "HEAD"

        standardOutput = stdout

    }

    return stdout.toString().trim()

}



def getBranch() {

    def stdout = new ByteArrayOutputStream()

    exec {

        commandLine "git"

        args "rev-parse", "--abbrev-ref", "HEAD"

        standardOutput = stdout

    }

    return stdout.toString().trim()

}



def gitLastCommitAuthorName() {

    return "git log -1 --pretty=format:'%an'".execute(null, rootDir).text.trim().replaceAll("\'", "")

}



def gitLastCommitAuthorEmail() {

    return "git log -1 --pretty=format:'%ae'".execute(null, rootDir).text.trim().replaceAll("\'", "")

}





android {

    def i = 0

    applicationVariants.all { variant ->       

        if (variant.assembleProvider.name.contains("Debug")) {

            // 只对 release 包生效

            return

        }



        // 打包完成后复制到的目录

        def outputFileDir = "${rootDir.absolutePath}/build/${variant.buildType.name}/${variant.versionName}"

        //确定输出文件名

        def today = new Date()

        def path = ((project.name != "app") ? project.name : rootProject.name.replace(" ", "")) + "_" + variant.flavorName + "_" + variant.buildType.name + "_" + variant.versionName + "_" + today.format('yyyy_MM_dd_HH_mm') + "_" + getBranch() + "_" + getCommit() + "_" + gitLastCommitAuthorName() + ".apk"

        println("path is $path")

        variant.outputs.forEach {

            it.outputFileName = path

        }

        // 打包完成后做的一些事,复制apk到指定文件夹

        variant.assembleProvider.configure() {

            it.doLast {

                File out = new File(outputFileDir)

                copy {

                    variant.outputs.forEach { file ->

                        copy {

                            from file.outputFile

                            into out

                        }

                    }

                }

            }

        }

    }

}

打 release 包后的日志

let me do something after assembleHuaweiGlobalRelease

apk fileName ==> MiniApp_huaweiGlobal_release_1.0.0_2306292226_2023_06_29_22_26_master_b0c6937_rookie.apk

apk filePath ==> D:\workspace\MinApp\app\build\outputs\apk\huaweiGlobal\release\MiniApp_huaweiGlobal_release_1.0.0_2306292226_2023_06_29_22_26_master_b0c6937_rookie.apk

apk fileSize ==> 4959230 , 4.73 MB

通过上面的日志，可以看到 MiniApp_huaweiGlobal_release_1.0.0_2306292226_2023_06_29_22_26_master_b0c6937_rookie.apk 包含了 ProjectName、flavor、debug/release、打包时间、分支、commitId 即最后一个 commitor 邮箱这些信息。通过这样的信息，可以更加方便快速的定位问题和解决问题。

妙用 flavor 实现不同的功能

使用 flavor 可以定制代码的不同功能及组合。不用把所有内容一锅乱炖似的放在一起搞。比如 MiniApp 随着演示代码的增多，已经逐渐丧失了 Mini 的定位，Apk 大小已经来到了 22 MB之多。究其原因，就是把所有代码验证和功能都放在一起导致的，音视频、compose、C++ 代码全都混在一起。部分功能不常用，但是每次为了验证一部分小功能，却要连带编译这些所有功能，同时打出的 apk 包体积也变大了，从编译到安装，无形中浪费了很多时间。

因此，可以通过 flavor 将一些不常用的功能，定义到不同的 flavor 中，真正需要的时候，编译相应 flavor 的包即可。

首先我们可以从 type 维度定义两个 flavor

    flavorDimensions "channel", "type"

    productFlavors {

        xiaomi {

            dimension "channel"

        }

        oppo {

            dimension "channel"

        }

        huawei {

            dimension "channel"

        }



        global {

            dimension "type"

        }

        local {

            dimension "type"

        }

    }

在 type 维度，我们可以认为 global 是功能完整的 flavor，而 local 是部分功能缺失的 flavor 。那么具体缺失哪些功能呢？这就要从实际情况出发了，比如产品定义，代码架构及模块组合之类的。回到 Mini App 中，我们使用不同 flavor 的目标就是通过减少非常用功能模块，获得一个体积相对较小的 apk. 因此，可以做如下配置。

    if (source_code.toBoolean()) {

        globalImplementation project(path: ':thirdlib')

    } else {

        globalImplementation 'com.engineer.third:thirdlib:1.0.0'

    }

    globalImplementation project(path: ':compose')

    globalImplementation 'com.github.CarGuo.GSYVideoPlayer:GSYVideoPlayer:v8.1.8-release-jitpack'

如上我们只在 global 这个 flavor 依赖 thirdlib, compose, GSYVideoPlayer 这些组件。这样 local flavor 就不会引入这些组件，那么就会带来一个问题，local flavor 编译的时候没有这些组件的类，会出现找不到类的情况。

对于这种情况，我们可以在项目 src 和 main 同级的目录下，创建 local 文件夹，然后在其内部按照具体 Class 文件的路径创建相应的类即可。

package com.engineer.compose.ui



import com.engineer.BasePlaceHolderActivity



/**

 * Created on 2022/7/31.

 * @author rookie

 */

class MainComposeActivity : BasePlaceHolderActivity()

package com.engineer.third



import com.engineer.BasePlaceHolderActivity



/**

 * Created on 2022/7/31.

 * @author rookie

 */

class CppActivity : BasePlaceHolderActivity()

package com.engineer



import android.os.Bundle

import androidx.appcompat.app.AppCompatActivity

import com.engineer.android.mini.ext.toast



/**

 * Created on 2022/8/1.

 * @author rookie

 */

open class BasePlaceHolderActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        "please use global flavor ".toast()

        finish()

    }

}

这里的思路其实很简单，类似于 leanCanary ，就是在不需要这个功能的 flavor 提供空实现，保证编译可以正常通过即可。缺什么类，建按照类的完整路径创建相应的 Class 文件，这样既保证了编译可以通过，同时在不需要次功能的 flavor 又减少无冗余的代码。

flavor 扩展

其实顺着上面的思路，基于不同 flavor 我们可以做更多的事情。基于 Java 虚拟机的类加载机制限制，相同的类只能有一个，因此我们无法做的事情是，通过 flavor 创建同名的类，去覆盖或重写其他 flavor 的逻辑，这种在编译阶段（其实是在创建同名类的阶段）就会报错。

但是，有些功能是可以被覆盖和定制的。比如包名、App 的名称、icon 之类。这些配置可以通过 AndroidManifest.xml/gradle 进行配置。可以在 local 目录下创建这个 flavor 特有的一些资源文件，这样就可以实现基于 flavor 的产品功能定制了。

比如最简单的修改 applicationId

        global {

            dimension "type"

        }

        local {

            dimension "type"

            applicationId "com.engineer.android.mini.x"

        }

这样，local 和 global 就有了各自不同的 applicationId, 这两种不同 flavor 的包就可以安装在同一台设备了。当然，现在这两个包的 label 和 icon 都是一样的，完全看不出区别。这里就可以利用 flavor 各自的文件夹，来定制各类资源和命名了。

flavor 过滤

不同维度的 flavor 会导致最终的 variant 变多。比如定义 product、channel、type 这些几个 dimension 的之后，后续新增的 flavor 会以乘积的形式增长，但是有些 flavor 又是我们不需要的，这个时候我们就可以过滤掉某些不需要的 flavor 。

比如以上面定义的 channel,type 这两个维度为例，在这两个维度下分别又扩展了 xiaomi/opop/huawei,global/local 这些 flavor 。按照规则会有 2x3x2=12 种 flavor，但实际情况可能不需要这么多，为了减少编译的压力，提升代码的可维护性，我们可以对 flavor 进行过滤。

    variantFilter { variant ->

        println "variant is ${variant.flavors*.name}"

        def dimens = variant.flavors*.name

        def type = dimens[1]

        def channel = dimens[0]

        switch (type) {

            case "global":

                if (channel == "xiaomi") {

                    setIgnore(true)

                }

                break

            case "local":

                if (channel == "oppo") {

                    setIgnore(true)

                }

                break

        }

    }

这样我们就成功的过滤掉了 xiaomiGlobal 和 oppoLocal 的 flavor ，一下子就去掉了 4 个 flavor 。

基于现有 task 定制任务

再回顾一下上面的 修改 release 包的输出路径及文件名 的代码实现，我们是在打包完成之后进行了 apk 文件的重命名。

        // 打包完成后做的一些事,复制apk到指定文件夹

        variant.assembleProvider.configure() {

            it.doLast {

                File out = new File(outputFileDir)

                copy {

                    variant.outputs.forEach { file ->

                        copy {

                            from file.outputFile

                            into out

                        }

                    }

                }

            }

        }

这里的 doLast 就是说，无论是否需要，每次都会在 assemble 这个 task 完成之后做一件事。这样在某些情况下显得非常的不灵活，尤其是当 doLast 闭包中要做的事情非常繁重的时候。这里的 copy 操作显然是比较轻量的，但是换做是其他操作，比如 apk 安全加固等操作，并不是每次必然需要的操作。这种情况下，就需要我们换一种方式去实现相应的逻辑了。

我们就以加固为例，一般情况下，我们需要对各个版本的 release 包进行加固。因此，我们可以基于现有的 assembleXXXRelease 这个 task 展开。

android {

    applicationVariants.all { variant ->

        if (variant.assemble.name.contains("Debug")) {

            // 只对 release 包生效

            return

        }



        def taskPrefix = "jiagu"

        def groupName = "jiagu"

        def assembleTask = variant.assembleProvider.name

        def taskName = assembleTask.replace("assemble", taskPrefix)

        tasks.create(taskName) {

            it.group groupName

            it.dependsOn assembleTask

            variant.assembleProvider.configure() {

                it.doLast {

                    logger.error("let me do something after $assembleTask")

                }

            }

        }

    }

}

添加上面的代码后，再执行一下 gradle sync ，我们就可以看到新添加的 jiagu 这个 group 和其中的 task 了。

这里使用创建 task 的一种方式，使用 create 和 dependsOn ，动态创建 task，并指定其依赖的 task 。

这样当我们执行 ./gradlew jiaguHuaweiLocalRelease 时就可以看到结果了。

> Task :app:assembleHuaweiLocalRelease

let me do something after assembleHuaweiLocalRelease



> Task :app:jiaguHuaweiLocalRelease



BUILD SUCCESSFUL in 56s

82 actionable tasks: 12 executed, 70 up-to-date

可以看到我们自定义的 task 已经生效了，会在 assembleXXXRelease 这个 task 完成之后执行。

关于 gradle 的使用，可以说是孰能生巧，只要逐渐熟悉了 groovy 的语法和 Java 语法之间的差异，那么就可以逐渐摸索出更多有意思的用法了。

本文源码可以参考 Github MiniApp

小结

可以看到基于 gradle 构建流程，我们仅仅通过编写一些脚本，可以做的事情还是很多的。但是由于 groovy 语法过于灵活，不像 Java 那样有语法提示，因此尝试一些新的语法时难免不知所措。面对这种情况，去看他的源码就好。通过源码，我们就可以知道某个类有哪

背景

为了提高App的冷启动耗时，除了在常规的业务侧进行耗时代码优化之外，为了进一步缩短启动耗时，需要在纯技术测做一些优化探索，本期我们从类预加载、Retrofit 、ARouter方面进行了进一步的优化。从测试数据上来看，这些优化手段的收益有限，可能在中端机上加起来也不超过50ms的收益，但为了冷启动场景的极致优化，给用户带来更好的体验，任何有收益的优化手段都是值得尝试的。

类预加载

一个类的完整加载流程至少包括 加载、链接、初始化，而类的加载在一个进程中只会触发一次，因此对于冷启动场景，我们可以异步加载原本在启动阶段会在主线程触发类加载过程的类，这样当原流程在主线程访问到该类时就不会触发类加载流程。

Hook ClassLoader 实现

在Android系统中，类的加载都是通过PathClassLoader 实现的，基于类加载的父类委托机制，我们可以通过Hook PathClassLoader 修改其默认的parent 来实现。

首先我们创建一个MonitorClassLoader 继承自PathClassLoader,并在其内部记录类加载耗时

class MonitorClassLoader(

    dexPath: String,

    parent: ClassLoader, private val onlyMainThread: Boolean = false,

) : PathClassLoader(dexPath, parent) {



    val TAG = "MonitorClassLoader"



    override fun loadClass(name: String?, resolve: Boolean): Class<*> {

    val begin = SystemClock.elapsedRealtimeNanos()

    if (onlyMainThread && Looper.getMainLooper().thread!=Thread.currentThread()){

        return super.loadClass(name, resolve)

    }

    val clazz = super.loadClass(name, resolve)

    val end = SystemClock.elapsedRealtimeNanos()

    val cost = end - begin

    if (cost > 1000_000){

        Log.e(TAG, "加载 ${clazz} 耗时 ${(end - begin) / 1000} 微秒 ,线程ID ${Thread.currentThread().id}")

    } else {

        Log.d(TAG, "加载 ${clazz} 耗时 ${(end - begin) / 1000} 微秒 ,线程ID ${Thread.currentThread().id}")

    }

    return  clazz;



}

}

之后，我们可以在Application attach阶段 反射替换 application实例的classLoader 对应的parent指向。

核心代码如下：

    companion object {

        @JvmStatic

        fun hook(application: Application, onlyMainThread: Boolean = false) {

            val pathClassLoader = application.classLoader

            try {

                val monitorClassLoader = MonitorClassLoader("", pathClassLoader.parent, onlyMainThread)

                val pathListField = BaseDexClassLoader::class.java.getDeclaredField("pathList")

                pathListField.isAccessible = true

                val pathList = pathListField.get(pathClassLoader)

                pathListField.set(monitorClassLoader, pathList)



                val parentField = ClassLoader::class.java.getDeclaredField("parent")

                parentField.isAccessible = true

                parentField.set(pathClassLoader, monitorClassLoader)

            } catch (throwable: Throwable) {

                Log.e("hook", throwable.stackTraceToString())

            }

        }

    }

主要逻辑为

• 反射获取原始 pathClassLoader 的 pathList


• 创建MonitorClassLoader，并反射设置 正确的 pathList


• 反射替换 原始pathClassLoader的 parent指向 MonitorClassLoader实例

这样，我们就获取启动阶段的加载类了

基于JVMTI 实现

除了通过 Hook ClassLoader的方案实现，我们也可以通过JVMTI 来实现类加载监控。关于JVMTI 可参考之前的文章 juejin.cn/post/694278…。

通过注册ClassPrepare Callback, 可以在每个类Prepare阶段触发回调。

当然这种方案，相比 Hook ClassLoader 还是要繁琐很多，不过基于JVMTI 还可以做很多其他更强大的事。

类预加载实现

目前应用通常都是多模块的，因此我们可以设计一个抽象接口，不同的业务模块可以继承该抽象接口，定义不同业务模块需要进行预加载的类。

/**

 * 资源预加载接口

 */

public interface PreloadDemander {

    /**

     * 配置所有需要预加载的类

     * @return

     */

    Class[] getPreloadClasses();

}

之后在启动阶段收集所有的 Demander实例，并触发预加载

/**

 * 类预加载执行器

 */

object ClassPreloadExecutor {





    private val demanders = mutableListOf<PreloadDemander>()



    fun addDemander(classPreloadDemander: PreloadDemander) {

        demanders.add(classPreloadDemander)

    }



    /**

     * this method shouldn't run on main thread

     */

    @WorkerThread fun doPreload() {

        for (demander in localDemanders) {

            val classes = demander.preloadClasses

            classes.forEach {

                val classLoader = ClassPreloadExecutor::class.java.classLoader

                Class.forName(it.name, true, classLoader)

    			}

			}

    }

    

}

收益

第一个版本配置了大概90个类，在终端机型测试数据显示 这些类的加载需要消耗30ms左右的cpu时间，不同类加载的消耗时间差异主要来自于类的复杂度 比如继承体系、字段属性数量等， 以及类初始化阶段的耗时，比如静态成员变量的立即初始化、静态代码块的执行等。

方案优化思考

我们目前的方案 配置的具体类列表来源于手动配置，这种方案的弊端在于，类的列表需要开发维护，在版本快速迭代变更的情况下 维护成本较大， 并且对于一些大型App，存在着非常多的AB实验条件，这也可能导致不同的用户在类加载上是会有区别的。

在前面的小节中，我们介绍了使用自定义的 ClassLoader可以手动收集 启动阶段主线程的类列表，那么 我们是否可以在端上 每次启动时 自动收集加载的类，如果发现这个类不在现有 的名单中 则加入到名单，在下次启动时进行预加载。 当然 具体的策略还需要做详细设计，比如 控制预加载名单的列表大小， 被加入预加载名单的类最低耗时阈值， 淘汰策略等等。

Retrofit ServiceMethod 预解析注入

背景

Retrofit 是目前最常用的网络库框架，其基于注解配置的网络请求方式及Adapter的设计模式大大简化了网络请求的调用方式。 不过其并没有采用类似APT的方式在编译时生成请求代码，而是采用运行时解析的方式。

当我们调用Retrofit.create(final Class service) 函数时，会生成一个该抽象接口的动态代理实例。

接口的所有函数调用都会被转发到该动态代理对象的invoke函数，最终调用loadServiceMethod(method).invoke 调用。

在loadServiceMethod函数中，需要解析原函数上的各种元信息，包括函数注解、参数注解、参数类型、返回值类型等信息，并最终生成ServiceMethod 实例，对原接口函数的调用其实最终触发的是 这个生成的ServiceMethod invoke函数的调用。

从源码实现上可以看出，对ServiceMethod的实例做了缓存处理，每个Method 对应一个ServiceMethod。

耗时测试

这里我模拟了一个简单的 Service Method， 并调用archiveStat 观察首次调用及其后续调用的耗时，注意这里的调用还未触发网络请求，其返回的是一个Call对象。

从测试结果上看，首次调用需要触发需要消耗1.7ms,而后续的调用 只需要消耗50微妙左右。

优化方案

由于首次调用接口函数需要触发ServiceMethod实例的生成，这个过程比较耗时，因此优化思路也比较简单，收集启动阶段会调用的 函数，提前生成ServiceMethod实例并写入到缓存中。

serviceMethodCache 的类型本身是ConcurrentHashMap,所以它是并发安全的。

但是源码中 进行ServiceMethod缓存判断的时候 还是以 serviceMethodCache为Lock Object 进行了加锁，这导致 多线程触发同时首次触发不同Method的调用时，存在锁等待问题

这里首先需要理解为什么这里需要加锁，其目的也是因为parseAnnotations 是一个好事操作，这里是为了实现类似 putIfAbsent的完全原子性操作。 但实际上这里加锁可以以 对应的Method类型为锁对象，因为本身不同Method 对应的ServiceMethod实例就是不同的。 我们可以修改其源码的实现来避免这种场景的锁竞争问题。

当然针对我们的优化场景，其实不修改源码也是可以实现的，因为 ServiceMethod.parseAnnotations 是无锁的，毕竟它是一个纯函数。 因此我们可以在异步线程调用parseAnnotations 生成ServiceMethod 实例，之后通过反射 写入 Retrofit实例的 serviceMethodCache 中。这样存在的问题是 不同线程可能同时触发了一个Method的解析注入，但 由于serviceMethodCache 本身就是线程安全的，所以 它只是多做了一次解析，对最终结果并无影响。

ServiceMethod.parseAnnotations是包级私有的，我们可以在当前工程创建一个一样的包，这样就可以直接调用该函数了。 核心实现代码如下

package retrofit2



import android.os.Build

import timber.log.Timber

import java.lang.reflect.Field

import java.lang.reflect.Method

import java.lang.reflect.Modifier



object RetrofitPreloadUtil {

    private var loadServiceMethod: Method? = null

    var initSuccess: Boolean = false

    //    private var serviceMethodCacheField:Map<Method,ServiceMethod<Any>>?=null

    private var serviceMethodCacheField: Field? = null



    init {

        try {

            serviceMethodCacheField = Retrofit::class.java.getDeclaredField("serviceMethodCache")

            serviceMethodCacheField?.isAccessible = true

            if (serviceMethodCacheField == null) {

                for (declaredField in Retrofit::class.java.declaredFields) {

                    if (Map::class.java.isAssignableFrom(declaredField.type)) {

                        declaredField.isAccessible =true

                        serviceMethodCacheField = declaredField

                        break

                    }

                }

            }

            loadServiceMethod = Retrofit::class.java.getDeclaredMethod("loadServiceMethod", Method::class.java)

            loadServiceMethod?.isAccessible = true

        } catch (e: Exception) {

            initSuccess = false

        }

    }



    /**

     * 预加载 目标service 的 相关函数，并注入到对应retrofit实例中

     */

    fun preloadClassMethods(retrofit: Retrofit, service: Class<*>, methodNames: Array<String>) {

        val field = serviceMethodCacheField ?: return

        val map = field.get(retrofit) as MutableMap<Method,ServiceMethod<Any>>



        for (declaredMethod in service.declaredMethods) {

            if (!isDefaultMethod(declaredMethod) && !Modifier.isStatic(declaredMethod.modifiers)

                && methodNames.contains(declaredMethod.name)) {

                try {

                    val parsedMethod = ServiceMethod.parseAnnotations<Any>(retrofit, declaredMethod) as ServiceMethod<Any>

                    map[declaredMethod] =parsedMethod

                } catch (e: Exception) {

                    Timber.e(e, "load method $declaredMethod for class $service failed")

                }

            }

        }



    }



    private fun isDefaultMethod(method: Method): Boolean {

        return Build.VERSION.SDK_INT >= 24 && method.isDefault;

    }



}

预加载名单收集

有了优化方案后，还需要收集原本在启动阶段会在主线程进行Retrofit ServiceMethod调用的列表， 这里采取的是字节码插桩的方式，使用的LancetX 框架进行修改。

目前名单的配置是预先收集好，在配置中心进行配置，运行时根据配置中写的配置 进行预加载。 这里还可以提供其他的配置方案，比如 提供一个注解用于标注该Retrofit函数需要进行预解析，

之后，在编译期间收集所有需要预加载的Service及函数，生成对应的名单，不过这个方案需要一定开发成本，并且需要去修改业务模块的代码，目前的阶段还处于验证收益阶段，所以暂未实施。

收益

App收集了启动阶段20个左右的Method 进行预加载，预计提升10~20ms。

ARouter

背景

ARouter框架提供了路由注册跳转 及 SPI 能力。为了优化冷启动速度，对于某些服务实例可以在启动阶段进行预加载生成对应的实例对象。

ARouter的注册信息是在预编译阶段(基于APT) 生成的，在编译阶段又通过ASM 生成对应映射关系的注入代码。

而在运行时以获取Service实例为例，当调用navigation函数获取实例最终会调用到 completion函数。

当首次调用时，其对应的RouteMeta 实例尚未生成，会继续调用 addRouteGroupDynamic函数进行注册。

addRouteGroupDynamic 会创建对应预编译阶段生成的服务注册类并调用loadInto函数进行注册。而某些业务模块如何服务注册信息比较多，这里的loadInto就会比较耗时。

整体来看，对于获取Service实例的流程， completion的整个流程 涉及到 loadInto信息注册、Service实例反射生成、及init函数的调用。 而completion函数是synchronized的，因此无法利用多线程进行注册来缩短启动耗时。

优化方案

这里的优化其实和Retroift Service 的注册机制类似，不同的Service注册时，其对应的元信息类(IRouteGroup)其实是不同的，因此只需要对对应的IRouteGroup加锁即可。

在completion的后半部分流程中，针对Provider实例生产的流程也需要进行单独加锁，避免多次调用init函数。

收益

根据线下收集的数据 配置了20+预加载的Service Method, 预期收益 10~20ms (中端机) 。

其他

后续将继续结合自身业务现状以及其他一线大厂分享的样例，在 x2c、class verify、禁用JIT、 disableDex2AOT等方面继续尝试优化。

如果通过本文对你有所收获，可以来个点赞、收藏、关注三连，后续将分享更多性能监控与优化相关的文章。

也可以关注个人公众号：编程物语

本文相关测试代码已分享至github: github.com/Knight-ZXW/…

APM性能监控与优化专栏

性能优化专栏历史文章：

前言

在app中，在实现分享功能的时候，通常会有一种以卡片形式展示和分享内容的分享方式。这种功能可以将信息以整洁、易读的方式呈现给用户，使他们能够快速了解内容的关键信息，并将其分享给其他人。那么在这篇文章中，就一起来探索下，如何使用Flutter来实现这卡片分享功能吧~

源代码：http://www.aliyundrive.com/s/FH7Xc2vyL…

效果图：

实现方案

为了卡片的样式的灵活性和可定制性，本文采用对组件进行截图的方式来实现卡片保存分享的功能，选择这个方案还有一点好处就是充分利用了flutter跨平台的优势。当然也会有一定的缺点，例如对于性能的考虑，当对复杂的嵌套卡片组件截图时，渲染和图像转换的计算量是需要考虑的，当然也可以选择忽略不计~

创建弹窗&卡片布局

在生成分享卡片的同时还会有其他的操作选项，例如保存图片、复制链接、浏览器打开等等，所以通常分享卡片的形式为弹窗形式，中间为分享卡片主体，剩余空间为操作项。

操作项组件封装：

class ImageDialog extends StatelessWidget {

  const ImageDialog({

    Key? key,

    required this.items,

  	...

  }) : super(key: key);

  final List<ItemLittleView> items;

	...



@override

Widget build(BuildContext context) {

  return Column(

    mainAxisAlignment: MainAxisAlignment.end,

    children: [

      Container(

        ...

        child: Row(

            children: items

                .map((e) => itemLittleView(

                    label: e.label,

                    icon: e.icon,

                    onTap: () {

                      Navigator.pop(context);

                      e.onTap?.call();

                    }))

                .toList()),

      ),

    ],

  );

}



Widget itemLittleView({

    required String label,

    required String icon,

    Function()? onTap,

  }) =>

      InkWell(

        onTap: onTap,

        child: Container(

          margin: EdgeInsets.only(right: 10),

          child: Column(

            mainAxisAlignment: MainAxisAlignment.end,

            children: [

              Container(

                //图标

              ),

							Container(

                //文字

              ),

            ],

          ),

        ),

      );

	 }

}



class ItemLittleView {

  final String label;

  final String icon;

  final Function()? onTap;



  ItemLittleView({required this.label, required this.icon, this.onTap});

}

需要加入新的操作项时，只需要简单的添加一个ItemLittleView即可。

ImageDialog(

  items: [

    ItemLittleView(

      label: "生成图片 ",

      icon: "assets/images/icon/ic_down.png",

      onTap: () => doSaveImage(),

    ),

    ...

  ],

),

卡片的布局则根据业务的需求自定义即可，本文也只是一个简单的例子。

渲染并截取组件截图

在flutter中可以使用RepaintBoundary将将组件渲染为图像。

• 第一步：定义全局的GlobalKey，用于获取卡片布局组件的引用

var repaintKey = GlobalKey();



RepaintBoundary(

     key: repaintKey,

      //分享卡片

     child: shareImage(),

),

• 第二步：使用RenderRepaintBoundary的toImage方法将其转换为图像

Future<Uint8List> getImageData() async {

  BuildContext buildContext = repaintKey.currentContext!;

  //用于存储截取的图片数据

  var imageBytes;

  //通过 buildContext 获取到 RenderRepaintBoundary 对象，表示要截取的组件边界

  RenderRepaintBoundary boundary =

      buildContext.findRenderObject() as RenderRepaintBoundary;



  //这行代码获取设备的像素密度，用于设置截取图片的像素密度

  double dpr = ui.window.devicePixelRatio;

  //将边界对象 boundary 转换为图像，使用指定的像素密度。

  ui.Image image = await boundary.toImage(pixelRatio: dpr);

  // image.width

  //将图像转换为ByteData数据，指定了数据格式为 PNG 格式。

  ByteData? byteData = await image.toByteData(format: ui.ImageByteFormat.png);

  //将ByteData数据转换为Uint8List 类型的图片数据。

  imageBytes = byteData!.buffer.asUint8List();

  return imageBytes;

}

• 第三步：获取权限&保存截图

//获取权限

_requestPermission() async {

    Map<Permission, PermissionStatus> statuses = await [

      Permission.storage,

    ].request();



    final info = statuses[Permission.storage].toString();

}



Future<String> saveImage(Uint8List imageByte) async {

  //将回调拿到的Uint8List格式的图片转换为File格式

  //获取临时目录

  var tempDir = await getTemporaryDirectory();

  //生成file文件格式

  var file =

      await File('${tempDir.path}/image_${DateTime.now().millisecond}.png')

          .create();

  //转成file文件

  file.writeAsBytesSync(imageByte);

  print("${file.path}");

  String path = file.path;

  return path;

}



//最后通过image_gallery_saver来保存图片

/// 执行存储图片到本地相册

  void doSaveImage() async {

    await _requestPermission();

    Uint8List data = await getImageData();

    String path = await saveImage(data);

    final result = await ImageGallerySaver.saveFile(path);

    showDialog(

        context: context,

        builder: (_) {

          return AlertDialog(

            title: Text("保存成功！"),

          );

        });

  }

到这里，分享卡片的功能就实现啦~

总结

在本文中，我们探索了使用Flutter实现卡片分享功能的过程。在开发app时，卡片分享功能可以为用户提供更好的交互和共享体验，我猜大家在开发的过程中也会有很大的概率碰上这样的需求。通过设计精美的卡片样式，可以帮助更快速的推广APP。

关于我

Hello，我是Taxze，如果您觉得文章对您有价值，希望您能给我的文章点个❤️，有问题需要联系我的话：我在这里 ，也可以通过掘金的新的私信功能联系到我。如果您觉得文章还差了那么点东西，也请通过关注督促我写出更好的文章~万

大家好，之前我已经写过了分析kotlin1.5、1.6、1.7、1.9插件版本新增的一些特性，唯独kotlin1.8的特性还没好好讲讲，本篇文章就带大家好好分析下kotlin1.8新增了那些特性，能对我们日常开发带来哪些帮助。

其中Kotlin1.8.0提供的特性有限，本篇文章主要是分析Kotlin1.8.20提供的一些新特性。下面是支持该插件的IDE对应版本：

一. 提供性能更好的Enum.entries替代Enum.values()

在之前，如果我们想遍历枚举内部元素，我们通常会写出以下代码：

enum class Color(val colorName: String, val rgb: String) {

    RED("Red", "#FF0000"),

    ORANGE("Orange", "#FF7F00"),

    YELLOW("Yellow", "#FFFF00")

}



fun main() {

    Color.values().forEach {

        println("${it.rgb}--${it.colorName}--${it.name}")

    }

}

但是不知道大家是否清楚，Color.values() 其实存在性能问题，换句话说，每调用一次该方法，就会触发重新分配一块内存，如果调用的频率过高，就很可能引发内存抖动。

我们可以反编译下枚举类简单看下原因：

Color.values()每次都会调用Object.clone()方法重新创建一个新的数组，这就是上面说的潜在的性能问题，github上也有相关的问题链接，感兴趣的可以看下：HttpStatus.resolve allocates HttpStatus.values() once per invocation。

同时Color.values()返回的是一个数组，而在我们大多开发场景中，可能集合使用的频率更高，这就可能涉及到一个数组转集合的操作。

基于以上考虑，Kotlin1.8.20官方提供了一个新的属性：Color.entries，这个方法会预分配一块内存并返回一个不可变集合，多次调用也不会产生潜在的性能问题。

我们简单看下使用：

fun main() {

    Color.entries.forEach {

        println("${it.rgb}--${it.colorName}--${it.name}")

    }

}

输出：

同时我们也可以从反编译的代码中看出区别：

不会每次调用都重新分配一块内存并返回。

如果想要使用这个特性，可以加上下面配置：

compileKotlin.kotlinOptions {

    languageVersion = "1.9"

}

另外多说一下，IntelliJ IDEA 2023.1版本也会检测代码中是否存在Enum.values()的使用，存在就提示使用Enum.entries代替。

二. 允许内联类声明次级构造函数

内联类在Kotlin1.8.20之前是不允许带body的次级构造函数存在的，也就是说下面的代码运行会报错：

@JvmInline

value class Person( val fullName: String) {

    constructor(name: String, lastName: String) : this("$name $lastName") {

        check(lastName.isNotBlank()) {

            "Last name shouldn't be empty"

        }

    }

}



fun main() {

    println(Person("a", "b").fullName)

}

运行看下结果：

如果没有次级构造函数body，下面这样写是没问题的：

    constructor(name: String, lastName: String) : this("$name $lastName") 

如果想要支持带body的次级构造函数，只需要在kotlin1.8.20插件版本上和上一个特性一样增加languageVersion = "1.9"配置即可。

然后上面的代码块运行就没问题了，我们看下输出：

fun main() {

    println(Person("a", "").fullName)

}

准确的执行了次级构造函数body内的逻辑。

三. 支持java synthethic属性引用

这个特性用文字不好解释，我们直接通过代码去学习下该特性。

当前存在一个类Person1：

public class Person1 {

    private String name;

    private int age;



    public Person1(String name, int age) {

        this.name = name;

        this.age = age;

    }



    public String getName() {

        return name;

    }



    public int getAge() {

        return age;

    }

}

在Kotlin1.8.20之前，以下这种写法是会报错的：

而是必须改成sortedBy(Person1::getAge)才能运行通过。

和上面特性一样，如果想要支持Person1::age这种引用方式，只需要在kotlin1.8.20插件版本上和上一个特性一样增加languageVersion = "2.1"配置即可。

PS：请注意，Kotlin官方网站提示配置languageVersion = "1.9" 就能使用上面的实验特性，但是编译器还是提示报错，然后你找报错提示信息改成了languageVersion = "2.1" 就正常了。

四. 新Kotlin K2编译器的更新

就是说目前Kotlin K2编译器还是一个实验阶段，不过Kotlin官方在其stable的路上又增加了一些更新：

1. 序列化插件的预览版本；


2. JS IR编译器的alpha支持；


3. Kotlin2.0版本特性的引入；

如果大家想要体验下最新版的Kotlin K2编译器，增加配置：languageVersion ="2.0"即可。

五. Kotlin标准库支持AutoCloseable

这个AutoCloseable 接口就是用来支持资源关闭的，搭配提供的use扩展函数，就能帮助我们在资源流使用完毕后自动关闭。

Kotlin之所以在标准库中支持，应该是想要支持多平台吧。

六. Kotlin标准库支持Base64编解码

这里不做太多介绍，看下面的使用例子即可：

七. Kotlin标准库@Volatile支持Kotlin/Native

@Volatile注解在Kotlin/JVM就是保证线程之间可见性以及有序性的，kotlin官方在Kotlin/Native中也支持了该注解使用，有兴趣的可以实战试下效果。

总结

本篇文章主要是介绍了Kotlin1.8版本新增的一些特性，主要挑了一些我能理解的、常用的一些特性拉出来介绍，希望能对你有所帮助。

历史文章

两个Kotlin优化小技巧，你绝对用的上

浅析一下：kotlin委托背后的实现机制

Kotlin1.9.0-Beta，它来了！！

聊聊Kotlin1.7.0版本提供的一些特性

聊聊kotlin1.5和1.6版本提供的一些新特性

kotlin密封sealed class/interface的迭代之旅

优化@BuilderInference注解，Kotlin高版本下了这些“毒手”！

@JvmDefaultWithCompatibility优化小技巧

转载请注明出处：juejin.cn/post/724677…

本文出自 容华谢后的博客

0.写在前面

现如今跨平台技术被越来越多的开发者提起和应用，从最早的Java到后来的RN、Weex，到现在的Compose、Flutter，大前端已经成为了趋势，很多公司为了节省成本，包括一些大厂已经在Android和iOS平台上使用了Flutter技术，效果还可以，贴近原生但是还会有一些卡顿的问题，好在Flutter目前还在不断的优化更新，希望越来越好吧。

Flutter从2017年发布到现在已经历经了6年，如果你现在创建一个Flutter项目，会发现已经支持了Android、iOS、Linux、MacOS、Web、Windows六大主流的操作系统平台，我以前经常会写一些在Windows上运行的小工具，使用java写的不仅复杂界面也不好看，用Flutter试了试，好像发现了新大陆，在PC上运行十分流畅，还直接支持在其他平台上运行，感觉十分不错，这也让我对未来Flutter的发展抱有期待。

Flutter开发有两种方式，一种是纯Flutter开发，一种是Flutter+原生的开发方式，正如上面所说的，Flutter在PC上运行十分流畅，可能是PC配置比较高的原因，但是在客户端上的运行效果却不如人意，启动有点慢，一些复杂列表有点卡，一些底层功能的API不支持，这就需要原生开发的介入，小部分原生+大部分Flutter开发可能是后续比较主流的一种开发方式。

本文主要讲的是在Android平台上，与Flutter混合开发的一些步骤，一起来看下吧。

1.准备

1.1 先贴下我用的开发环境：

• 
  

  操作系统：Windows 10

  
  


• 
  

  IDE：Android Studio Flamingo

  
  


• 
  

  Android SDK：33

  
  


• 
  

  Gradle：8.0.2

  
  


• 
  

  JDK：17.0.7

  
  


• 
  

  Flutter：3.10.4

  
  

1.2 下载Flutter SDK

下载地址：docs.flutter.dev/get-started…

是个压缩包，解压到你存放开发环境的目录，然后在AS中打开 File->Settings->Languages&Frameworks，在里面配置一下SDK的路径就可以了。

1.3 配置环境变量

和Jdk一样，为了使用方便，还需要配置下环境变量，设置->关于->高级系统设置->环境变量，找到用户变量，在Path里面新增一个路径 flutter SDK的路径\bin，前面如果有值的话，别忘了在前面加个英文分号进行分割。

1.4 检测flutter状态

为了验证Flutter是否安装成功，打开cmd命令行，输入 flutter doctor 进行检测：

如果出现上面的提示，是因为Android证书的问题，再输入 flutter doctor --android-licenses 进行修复：

可能会出现这样的错误，这个是因为JDK版本有点低，现在大部分还是用的1.8版本，安装配置下JDK 17就可以，再运行下flutter doctor，已经可以了：

1.5 安装Flutter插件

在AS中打开 File->Settings->Plugins，安装下面两个插件：

到这里，所有的准备工作就完成了，接下来去创建项目。

2.创建项目

首先创建一个标准的Android项目，在此基础上，打开 File->New->New Flutter Project 创建一个Flutter Module：

注意Project location要选择你当前的工程目录，Project types选择Module，然后CREATE，看下创建好的目录结构：

3.项目Flutter配置

打开项目根目录的settings.gradle配置文件，增加下面的配置：

// Flutter配置

setBinding(new Binding([gradle: this]))

evaluate(new File(

        settingsDir,

        'flutter_lib/.android/include_flutter.groovy'

))

include ':flutter_lib'

然后再修改下dependencyResolutionManagement，把FAIL_ON_PROJECT_REPOS 改成 PREFER_SETTINGS，增加flutter的maven仓库地址：

dependencyResolutionManagement {

    repositoriesMode.set(RepositoriesMode.PREFER_SETTINGS)

    repositories {

        google()

        mavenCentral()

        maven {

            allowInsecureProtocol = true

            url "http://download.flutter.io"

        }

    }

}

找到flutter_lib->.android->Flutter->build.gradle，在android属性增加namespace，这个是Gradle 8.0新增的特性：

android {

    namespace 'com.example.flutter_lib'

    compileSdkVersion flutter.compileSdkVersion

    ndkVersion flutter.ndkVersion

    ...

}

找到主app的build.gradle，在dependencies中引用flutter模块，注意模块名称是flutter，无论你创建的Moudle是什么名字，这里的名字都是flutter：

dependencies {

    ...

    implementation project(':flutter')

}

4.开始使用

在清单文件中，增加下面的activity标签，注意这个Activity是SDK中自带的，不需要自己手动创建：

<application>

    ...



    <activity

        android:name="io.flutter.embedding.android.FlutterActivity"

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

        android:hardwareAccelerated="true"

        android:windowSoftInputMode="adjustResize" />

</application>

在MainActivity写个跳转方法进行测试：

val intent = FlutterActivity

    .withNewEngine()

    .initialRoute("home")

    .build(this)

startActivity(intent)

看下效果：

可以看到在点击跳转按钮后，有一个明显的停顿，这是因为初始化Flutter引擎比较慢导致的，那就提前初始化试试，在Application中初始化引擎：

class App : Application() {



    override fun onCreate() {

        super.onCreate()

        // 创建 Flutter 引擎

        val flutterEngine = FlutterEngine(this)

        // 指定要跳转的flutter页面

        flutterEngine.navigationChannel.setInitialRoute("main")

        flutterEngine.dartExecutor.executeDartEntrypoint(DartExecutor.DartEntrypoint.createDefault())

        // 这里做一个缓存，可以在适当的时候执行它，例如app里，在跳转前执行预加载

        val flutterEngineCache = FlutterEngineCache.getInstance()

        flutterEngineCache.put("default_engine_id", flutterEngine)

    }

}

然后使用已经提前创建后的引擎再次跳转：

val intent = FlutterActivity

    .withCachedEngine("default_engine_id")

    .build(this)

startActivity(intent)

看下效果，已经非常丝滑了：

5.写在最后

GitHub地址：github.com/alidili/Flu…

到这里，Flutter与原生混合开发的基本步骤就介绍完了，如有问题可以给我留言评论或者在GitHub中提交

前言

通常我们在App中会使用第三方的开源代码，按照许可协议，我们应该在App中公开使用的开源代码并且附上对应的开源协议。当然，实际上只有少部分注重合规性的大厂才会这么干，比如下图是支付宝的关于界面的第三方信息。当然，对于小企业，基本上都不会放使用的第三方开源代码的任何信息。

不过，作为一个有“追求”的码农，我们还是想对开源软件致敬一下的，毕竟，没有他们我都不知道怎么写代码。然而，我们的 App 里用了那么多第三方开源插件，总不能一个个找出来一一致敬吧？怎么办？其实，Flutter 早就为我们准备好了一个组件，那就是本篇要介绍的 AboutDialog。

AboutDialog 简介

AboutDialog 是一个对话框，它可以提供 App 的基本信息，如 Icon、版本、App 名称、版权信息等。

同时，AboutDialog还提供了一个查看授权信息（View Licenses）的按钮，点击就可以查看 App 里所有用到的第三方开源插件，并且会自动收集他们的 License 信息展示。所以，使用 AboutDialog 可以让我们轻松表达敬意。怎么使用呢？非常简单，我们点击一个按钮的时候，调用 showAboutDialog 就搞定了，比如下面的代码：

IconButton(

  onPressed: () {

    showAboutDialog(

      context: context,

      applicationName: '岛上码农',

      applicationVersion: '1.0.0',

      applicationIcon: Image.asset('images/logo.png'),

      applicationLegalese: '2023 岛上码农版权所有'

    );

  },

  icon: const Icon(

    Icons.info_outline,

    color: Colors.white,

  ),

),

参数其实一目了然，具体如下：

• context：当前的 context；


• applicationName：应用名称；


• applicationVersion：应用版本，如果要自动获取版本号也可以使用 package_info_plus 插件。


• applicationIcon：应用图标，可以是任意的 Widget，通常会是一个App 图标图片。


• applicationLegalese：其他信息，通常会放置应用的版权信息。

点击按钮，就可以看到相应的授权信息了，点击一项就可以查看具体的 License。我看了一下使用的开源插件非常多，要是自己处理还真的很麻烦。

可以说非常简单，当然，如果你直接运行还有两个小问题。

按钮本地化

AboutDialog 默认提供了两个按钮，一个是查看授权信息，一个是关闭，可是两个按钮 的标题默认是英文的（分别是VIEW LICENSES和 CLOSE）。

如果要改成本地话的，还需要做一个自定义配置。我们扒一下 AboutDialog 的源码，会发现两个按钮在DefaultMaterialLocalizations中定义，分别是viewLicensesButtonLabel和closeButtonLabel。这个时候我们自定义一个类集成DefaultMaterialLocalizations就可以了。

class MyMaterialLocalizationsDelegate

    extends LocalizationsDelegate<MaterialLocalizations> {

  const MyMaterialLocalizationsDelegate();



  @override

  bool isSupported(Locale locale) => true;



  @override

  Future<MaterialLocalizations> load(Locale locale) async {

    final myTranslations = MyMaterialLocalizations(); // 自定义的本地化资源类

    return Future.value(myTranslations);

  }



  @override

  bool shouldReload(

          covariant LocalizationsDelegate<MaterialLocalizations> old) =>

      false;

}



class MyMaterialLocalizations extends DefaultMaterialLocalizations {

  @override

  String get viewLicensesButtonLabel => '查看版权信息';



  @override

  String get closeButtonLabel => '关闭';



}

然后在 MaterialApp 里指定本地化localizationsDelegates参数使用自定义的委托类对象就能完成AboutDialog两个按钮文字的替换。

return MaterialApp(

  debugShowCheckedModeBanner: false,

  title: 'Flutter Demo',

  theme: ThemeData(

    primarySwatch: Colors.blue,

  ),

  home: const AboutDialogDemo(),

  localizationsDelegates: const [MyMaterialLocalizationsDelegate()],

);

添加自定义的授权信息

虽然 Flutter 会自动收集第三方插件，但是如果我们自己使用了其他第三方的插件的话，比如没有在 pub.yaml 里引入，而是直接使用了源码。那么还是需要手动添加一些授权信息的，这个时候我们需要自己手动添加了。添加的方式也不麻烦，Flutter 提供了一个LicenseRegistry的工具类，可以调用其 addLicense 方法来帮我们添加授权信息。具体使用如下：

LicenseRegistry.addLicense(() async* {

  yield const LicenseEntryWithLineBreaks(

    ['关于岛上码农'],

    '我是岛上码农，微信公众号同名。\f如有问题可以加本人微信交流，微信号：island-coder。',

  );

});

这个方法可以在main方法里调用。其中第一个参数是一个数组，是因为可以允许多个开源代码共用一份授权信息。同时，如果一份开源插件有多个授权信息，可以多次添加，只要名称一致，Flutter就会自动合并，并且会显示该插件的授权信息条数，点击查看时，会将多条授权信息使用分割线分开，代码如下所示：

void main() {

  runApp(const MyApp());

  LicenseRegistry.addLicense(() async* {

    yield const LicenseEntryWithLineBreaks(

      ['关于岛上码农'],

      '我是岛上码农，微信公众号同名。如有问题可以加本人微信交流，微信号：island-coder。',

    );

  });



  LicenseRegistry.addLicense(() async* {

    yield const LicenseEntryWithLineBreaks(

      ['关于岛上码农'],

      '使用时请注明来自岛上码农、。',

    );

  });

}

总结

本篇介绍了在 Flutter 中快速展示授权信息的方法，通过 AboutDialog 就可以轻松搞定，各位“抄代码”的码农们，赶紧用起来向大牛们致敬吧！

我是岛上码农，微信公众号同名。如有问题可以加本人微信交流，微信号：island-coder。

👍🏻：觉得有收获请点个赞鼓励一下！

🌟：收藏文章，方便回看哦！

💬：评论交流，互相进步！

作者：岛上码农
来源：juejin.cn/post/7246328828837871677

大家好，kotlin的属性委托、类委托、lazy等委托在日常的开发中，给我们提供了很大的帮助，我之前的文章也是有实战过几种委托。不过对比委托实现的背后机制一直都没有分析过，所以本篇文章主要是带领大家分析下委托的实现原理，加深对kotlin的理解。

一. lazy委托

这里我们不说用法，直接说背后的实现原理。

先看一段代码：

val content: String by lazy {

    "oiuytrewq"

}



fun main() {

    println(content.length)

}

我们看下反编译后的java代码：

1. 首先会通过DelegateDemoKt静态代码块饿汉式的方式创建一个Lazy类型的变量content$delegate，命名的规则即代码中定义的原始变量值拼接上$delegate，我们原始定义的content变量就会从属性定义上消失，但会生成对应的get方法，即getContent()；

2. 当我们在main方法中调用content.length时，其实就是调用getContent().length()，而getContent()最终是调用了content$delegate.getValue方法；

3. 这个lazy类型的变量是调用了LazyKt.lazy()方法创建，而真正的核心逻辑——该方法具体参数的传入，在反编译的java代码中并没有体现；

java代码既然看不到，我们退一步看下字节码：

上面是DelegateDemoKt类构造器对应的字节码，其中就是获取了DelegateDemoKt$content$2作为参数传入了LazyKt.lazy()方法。

我们看下DelegateDemoKt$content$2类的实现字节码：

DelegateDemoKt$content$2类实现了Function0接口，所以上面lazy的真正实现逻辑就是DelegateDemoKt$content$2类的invoke方法中，上图的字节码红框圈出的地方就很直观的看出来了。

二. 属性委托

属性委托的委托类就是指实现了ReadWriteProperty和ReadOnlyProperty接口的类，像官方提供的Delegates.observable()和Delegates.vetoable()这两个api也是借助前面两个接口实现的。这里我们就以支持读写的ReadWriteProperty委托接口进行举例分析。

先看一段例子代码：

var age: Int by object : ReadWriteProperty<Any?, Int> {

    override fun getValue(thisRef: Any?, property: KProperty<*>): Int {

        return 10

    }



    override fun setValue(thisRef: Any?, property: KProperty<*>, value: Int) {

        val v = value * value

        println("setValue: $v")

    }

}



fun main() {

    age = 4

    println(age)

}

我们看下反编译的java代码：

public final class DelegateDemoKt {

   // $FF: synthetic field

   static final KProperty[] $$delegatedProperties = new KProperty[]{Reflection.mutableProperty0(new MutablePropertyReference0Impl(DelegateDemoKt.class, "age", "getAge()I", 1))};

   @NotNull

   private static final <undefinedtype> age$delegate = new ReadWriteProperty() {

      @NotNull

      public Integer getValue(@Nullable Object thisRef, @NotNull KProperty property) {

         Intrinsics.checkNotNullParameter(property, "property");

         return 10;

      }



      public void setValue(@Nullable Object thisRef, @NotNull KProperty property, int value) {

         Intrinsics.checkNotNullParameter(property, "property");

         int v = value * value;

         String var5 = "setValue: " + v;

         System.out.println(var5);

      }

   };



   public static final int getAge() {

      return age$delegate.getValue((Object)null, $$delegatedProperties[0]);

   }



   public static final void setAge(int var0) {

      age$delegate.setValue((Object)null, $$delegatedProperties[0], var0);

   }



   public static final void main() {

      setAge(4);

      int var0 = getAge();

      System.out.println(var0);

   }

}

1. 和lazy有些类似，会生成一个实现了ReadWriteProperty接口的匿名类变量age$delegate，命名规则和lazy相同，通过还帮助我们生成了对应的getAge和setAge方法；

2. 当我们在代码中执行age = 4就会调用setAge(4)方法，最终会调用age$delegate.setValue()方法；类似的调用age就会调用getAge()，最终调用到age$delegate.getValue()方法；

3. 编译器还通过反射帮助我们生成了一个KProperty类型的$$delegatedProperties变量，主要是ReadWriteProperty的setValue和getValue方法都需要传入这样一个类型的对象，通过$$delegatedProperties变量我们可以访问到具体的变量名等信息；

类似的还有一种属性委托，我们看下代码：

val map = mutableMapOf<String, Int>()



val name: Int by map

上面代码的意思是：当访问name时，就会从map这个散列表中获取key为"name"的value值并返回，不存在就直接抛异常，接下来我们看下反编译后的java代码：

public final class DelegateDemoKt {

   // $FF: synthetic field

   static final KProperty[] $$delegatedProperties = new KProperty[]{Reflection.property0(new PropertyReference0Impl(DelegateDemoKt.class, "name", "getName()I", 1))};

   @NotNull

   private static final Map map = (Map)(new LinkedHashMap());

   @NotNull

   private static final Map name$delegate;



   static {

      name$delegate = map;

   }



   public static final int getName() {

      Map var0 = name$delegate;

      Object var1 = null;

      KProperty var2 = $$delegatedProperties[0];

      return ((Number)MapsKt.getOrImplicitDefaultNullable(var0, var2.getName())).intValue();

   }

}

1. 生成一个Map类型的name$delegate变量，这个变量其实就是我们定义的map散列表；

2. 通过反射生成了一个KProperty类型对象变量$$delegatedProperties，通过这个对象的getName()我们就能拿到变量名称，比如这里的"name"变量名；

3. 最终调用了MapsKt.getOrImplicitDefaultNullable方法，去map散列表去查找"name"这个key对应的value；

PS：记得kotlin1.6还是1.7的插件版本对应委托进行了优化，这个后续的文章会再进行讲解。

三. 类委托

类委托实现就比较简单了，这里我们看下样例代码：

fun interface Fruit {

    fun type(): Int

}



class FruitProxy(private val model: Fruit) : Fruit by model



fun main() {

    val proxy: FruitProxy = FruitProxy {

        -1

    }

    println(proxy.type())

}

反编译成java代码看下：

首先我们看下FruitProxy这个类，其实现了Fruit接口，借助属性委托特性，编译器会自动帮助我们生成type() 接口方法的实现，并再其中调用构造方法传入的委托类对象model的type()方法，类委托的核心逻辑就这些。

再main()方法中构造FruitProxy时，我们也无法知晓具体的构造参数对象是啥，和上面的lazy一样，我们看下字节码：

其实FruitProxy方法就传入了一个DelegateDemoKt$main$proxy$1类型的对象，并实现了Fruit接口重写了type方法。

总结

本篇文章主要是讲解了三种委托背后的实现原理，有时候反编译字节码看不出来原理的，可以从字节码中寻找答案，希望本篇文章能对你有所帮助。

历史文章

这里是我整理的过往kotlin特性介绍的历史文章，大家感兴趣可以阅读下：

Kotlin1.9.0-Beta，它来了！！

聊聊Kotlin1.7.0版本提供的一些特性

聊聊kotlin1.5和1.6版本提供的一些新特性

kotlin密封sealed class/interface的迭代之旅

优化@BuilderInference注解，Kotlin高版本下了这些“毒手”！

@JvmDefaultWithCompatibility优化小技巧

打开屏幕共享，差点直接被转账

今天和爸妈聊天端午回家的事情，突然说到最近AI诈骗的事情，千叮咛万嘱咐说要对方说方言才行，让他们充分了解一下现在骗子诈骗的手段，顺便也找了一下骗子还有什么其他的手段，打算一起和他们科普一下，结果就发现下面这一则新闻：

在辽宁大连务工的耿女士接到一名自称“大连市公安局民警”的电话，称其涉嫌广州一起诈骗案件，让她跟广州警方对接。耿女士在加上所谓的“广州警官”的微信后，这位“警官”便给耿女士发了“通缉令”，并要求耿女士配合调查，否则将给予“强制措施”。随后，对方与耿女士视频，称因办案需要，要求耿女士提供“保证金”，并将所有存款都集中到一张银行卡上，再把钱转到“安全账户”。

期间，通过 “屏幕共享”，对方掌握了耿女士银行卡的账号和密码。耿女士先后跑到多家银行，取出现金，将钱全部存到了一张银行卡上。正当她打算按照对方指示，进行下一步转账时，被民警及时赶到劝阻。在得知耿女士泄露了银行卡号和密码后，银行工作人员立即帮助耿女士修改了密码，幸运的是，银行卡的近6万元钱没有受到损失。

就这手段，我家里的老人根本无法预防，除非把手机从他们手里拿掉，与世隔绝还差不多，所以还是做APP的各大厂商努力一下吧！

希望各大厂商都能看看下面这个防劫持SDK，让出门在外打工的我们安心一点。

防劫持SDK

一、简介

防劫持SDK是具备防劫持兼防截屏功能的SDK，可有效防范恶意程序对应用进行界面劫持与截屏的恶意行为。

二、iOS版本

2.1 环境要求

2.2 SDK接入

2.2.1 DxAntiHijack获取

从官网下载SDK获取，下面是SDK的目录结构

DXhijack_xxx_xxx_xxx_debug.zip 防劫持debug 授权集成库 DXhijack_xxx_xxx_xxx_release.zip 防劫持release 授权集成库

• 
  

  解压DXhijack_xxx_xxx_xxx_xxx.zip 文件，得到以下文件

  
  
  
  
  • 
    

    DXhijack 文件夹

    
    
    
    
    • DXhijack.a 已授权静态库
    
    
    • Header/DXhijack.h 头文件
    
    
    • dx_auth_license.description 授权描述文件
    
    
    • DXhijackiOS.framework 已授权framework 集成库
    
    
    
    
  
  
  
  

2.2.2 将SDK接入XCode

2.2.2.1 导入静态库及头文件

将SDK目录（包含静态库及其头文件）直接拖入工程目录中，或者右击总文件夹添加文件。 或者 将DXhijackiOS.framework 拖进framework存放目录

2.2.2.2 添加其他依赖库

在项目中添加 libc++.tbd 库，选择Target -> Build Phases，在Link Binary With Libraries里点击加号，添加libc++.tbd

2.2.2.3 添加Linking配置

在项目中添加Linking配置，选择Target -> Build Settings，在Other Linker Flags里添加-ObjC配置

2.3 DxAntiHijack使用

2.3.1 方法及参数说明

@interface DXhijack : NSObject



+(void)addFuzzy;   //后台模糊效果

+(void)removeFuzzy;//后台移除模糊效果

@end

2.3.2 使用示例

在对应的AppDelegate.m 文件中头部插入

#import "DXhijack.h"



//在AppDelegate.m 文件中applicationWillResignActive 方法调用增加

 - (void)applicationWillResignActive:(UIApplication *)application {

     [DXhijack addFuzzy];

 }

 

 //在AppDelegate.m 文件中applicationDidBecomeActive 方法调用移除

 - (void)applicationDidBecomeActive:(UIApplication *)application {

     [DXhijack removeFuzzy];

 }

 

三、Android版本

3.1 环境要求

3.2 SDK接入

3.2.1 SDK获取

1. 访问官网，注册账号


2. 登录控制台，访问“全流程端防控->安全键盘SDK”模块


3. 新增App，填写相关信息


4. 下载对应平台SDK

3.2.2 SDK文件结构

• 
  

  SDK目录结构 

  
  
  
  
  • dx-anti-hijack-${version}.jar Android jar包
  
  
  • armeabi, armeabi-v7a, arm64-v8a, x86 4个abi平台的动态库文件
  
  
  
  

3.2.3 Android Studio 集成

点击下载Demo

3.2.3.1 Android Studio导入jar, so

把dx-anti-hijack-x.x.x.jar, so文件放到相应模块的libs目录下

• 在该Module的build.gradle中如下配置:

 android{

     sourceSets {

         main {

             jniLibs.srcDirs = ['libs']

         }

     }

     

     repositories{

         flatDir{

             dirs 'libs'

         }

     }

 }

 

 

 dependencies {

     implementation fileTree(dir: 'libs', include: ['*.jar'])

 }

 

 

3.2.3.2 权限声明

Android 5.0(不包含5.0)以下需要在项目AndroidManifest.xml文件中添加下列权限配置：

<uses-permission android:name="android.permission.GET_TASKS"/>

3.2.3.3 混淆配置

-dontwarn *.com.dingxiang.mobile.**

-dontwarn *.com.mobile.strenc.**

-keep class com.security.inner.**{*;}

-keep class *.com.dingxiang.mobile.**{*;}

-keep class *.com.mobile.strenc.**{*;}

-keep class com.dingxiang.mobile.antihijack.** {*;}

3.3 DxAntiHijack 类使用

3.3.1 方法及参数说明

3.3.1.1 初始化

建议在Application的onCreate下調用

/**

* 使用API前必須先初始化

* @param context

*/

public static void init(Context context);

3.3.1.2 反截屏功能

/**

* 反截屏功能

* @param activity 

*/

public static void DGCAntiHijack.antiScreen(Activity activity);



/**

* 反截屏功能

* @param dialog

*/

public static void DGCAntiHijack.antiScreen(Dialog dialog);

3.3.1.3 反劫持检测

/**

* 调用防劫持检测，通常现在activity的onPause和onStop调用

* @return 是否存在被劫持风险

*/

public static boolean DGCAntiHijack.antiHijacking();

3.3.2 使用示例

//使用反劫持方法

@Override

protected void onPause() {

   boolean safe = DXAntiHijack.antiHijacking();

   if(!safe){

       Toast.makeText(getApplicationContext(), "App has entered the background", Toast.LENGTH_LONG).show();

   }

   super.onPause();

}



@Override

protected void onStop() {

   boolean safe = DXAntiHijack.antiHijacking();

   if(!safe){

       Toast.makeText(getApplicationContext(), "App has entered the background", Toast.LENGTH_LONG).show();

   }

   super.onStop();

}







//使用反截屏方法

@Override

protected void onCreate(Bundle savedInstanceState) {

   super.onCreate(savedInstanceState);

   setContentView(R.layout.activity_main);

   DXAntiHijack.antiScreen(MainActivity.this);

}

以上。

结语

这种事情层出不穷，真的不是吾等普通民众能解决的，最好有从上至下的政策让相应的厂商（尤其是银行和会议类的APP）统一做处理，这样我们在外

前言

本文档只介绍工具的使用方法，有时间再写一篇介绍一下实现细节。
整体的话就是借助这个工具方便记录当前坐标，可以实现游戏资源不浪费。

阅读本文档前提是大家是《末日血战》游戏玩家。

工具下载安装

download.csdn.net/download/u0…

安装工具

工具安装后，桌面会有这个图标。

在打开工具前需进入应用设置页打开这个应用的显示悬浮窗权限。

填入初始坐标

打开工具大致显示是这个样子，坐标初始都是0，那么填入相应的坐标保存就会是这个样子。

可以看到左上角有个小图，这是一个直接坐标系的缩略图，拖拽可以移动位置。
小图中会显示3个红点，一个绿点。绿点表示当前坐标，红点表示终极坐标。当前点的坐标是固定显示在左上角的

此时可以按返回键退出app，但是不要杀掉应用。

建立坐标系

初次使用，建议可以打开小程序截一张生存之路的全屏图，然后我们打开这张图并横屏显示图片开始操作。当已经熟悉工具如何使用后可以在游戏中进行操作了

建立坐标系

打开图片或者游戏，进入到这个界面，点击左上角悬浮窗上的开始按钮，会看到这样一个界面（没有中间两条直线）

我们的目标就是为了建立中间两条直线。

按图片指示的顺序操作。尽可能点击在轴线的中心位置。

以上操作只需要执行一次，后续就不需要操作了。
完成以上操作，就得到有两条线的图了。这个时候就完成了建立坐标系

开始寻找终极坐标

注意观察小地图，找一个我们没有到达的离的近的终极坐标为目标。可以看到x和y的差距。

举个例子，我们当前坐标49,52,刚刚已经在48,52这里取得了一个宝箱，那么下一个目的地选237,29。因为是x坐标相差较大，我们x太小，而y坐标我们的大一点。所以主要的方向是加x，少量的减y。

所以我们应该按x轴正方向和y轴负方向这里走，因为x相差较大，所以如果可以的话（有障碍物就走不了）就直接沿着x轴正方向走就好了。

我想游戏玩家应该还是知道要往哪走的，但是容易算错坐标或者根本懒得记，凭运气。那么我们指定往哪走之后，接下来怎么使用这个工具。

• 1、点击一个位置（我们要让小车开到的位置），这个时候小车不会走，因为我们工具盖住了游戏


• 2、app回退一下（不是杀掉应用），这时可以发现小车在抖动了，其实就是小车可以走了，再点一下刚才那个位置，小车就会走到那个位置。这样我们就完成了一次移动和坐标记录。小地图当前坐标就会变化。绿点也会移动。


• 3、小车走完之后，我们再点开始，然后重复1，2 步骤。

补充

• 1、本工具存在误差，一般每次执行在小车x,y <=|2| 基本100%准确。x,y <= |3| 100个汽油可能会有|2|以内坐标的误差（仅本人测试数据）


• 1、点击位置尽可能点在地图块的中间，这样可以减少误差。遇到坐标点在路径上，可以进入其中对当前坐标进行校准，当然一般是不需要的。


• 1、如果遇到了事件，我们就处理完事件后再点开始按钮


• 2、回退怎么用：右下角回退用途是当我们不想走这一步，可以回退一步。重新再点一个点。确认这个点没问题我们就回退app，如果回退还是后悔不想走这一步(这个回退是指回退我们的记录，游戏中的步骤我们肯定是做不到回退的)，再打开开始点击回退。


• 3、本次汽油用完后，就可以杀掉辅助工具app了。下次有汽油可以继续直接使用,记住使用过程中的退出都是回退而不是杀掉app

最后

希望大家先熟悉工具流程，可以截一张图去操作，然后再在游戏中操作避免浪费资源。坐标可以随时矫正。

希望大家游戏愉快，也希望本工具对大家有所帮助。

如有建议或问题可在文章评论

介绍

动画是 Android 应用程序中重要的交互特性。Android 提供了多种动画效果，包括平移、缩放、旋转和透明度等，它们可以通过代码或 XML 来实现。本文将介绍 Android 动画的原理和实现方法，并提供一些示例。

原理

Android 动画的实现原理是通过改变视图的属性来实现的。当我们在代码中设置视图的属性值时，Android 会通过平滑过渡的方式来将视图从一个状态过渡到另一个状态。这种平滑过渡的效果就是动画效果。

属性

Android 中有许多属性可以用来实现动画效果，以下是一些常用的属性：

• translationX：视图在 X 轴上的平移距离。


• translationY：视图在 Y 轴上的平移距离。


• scaleX：视图在 X 轴上的缩放比例。


• scaleY：视图在 Y 轴上的缩放比例。


• rotation：视图的旋转角度。


• alpha：视图的透明度。

类型

Android 中有多种不同类型的动画，每种类型都有其自身的特点和用途：

View 动画

View 动画是一种在应用程序中实现动画效果的简单方法。它可以通过 XML 或代码来实现。View 动画可以应用于任何 View 对象，包括按钮、文本框、图像等等。常见的 View 动画包括平移、缩放、旋转和透明度等效果。以下是一个 View 动画的 XML 示例：

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

    <translate

        android:fromXDelta="0%"

        android:toXDelta="50%"

        android:duration="500"

        android:repeatCount="infinite"

        android:repeatMode="reverse" />

</set>

帧动画

帧动画是一种将一系列图像逐帧播放来实现动画效果的方法。它可以通过 XML 或代码来实现。帧动画常用于播放一系列连续的图像，例如动态图像、电影等等。以下是一个帧动画的 XML 示例：

<animation-list xmlns:android="http://schemas.android.com/apk/res/android"

    android:oneshot="false">

    <item android:drawable="@drawable/animation_frame1" android:duration="50" />

    <item android:drawable="@drawable/animation_frame2" android:duration="50" />

    <item android:drawable="@drawable/animation_frame3" android:duration="50" />

    ...

</animation-list>

属性动画

属性动画是一种可以改变视图属性值的动画效果。它可以通过 XML 或代码来实现。属性动画可以应用于任何属性，包括大小、颜色、位置、透明度等等。它可以在运行时动态地更改属性值，从而实现平滑的动画效果。以下是一个属性动画的 Java 代码的示例：

ObjectAnimator animator = ObjectAnimator.ofFloat(view, "translationX", 0f, 300f);

animator.setDuration(1000);

animator.start();

过渡动画

过渡动画是一种在应用程序中实现平滑过渡效果的方法。它可以通过 XML 或代码来实现。过渡动画常用于实现屏幕之间的切换效果，例如滑动、淡入淡出等等。以下是一个过渡动画的 XML 示例：

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

    <fade android:duration="500" />

</transition>

Lottie 动画

Lottie 是 Airbnb 开源的一种动画库，它可以将 Adobe After Effects 中制作的动画直接导出为 JSON 格式，并在 Android 应用程序中使用。Lottie 动画可以实现非常复杂的动画效果，例如骨骼动画、粒子效果等等。

实现

要实现 Android 动画，我们需要按照以下步骤：

1. 创建动画资源文件。


2. 在代码中加载动画资源文件。


3. 将动画应用到相应的视图中。

我们可以通过 XML 或代码来创建动画资源文件。以下是一个简单的平移动画的 XML 示例：

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

    <translate

        android:fromXDelta="0%p"

        android:toXDelta="50%p"

        android:duration="500"

        android:repeatCount="infinite"

        android:repeatMode="reverse" />

</set>

在代码中加载动画资源文件的方法如下：

Animation animation = AnimationUtils.loadAnimation(this, R.anim.translate);

最后，我们需要将动画应用到相应的视图中：

imageView.startAnimation(animation);

下面是一个实现平移动画效果的 Java 代码示例：

View view = findViewById(R.id.view);

ObjectAnimator animator = ObjectAnimator.ofFloat(view, "translationX", 0f, 300f);

animator.setDuration(1000);

animator.start();

结论

无论是在应用程序设计中还是在用户体验中，动画都是一个非常重要的因素。如果你想要在你的应用程序中实现动画效果，本文提供了 Android 动画的基本原理和实现方法。你可以根据自己的需要使用不同类型的动画来实现不同的效果。

推荐

android_startup: 提供一种在应用启动时能够更加简单、高效的方式来初始化组件，优化启动速度。不仅支持Jetpack App Startup的全部功能，还提供额外的同步与异步等待、线程控制与多进程支持等功能。

AwesomeGithub: 基于Github的客户端，纯练习项目，支持组件化开发，支持账户密码与认证登陆。使用Kotlin语言进行开发，项目架构是基于JetPack&DataBinding的MVVM；项目中使用了Arouter、Retrofit、Coroutine、Glide、Dagger与Hilt等流行开源技术。

flutter_github: 基于Flutter的跨平台版本Github客户端，与AwesomeGithub相对应。

android-api-analysis: 结合详细的Demo来全面解析Android相关的知识点, 帮助读者能够更快的掌握与理解所阐述的要点。

daily_algorithm: 每日一算法，由浅入深

1. 前言

因为最近没有什么比较好的技术想要分享，所以来水一下文章，啊不对，是分享一下一些思路，和大家交流一下想法，没准能产生一些新的想法。这篇文章不具备权威，不一定正确，简单来说全都是我瞎吹。

开发这么久，多多少少也有了解过适配器模式。我还是一如既往的建议学习设计模式，不能光靠看别人的文章，得靠自己的积累和理解源码的做法来得更切实际。

2. 浅谈适配器

我们都知道，适配器模式是一种结构型模式，结构型模式我的理解都有一个特点，简单来说就是封装了一些操作，就是隐藏细节嘛，比如说代理就是隐藏了通过代理调用实体的细节。

我还是觉得我们要重头去思考它是怎样的一个思路。如果你去查“适配器模式”，相信你看到很多关于插头的说法，而且你会觉得这东西很简单，但好像看完之后又感觉学了个寂寞。

还是得从源码中去理解。先看看源码中最经典的适配器模式的使用地方，没错，RecyclerView的Adapter。但是它又不仅仅只使用Adapter模式，如果拿它的源码来做分析反而会有些绕。但是我们可以进行抽象。想想Adapter其实主要的流程就是输入数据然后输出View给RecyclerView

然后又可以大胆的去思考一下，如果不定义一个Adapter，没有ViewHolder，要怎么实现这个效果？写一个循环，然后在循环里面做一些逻辑判断，然后创建对应的子View，添加到父View中 ，大概会这样做吧。那其实Adapter就帮我们做了这一步，并且还做了很多比较经典的优化操作，其实大概就是这样。

然后从这样的模型中，我大概是能看出了一些东西，比如使用Adapter是为了输入一些东西，也可以说是为了让它封装一些逻辑，然后达到某些目的，如果用抽象的眼光去看，我不care你封装的什么东西，我只要你达到我的目的（输出我的东西），RecyclerView的adapter就是输出View。这是其一，另外，在这个模型中我有一个使用者去使用这个Adaper，这个Apdater在这里不是一个概念，而是一个对象，我这个使用者通过Adaper这个对象给它一些输入，以此来实现我的某些目标

ok，结合Adapter模式的结构图看看（随便从网上找一张图）

可以看到这个模型中有个Client，有个Tagrget，有个Adapter。拿RecyclerView的Adapter来说，Client是RecyclerView （当然具体的addView操作是在LayoutManager中，这里是抽象去看），Adapter就是RecyclerView.Adapter，而Tagrget抽象去看就是对view的操作。

3. 天马行空的使用

首先一般使用官方的RecyclerView啊这些，都会提供自己的Adapter，但是会让人会容易觉得Adapter就是在复用View的情况下使用。而我的理解是，RecyclerView的复用是ViewHolder的思想，不是Adapter的思想，比如早期的ListView也有Adapter啊，当时出RecyclerView之前也没有说用到ViewHolder的这种做法（这是很多年前的事），我说这个是想要表达不要把Adapter和RecyclerView绑一起，这样会让思维受到局限。

对我而言，Adapter在RecyclerView中的作用是 “Data To View” ,适配数据而产出对应的View。

那我可以把Apdater的作用理解成“Object To Object” ，对于我来说，Object它可以是Data，可以是View，甚至可以是业务逻辑。

所以当我跳出RecyclerView这种传统的 “Data To View” 的思维模式之后，Adapter适配器模式可以做到的场景就很多，正如上面我理解的，Adapter简单来说就是 “Data To View” ，那我可以用适配器模式去做 “Data To Data” ,可以去做 “View To Data” ，可以去做 “Business To Business” , “Business To View” 等等，实现多种效果。

假设我这里做个Data To Data的场景 （强行举的例子可能不是很好）

我请求后台拿到个人的基本信息数据

data class PeopleInfo(

    var name: String?,

    var sex: Int?,

    ......

)

然后通过个人的ID，再请求服务端另外一个接口拿到成绩数据

data class ScoreInfo(

    var language : Int,

    var math : Int,

    ......

)

然后我有个数据竞赛的报名表对象。

data class MathCompetition(

    var math : Int,

    var name : String

)

然后一般我们使用到的时候就会这样赋值，假设这段代码在一个Competition类中进行

val people = getPeopleInfo()

val score = getScoreInfo()

val mathTable = MathCompetition(

    score.math?,

    people.name?,

    ......

)

就是深拷贝的一种赋值，我相信很多人的代码里面肯定会有

两个对象 A 和 B

A.1 = B.1

A.2 = B.2

A.3 = B.3

......

这样的代码，然后对象的熟悉多的话这个代码就会写得很长。当然这不会造成什么大问题，但是你看着看着，总觉得缺少一些美感，但是好像这玩意没封装不起来这种感觉。

如果用适配器来做的话，首先明确要做的流程是从Competition这个类中，将所有数据整合成MathCompetition对象，目标就是输出MathCompetition对象。那从适配器模式的模型上去看，client就是Competition，是它的需求，Taget就是getMathCompetition，输出mathTable，然后我们可以写一个Adapter。

class McAdapter {



    var mathCompetition : MathCompetition? = null



    init {

        // 给默认值

        mathCompetition = MathCompetition(0, "name", ......)

    }



    fun setData(people : PeopleInfo? = null, score : ScoreInfo? = null){

        people?.let {

            mathCompetition?.name = it.name

            ......

        }



        score?.let {

            mathCompetition?.math = it.math

            ......

        }

    }

    

    fun getData() : MathCompetition?{

        return mathCompetition

    }



}

然后在Competition中就不需要直接引用MathCompetition，而是设置个setAdapter方法，然后需要拿数据时再调用adapter的getData()方法，这样就恰到好处，不会把这些深拷贝方式的赋值代码搞得到处都是。 这个Demo看着好像没什么，但是真碰到了N合1这样的数据场景的时候，使用Adapter显然会更安全。

我再简单举一个Business To View的例子吧。假设你的app中有很几套EmptyView，比如你有嵌入到页面的EmptyView，也有做弹窗类型的EmptyView，我们一般的做法就是对应的页面的xml文件中直接写EmptyView，那这些EmptyView的代码就会很分散是吧。OK，你也想整合起来，所以你会写个EmptyHelper，大概是这个意思，用单例写一个管理EmptyView的类，然后里面统一封装对EmptyView的操作，一般都会这样写。 其实如果你让我来做，我可能就会用适配器模式去实现。 ，当然也有其他办法能很好的管理，这具体的得看心情。

写一个Adapter，我这里写一段伪代码，应该比较容易能看懂

class EmptyAdapter() {

    // 这样语法要伴生，懒得写了，看得懂就行

    const val STATUS_NORMAL = 0

    const val STATUS_LOADING = 1

    const val STATUS_ERROR = 2



    private var type: Int = 0

    var parentView: ViewGroup? = null

    private var mEmptyView: BaseEmptyView? = null

    private var emptyStatus = 0 // 有个状态，0是不显示，1是显示加载中，2是加载失败......



    init {

        createEmptyView()

    }



    private fun createEmptyView() {

        // 也可以判断是否有parentView决定使用哪个EmptyView等逻辑

        mEmptyView = when (type) {

            0 -> AEmptyView

            1 -> BEmptyView

            2 -> CEmptyView

            else -> {

                AEmptyView

            }

        }

    }



    fun setData(status: Int) {

        when (status) {

            0 -> parentView?.removeView(mEmptyView)

            1 -> mEmptyView?.showLoading()

            2 -> mEmptyView?.showError()

        }

    }



    fun updateType(type: Int) {

        setData(0)

        this.type = type

        createEmptyView()

    }

}

然后在具体的Activity调用的时候，可以

val emptyAdapter = EmptyAdapter(getContentView())

// 然后在每次要loading的时候去设置adapter的的状态

emptyAdapter.setData(EmptyAdapter.STATUS_LOADING)

emptyAdapter.setData(EmptyAdapter.STATUS_NORMAL)

emptyAdapter.setData(EmptyAdapter.STATUS_ERROR)

可以看出这样做就有几个好处，其一就是不用每个xml都写EmptyView，然后也能做到统一的管理，和一些人写的Helper这种的效果类似，最后调用的方法也很简单，你只需要创建一个Adaper，然后调用它的setData就行，我们的RecyclerView也是这样的，在外层去创建然后调用Adapter就行。

4. 总结

写这篇文章主要是为了水，啊不对，是为了想说明几个问题：

（1）开发时要善于跳出一些限制去思考，比如RecyclerView你可能觉得适配器模式就和它绑定了，就和View绑定了，有View的地方才能使用适配器模式，至少我觉得不是这样。

（2）学习设计模式，只去看一些介绍是很难理解的，当然要知道它的一个大致的思想，然后要灵活运用到开发中，这样学它才有用。

（3）我对适配器模式的理解就是 Object To Object，我可以去写ViewAdapter，可以去写DataAdapter，也可以去写BusinessAadpter，可以用这个模式去适配不同的场景，利用这个思想来使代码更加合理。

当然最后还是要强调一下，我不敢保证我说的就是对的，我肯定不是权威的。但至少我使用这招之后的的新代码效果要比一些旧代码更容

效果

类似毛玻璃，或者马赛克的效果。我们可以用它来提升app背景的整体质感，或者给关键信息打码。

源代码

import 'dart:ui';



import 'package:flutter/material.dart';



void main() {

  runApp(const MyApp());

}



class MyApp extends StatelessWidget {

  const MyApp({super.key});



  // This widget is the root of your application.

  @override

  Widget build(BuildContext context) {

    return MaterialApp(

      title: 'Flutter Demo',

      theme: ThemeData(

        primarySwatch: Colors.blue,

      ),

      home: const MyHomePage(title: 'Flutter Demo Home Page'),

    );

  }

}



class MyHomePage extends StatefulWidget {

  const MyHomePage({super.key, required this.title});



  final String title;



  @override

  State<MyHomePage> createState() => _MyHomePageState();

}



class _MyHomePageState extends State<MyHomePage> {

  // 高斯模糊的第一种写法 ImageFiltered 包裹要模糊的组件



  /// 将子组件进行高斯模糊

  /// [child] 要模糊的子组件

  Widget _imageFilteredWidget1({required Widget child, double sigmaValue = 1}) {

    return ImageFiltered(

      imageFilter: ImageFilter.blur(sigmaX: sigmaValue, sigmaY: sigmaValue),

      child: child,

    );

  }



  /// 使用第一种模糊方式的案例

  Widget _demo1() {

    return Container(

      padding: const EdgeInsets.all(50),

      color: Colors.blue.shade100,

      width: double.infinity,

      child: Column(

        children: [

          _imageFilteredWidget1(

            child: SizedBox(

              width: 150,

              child: Image.asset(

                "assets/images/bz1.jpg",

                fit: BoxFit.fitHeight,

              ),

            ),

          ),

          const SizedBox(height: 100),

          _imageFilteredWidget1(

              child: const Text(

                "测试高斯模糊",

                style: TextStyle(fontSize: 30, color: Colors.blueAccent),

              ),

              sigmaValue: 2)

        ],

      ),

    );

  }



  /// 利用  BackdropFilter 做高斯模糊

  _backdropFilterWidget2({

    required Widget child,

    double sigmaValueX = 1,

    double sigmaValueY = 1,

  }) {

    return ClipRect(

      child: BackdropFilter(

        filter: ImageFilter.blur(sigmaX: sigmaValueX, sigmaY: sigmaValueY),

        child: child,

      ),

    );

  }



  ///

  Widget _demo2() {

    return SizedBox(

      width: double.infinity,

      height: double.infinity,

      child: Stack(

        alignment: Alignment.center,

        children: [

          Positioned.fill(

            child: Image.asset(

              "assets/images/bz1.jpg",

              fit: BoxFit.fill,

            ),

          ),

          Positioned(

            child: _backdropFilterWidget2(

                sigmaValueX: _sigmaValueX,

                sigmaValueY: _sigmaValueY,

                child: Container(

                  width: MediaQuery.of(context).size.width - 100,

                  height: MediaQuery.of(context).size.height / 2,

                  alignment: Alignment.center,

                  decoration: BoxDecoration(

                    borderRadius: BorderRadius.circular(20),

                    color: const Color(0x90ffffff),

                  ),

                  child: const Text(

                    "高斯模糊",

                    style: TextStyle(fontSize: 30, color: Colors.white),

                  ),

                )),

            top: 20,

          ),

          _slider(

            bottomMargin: 200,

            themeColors: Colors.yellow,

            title: '横向模糊度',

            valueAttr: _sigmaValueX,

            onChange: (double value) {

              setState(() {

                _sigmaValueX = value;

              });

            },

          ),

          _slider(

            bottomMargin: 160,

            themeColors: Colors.blue,

            title: '纵向模糊度',

            valueAttr: _sigmaValueY,

            onChange: (double value) {

              setState(() {

                _sigmaValueY = value;

              });

            },

          ),

          _slider(

            bottomMargin: 120,

            themeColors: Colors.green,

            title: '同时调整：',

            valueAttr: _sigmaValue,

            onChange: (double value) {

              setState(() {

                _sigmaValue = value;

                _sigmaValueX = value;

                _sigmaValueY = value;

              });

            },

          ),

        ],

      ),

    );

  }



  Widget _slider({

    required String title,

    required double bottomMargin,

    required Color themeColors,

    required double valueAttr,

    required ValueChanged<double>? onChange,

  }) {

    return Positioned(

      bottom: bottomMargin,

      child: Row(

        children: [

          Text(title, style: TextStyle(color: themeColors, fontSize: 18)),

          SliderTheme(

            data: SliderThemeData(

              trackHeight: 20,

              activeTrackColor: themeColors.withOpacity(.7),

              thumbColor: themeColors,

              inactiveTrackColor: themeColors.withOpacity(.4)

            ),

            child: SizedBox(

              width: MediaQuery.of(context).size.width * 0.5,

              child: Slider(

                value: valueAttr,

                min: 0,

                max: 10,

                onChanged: onChange,

              ),

            ),

          ),

          SizedBox(

            width: 50,

            child: Text('${valueAttr.round()}',

                style: TextStyle(color: themeColors, fontSize: 18)),

          ),

        ],

      ),

    );

  }



  double _sigmaValueX = 10;

  double _sigmaValueY = 10;



  double _sigmaValue = 10;



  @override

  Widget build(BuildContext context) {

    return Scaffold(

      appBar: AppBar(

        title: Text(widget.title),

      ),

      body: _demo2(),

    );

  }

}

实现原理

实现高斯模糊，在flutter中有两种方式：

ImageFiltered

它可以对其包裹的子组件施加高斯模糊，需要传入 ImageFilter 控制模糊程度，分为X Y两个方向的模糊，实际上就是对图片进行拉伸，数字越大，模糊效果越大。

/// 将子组件进行高斯模糊

/// [child] 要模糊的子组件

Widget _imageFilteredWidget1({required Widget child, double sigmaValue = 1}) {

  return ImageFiltered(

    imageFilter: ImageFilter.blur(sigmaX: sigmaValue, sigmaY: sigmaValue),

    child: child,

  );

}

BackDropFilter

同样需要一个 ImageFilter参数控制模糊度，与 ImageFilter的区别是，它会对它覆盖的组件整体模糊。
所以如果我们需要对指定的子组件进行模糊的话，需要再包裹一个ClipRect裁切。

/// 利用  BackdropFilter 做高斯模糊

_backdropFilterWidget2({required Widget child, double sigmaValue = 1}) {

  return ClipRect(

    child: BackdropFilter(

      filter: ImageFilter.blur(sigmaY: sigmaValue, sigmaX: sigmaValue),

      child: child,

    ),

  );

}

由于 BackdropFilter 会对其子组件进行图形处理，所以其子组件可能会变得更加消耗性能。因此，需要谨慎使用 BackdropFilter 组件。

• 原文: medium.com/proandroidd…


• 译者：程序员 DHL


• 本文已收录于仓库 Technical-Article-Translation

这篇文章，主要分享在 Android 14 以上新增的权限 READ_MEDIA_VISUAL_USER_SELECTED，该权限允许用户仅授予对选定媒体的访问权限（Photos / Videos)），而不是访问整个媒体库。

新的权限弹窗

当你的 App 运行在 Andrid 14 以上的设备时，如果请求访问照片，会出现以下对话框，你将看到新的选项。

受影响的行为

当我们在项目中声明新的权限 READ_MEDIA_VISUAL_USER_SELECTED ，并且用户选择 Select photos and videos(Select photos or Select videos) ：

• 
  

  READ_MEDIA_IMAGES 和 READ_MEDIA_VIDEO 权限都会被拒绝

  
  


• 
  

  READ_MEDIA_VISUAL_USER_SELECTED 权限被授予时，将会被允许临时访问用户的照片和视频

  
  


• 
  

  如果我们需要访问其他照片和视频，我们需要同时申请 READ_MEDIA_IMAGES 或者 READ_MEDIA_VIDEO 权限

  
  

如何在项目中使用新的权限

• 在 AndroidManifest.xml 文件中添加下面的权限

<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />



// new permisison

<uses-permission android:name="android.permission.READ_MEDIA_VISUAL_USER_SELECTED" />

• 使用 ActivityResultContract 请求新的权限

val permissionLauncher =

    rememberLauncherForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { mapResults ->

        mapResults.forEach {

            Log.d(TAG, "Permission: ${it.key} Status: ${it.value}")

        }

        // check if any of the requested permissions is granted or not

        if (mapResults.values.any { it }) {

            // query the content resolver

            queryContentResolver(context) { listOfImages ->

                imageDataModelList = listOfImages

            }

        }

    }

为什么要使用 RequestMultiplePermissions，因为我们需要同时请求 READ_MEDIA_IMAGES , READ_MEDIA_VIDEO 权限

• 启动权限申请流程

OutlinedButton(onClick = {

    permissionLauncher.launch(arrayOf(READ_MEDIA_IMAGES, READ_MEDIA_VISUAL_USER_SELECTED))

}) {

    Text("Allow to read all or select images")

}

关于 Android 12 、 Android 13 、Android 14 功能和权限的变更，点击下方链接前往查看：

• 
  

  快速适配 Android 14

  
  


• 
  

  Android 13这些权限废弃，你的应用受影响了吗？

  
  


• 
  

  Android 12 已来，你的 App 崩溃了吗？

  
  

最后我们看一下运行效果

全文到这里就结束了，感谢你的阅读，坚持原创不易，欢迎在看、点赞、分享给身边的小伙伴，我会持续分享原创干货！！！

我开了一个云同步编译工具（SyncKit），主要用于本地写代码，同步到远程设备，在远程设备上进行编译，最后将编译的结果同步到本地，代码已经上传到 Github，欢迎前往仓库 hi-dhl/SyncKit 查看。

• 仓库 SyncKit：https://github.com/hi-dhl/SyncKit


• 下载地址：https://github.com/hi-dhl/SyncKit/releases

Hi 大家好，我是 DHL，就职于美团、快手、小米。公众号：ByteCode ，分享有用、有趣的硬核原创内容，Kotlin、Jetpack、性能优化、系统源码、算法及数据结构、动画、大厂面经，真诚推荐你关注我。

• 公众号：ByteCode


• 哔哩哔哩： space.bilibili.com/498153238


• 掘金： juejin.im/user/259450…


• 博客： hi-dhl.com


• Github： github.com/hi-dhl

最新文章

• 国外大厂面试题， 7 个 Android Lifecycle 重要的知识点


• Android 13这些权限废弃，你的应用受影响了吗？


• Android 12 已来，你的 App 崩溃了吗？


• Android 利器，我开发了云同步编译工具


• Twitter 上有趣的代码


• 谁动了我的内存，揭秘 OOM 崩溃下降 90% 的秘密


• 反射技巧让你的性能提升 N 倍


• 90%人不懂的泛型局限性，泛型擦除，星投影


• 揭秘反射真的很耗时吗，射 10 万次耗时多久


• Google 宣布废弃 LiveData.observe 方法


• 影响性能的 Kotlin 代码（一）


• 揭秘 Kotlin 中的 == 和 ===

开源新项目

• 
  

  云同步编译工具（SyncKit），本地写代码，远程编译，欢迎前去查看 SyncKit

  
  


• 
  

  KtKit 小巧而实用，用 Kotlin 语言编写的工具库，欢迎前去查看 KtKit

  
  


• 
  

  最全、最新的 AndroidX Jetpack 相关组件的实战项目以及相关组件原理分析文章，正在逐渐增加 Jetpack 新成员，仓库持续更新，欢迎前去查看 AndroidX-Jetpack-Practice

  
  


• 
  

  LeetCode / 剑指 offer，包含多种解题思路、时间复杂度、空间复杂度分析，在线阅读

  
  

欢迎关 Android茶话会 在技术学习、个人成长的道路上，让我们一起前进！

一、什么是SysTrace？

在日常开发中有时候遇到棘手的性能问题就需要使用这个工具，Systrace 是 「Android 4.1」 中新增的性能数据采样和分析工具。它可帮助开发者收集 Android 关键子系统
（如 SurfaceFlinger/SystemServer/Kernel/Input/Display 等 Framework 部分关键模块、服务，View」系统等 的运行信息，从而帮助开发者更直观的「分析系统瓶颈，改进性能」。

二、如何使用SysTrace？

2.1 采集trace

首先我们需要了解Trace的采集主要涉及几部分：采集方式、自定义trace阶段、Release包抓取Trace和系统Trace类同异步调用的差异；

命令行采集：

• 设备要求**「Android 4.3 (API level 18)及以上」**


• 命令如下：python systrace.py [options][「categories」]，示例如下：

python /Users/yangzhiyong/Library/Android/sdk/platform-tools/systrace/systrace.py -t 10 -o trace.html gfx input view sched freq wm am hwui workq res dalvik sync disk load perf hal rs idle mmc -a com.ss.android.lark.debug



# -o : 指示输出文件的路径和名字

# -t : 抓取时间(最新版本可以不用指定, 按 Enter 即可结束)，单位为秒

# -b : 指定 buffer 大小 (一般情况下,默认的 Buffer 是够用的,如果你要抓很长的 Trae , 那么建议调大 Buffer )

# -a : 指定 app 包名 (如果要 Debug 自定义的 Trace 点, 记得要加这个)

• 
  

  查看支持的categories

  
  
  
  
  • adb shell atrace --list_categories
  
  
  • python systrace.py -l
  
  
  
  

// 粗体部分是常用的categories;

         gfx - Graphics

       input - Input

        view - View System

     webview - WebView

          wm - Window Manager

          am - Activity Manager

          sm - Sync Manager

       audio - Audio

       video - Video

      camera - Camera

         hal - Hardware Modules

         res - Resource Loading

      dalvik - Dalvik VM

          rs - RenderScript

      bionic - Bionic C Library

       power - Power Management

          pm - Package Manager

          ss - System Server

    database - Database

     network - Network

         adb - ADB

    vibrator - Vibrator

        aidl - AIDL calls

         pdx - PDX services

       sched - CPU Scheduling

        freq - CPU Frequency

        idle - CPU Idle

        disk - Disk I/O

        sync - Synchronization

  memreclaim - Kernel Memory Reclaim

  binder_driver - Binder Kernel driver

  binder_lock - Binder global lock trace

系统自带工具：

• 
  

  设备要求**「Android 9(API level 28)及其以上」**

  
  


• 
  

  开发者模式->系统跟踪

  
  


• 
  

  trace导出：

  
  
  
  
  • 通知栏分享；
  
  
  • adb pull /data/local/traces/ .
  
  
  • systrace --from-file .ctrace .perfetto-trace 转换成html
  
  
  
  

网页版采集分析工具：💻

• 设备要求**「Android 10(API level 29)及其以上；」**


• Perfetto UI

❝

除此之外还有一些常用的技巧

❞

1. 自定义TAG

具体使用可参考：developer.android.com/topic/perfo…

• 
  

  「定义」

  
  
  
  
  • 在事件开始调用Trace.beginSection(event)；
  
  
  • 在事件结束调用Trace.endSection()，需成对调用；
  
  
  
  


• 
  

  「使用」 添加了自定义TAG后，需要-a指定包名参数，才可以采集到自定义的trace信息；

  
  

2. Release包抓取trace

反射调用setAppTracingAllowed即可：

try {

    Class threadClazz = Class.forName("android.os.Trace");

    Method setAppTracingAllowed = threadClazz.getDeclaredMethod("setAppTracingAllowed", boolean.class);

    setAppTracingAllowed.invoke(null, true);

} catch (Exception e) {

    e.printStackTrace();

}

3. 同异步trace的差异

2.2 分析

拿到这些trace 我们如何分析也是一个重要的部分

2.2.1 Trace文件打开

首先是打开这个文件

1. chrome://tracing：推荐：不过近期版本该工具对trace中线程、进程名解析不出来，不利于查看；


2. ui.perfetto.dev/#!/： 推荐，不过新版分析工具不支持VSync的高亮；


3. perfetto.bytedance.net/#!/viewer： 不推荐，仅支持单进程查看，对于涉及系统调用的分析不方便；

较早版本sysTrace生成的html文件浏览器即可打开，但最近版本已无法正常打开，需要通过chrome工具手动加载；

2.2.2 面板区域说明

image.png

1. 用户屏幕交互


2. CPU 使用率


3. CPU各核心的运行情况


4. 进程信息


5. 进程变量/进程


6. 选中区段的详细信息


7. 鼠标操作选项，可通过1-4快速切换


8. 进程过滤


9. VSync高亮配置

2.2.3 常用快捷键

比较常用的快捷键是W S A D M V；

• W : 放大 Systrace，放大可以更好地看清局部细节


• S : 缩小 Systrace，缩小以查看整体


• A : 左移


• D : 右移


• M : 高亮选中当前鼠标点击的段（这个比较常用，可以快速标识出这个方法的左右边界和执行时间，方便上下查看）


• V : 高亮VSync的时机，方便分析掉帧的原因；

image.png

2.2.4 线程状态

a) 线程状态

「线程状态」	「Systrace中的显示」	「说明」
绿色 : 运行中（Running）		我们经常会查看 Running 状态的线程，查看其运行的时间，与竞品做对比，分析快或者慢的原因
蓝色 : 可运行（Runnable）		Runnable 状态的线程状态持续时间越长，则表示 cpu 的调度越忙，没有及时处理到这个任务
白色 : 休眠中（Sleep）		一般是在等事件驱动
橘色 : 不可中断的睡眠态 IO Block（Uninterruptible Sleep WakeKill）		一般是标示 IO 操作慢，如果有大量的橘色不可中断的睡眠态出现，那么一般是由于进入了低内存状态
紫色 : 不可中断的睡眠态（Uninterruptible Sleep）		一般是陷入了内核态，有些情况下是正常的，有些情况下是不正常的，需要按照具体的情况去分析

b) 线程唤醒

一个任务在进入 Running 状态之前，会先进入 Runnable 状态进行等待，而 Systrace 会把这个状态也标示在 Systrace 上； stateWhenDescheduled定义：chromium.googlesource.com/external/tr…

c) 线程参数说明

• Wall Duration：函数执行的总耗时


• CPU Duration：在 CPU 上执行的耗时


• Self Time：自身执行的总耗时，不包括子方法


• CPU Self Time：自身在 CPU 上执行的耗时，不包括子方法

d) 函数调用虚实区别

如下图，我们看到标识setUpHWComposer调用的紫色条并不是实心的，实心的部分代表CPU Duration相对于Wall Duration的占比：

2.2.5 CPU信息

image.png

1. C-State

为了在CPU空闲的时候降低功耗，CPU可以被命令进入low-power模式。每个CPU都有几种power模式，这些模式被统称为C-states或者C-modes； C-States从C0开始，C0是CPU的正常工作模式，CPU处于100%运行状态。C后的数越高，CPU睡眠得越深，CPU的功耗被降低得越多，同时需要更多的时间回到C0模式。

1. Clock Frequency：CPU当前运行频率；


2. Clock Frequency Limits：CPU最大最小频率，通过该参数可以判断CPU核心差异，如大中小核

2.2.6 常见系统进程、线程

• 
  

  进程

  
  
  
  
  • 
    

    system_server

    
    
    
    
    • AMS
    
    
    • WMS
    
    
    • SurfaceFlinger
    
    
    
    
  
  
  
  


• 
  

  线程

  
  
  
  
  • UI Thread //主线程
  
  
  • Render Thread //渲染线程
  
  
  • Binder Thread //跨进程调用线程
  
  
  
  

2.2.7 常见问题

a) 「锁等待」

「monitor contention」 with owner 「caton_dump_stack (11056)」 waiters=0 blocking from 「boolean android.os.MessageQueue.enqueueMessage(android.os.Message, long)(MessageQueue.java:544)」 结合代码看，这段信息的意思是，「caton_dump_stack」线程（线程ID是11056）作为「owner」持有了主线程消息队列对象锁，「waiters」表示等待在该对象锁上的其他线程数（不包括当前线程），所以总的有1个线程等待对象锁释放，当前线程等待的位置是「enqueueMessage调用处」。

b) 「SurfaceFlinger绘制」

SurfaceFlinger主要是收集各个UI渲染层的数据合成发送给Hardware Composer；一般应用的渲染层包括状态栏、应用页面、导航栏，每个部分都是单独渲染生成Buffer的，基本步骤如下：

1. 应用收到VSYNC-app信号后，在**「UI Thread」完成数据计算；准备好后，将数据发送到「RenderThread」**；


2. 应用在**「RenderThread」完成数据渲染后，将数据填充到「SurfaceFlinger」**的对应页面BufferQueue中；


3. 在**「SurfaceFlinger」收到VSYNC-sf信号后，「SurfaceFlinger」** 会遍历它的层列表的BufferQueue，以寻找新的缓冲区。如果找到新的缓冲区，它会获取该缓冲区；否则，它会继续使用以前获取的缓冲区。「SurfaceFlinger」 必须始终显示内容，因此它会保留一个缓冲区。如果在某个层上没有提交缓冲区，则该层会被忽略；


4. **「SurfaceFlinger」**向 「HWC」 提供一个完整的层列表，并询问“您希望如何处理这些层？”


5. 「HWC」 的响应方式是将每个层标记为叠加层或 GLES 合成；


6. 「SurfaceFlinger」 会处理所有 GLES 合成，将输出缓冲区传送到 「HWC」，并让 「HWC」 处理其余部分；

image.png

c) 「掉帧」

上一部分描述了SurfaceFlinger合成每帧数据的过程，在上述过程中，如果**「UI Thread」计算不及时，或者「RenderThread」渲染不及时，或者「BufferQueue」**中可用Buffer不足导致在下一次VSYNC信号来临之前，没有准备好需要显示的帧的数据，就会出现丢帧，Systrace 报告列出了渲染界面帧的每个进程，并指明了沿时间轴渲染的每个帧。在 16.6 毫秒内渲染的必须保持每秒 60 帧稳定帧速率的帧会以绿色圆圈表示。渲染时间超过 16.6 毫秒的帧会以黄色或红色帧圆圈表示：

1. 绿色：未丢帧；


2. 棕色：轻微丢帧，丢1帧 ；


3. 红色：严重丢帧，丢大于1帧；

通过Systrace右上角的View Options > Highlight VSync，我们可以高亮VSYNC信号到来的时刻，需要注意的是，高亮的VSYNC主要是VSYNC-app信号（可在SurfaceFlinger进程中查看），且灰白相间的位置是VSYNC信号到来的时刻。 如下图，显示了丢1帧的情况，第二个VSYNC到来时，主线程仍未完成显示帧数据的计算，所以出现丢帧的问题。

三、常见trace工具对比

其实我们分析trace不光只有系统这一种方法，下图做个简单的总结

「instrument」：获取一段时间内所有函数的调用过程，可以通过分析这段时间内的函数调用流程，再进一步分析待优化的点。

「sample」：有选择性或者采用抽样的方式观察某些函数调用过程，可以通过这些有限的信息推测出流程中的可疑点，然后再继续细化分析。

1.前期

去年公司开展了一个新的项目，是一个运行在机顶盒上的App。项目经理把整个部门的几个重要成员叫到会议室开了场研讨，讨论了关于整个项目的详细情况，但是公司现有做安卓哥们都没有开发过Tv上的项目，所以当时都没有人主动想要负责这个项目的开发。可能在会上我问的问题比较多引起了注意。然后就毫无意外的把这个项目客户端开发硬塞了给我负责。我也是醉了。。。

2.准备

在美工(设计师)正画高保真图的这段时间我也开始了研究关于在机顶盒上的一些相关技术储备,也试的写了一些Demo出来。感觉还是阔以拿捏的。但是当前我等到高保真出来的时侯大家一起探讨机顶盒上的一些交互时，我发现我的的相关技术储备还是有点欠缺，没办法，只能先跟着图开始做着。

3.开干

没过这方面开发的哥们可能不知道。开发一个几个按钮外加一个列表的页面如果是手机端的我不用半小时就写完了，但是我在开发TV上的类似的页面时我足足做一了一个多星期。而且产经理看了还是不满意，说这不行，说那焦点有问题。还经常用几个主流的Tv应用在跟我展示说别人也是这么做，也是那么做。

4.遇到问题

就拿一个控件获取焦点时的问题来说吧，别人主流的TV应用里的控件获取焦点显示焦框时，控件里的内容是不是被挤压的。而且有的焦框带有阴影，阴影还会复盖在别的控件之上，也就是说焦点框不占据控件的大小，如果有传统的方式给控件设置src或是background属性来显示焦点框的话是会占据控件原本的大小的。

如图下面三个正方形的控件的宽高都是100dp的，第1个和第2个是可以获取焦点的，第3个是用来作为对比大小的。给第1，2个控件添加了一个selector类型的drawable,作为当控件获取焦点时的的焦点框，很明显可以看到，当获取焦点时第2个控件显示了一个红色的焦点框，但是焦点框却挤压了控件的内容，也就是说焦点框显示在控件100dp之内。像这种方式是有问题的。我们要的是焦点框要显示的控件之外的区域这样就会不占用控件的大小。

5寻找解决方案

顺着这个问题在各大社区寻找解决方案，找到了一种可以把焦点框显示在控件之外的方式。核心就是默认情况下Android的组件可以绘制超出它原本大小之外的区域，但是默认只会显示控件大小之内的区域，如果我把给这个控件的父控件的两个属性设置为false那么就可以进显示控件之外的内容了。而这两个属性就是：

android:clipChildren="false"

android:clipToPadding="false"

接着就要自定义一个控件，这里以ImageView为例，首页要拿到获取焦点框图片的边框大小：

int resourceId = ta.getResourceId(R.styleable.EBoxImageView_ebox_iv_focused_border,

        -1);

Rect mFocusedDrawable.getPadding(mFocusDrawableRect);

然后计算出焦点框加点组件之后的整个显示的区域的大小，

private void mergeRect(Rect layoutRect, Rect drawablePaddingRect) {

    layoutRect.left -= drawablePaddingRect.left;

    layoutRect.right += drawablePaddingRect.right;

    layoutRect.top -= drawablePaddingRect.top;

    layoutRect.bottom += drawablePaddingRect.bottom;

}

最后再根据这个大小区域绘制焦点框，而绘制内容这一块直接调用super.onDraw(canvas);就可以了。

下面是一个完整的代码：

public class MyImageView extends AppCompatImageView {

    private static final String TAG = "EBoxImageView";



    private static final Rect mLayoutRect = new Rect();

    private static final Rect mFocusDrawableRect = new Rect();



    private final static Drawable DEFAULT_FOCUSED_DRAWABLE = ResourceUtils.getDrawable(R.drawable.drawable_focused_border);

    private Drawable mFocusedDrawable = DEFAULT_FOCUSED_DRAWABLE;



    public MyImageView(Context context) {

        this(context, null);

    }



    public MyImageView(Context context, @Nullable AttributeSet attrs) {

        this(context, attrs, 0);

    }



    public MyImageView(Context context, @Nullable AttributeSet attrs, int defStyleAttr) {

        super(context, attrs, defStyleAttr);

        init(attrs);

    }



    private void init(AttributeSet attributeSet) {

        setScaleType(ScaleType.FIT_XY);



        TypedArray ta = getContext().obtainStyledAttributes(attributeSet, R.styleable.MyImageView);

        boolean selectorMode = ta.getBoolean(R.styleable.MyImageView_ebox_iv_selected_mode,false);

        int resourceId = ta.getResourceId(R.styleable.MyImageView_ebox_iv_focused_border,

                -1);

        ta.recycle();



        if(selectorMode){

            setFocusable(false);

        }else {

            setFocusable(true);

        }



        if (resourceId != -1) {

            mFocusedDrawable = ResourceUtils.getDrawable(resourceId);

        }

        mFocusedDrawable.getPadding(mFocusDrawableRect);

    }





    @Override

    public void invalidateDrawable(@NonNull Drawable dr) {

        super.invalidateDrawable(dr);

        invalidate();

    }



    @CallSuper

    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);

        if (isFocused()||isSelected()) {

            getDrawingRect(mLayoutRect);



            mergeRect(mLayoutRect, mFocusDrawableRect);

            mFocusedDrawable.setBounds(mLayoutRect);

            canvas.save();

            mFocusedDrawable.draw(canvas);

            canvas.restore();

        }



    }



    /**

     * 合并drawable的padding到borderRect里去

     *

     * @param layoutRect          当前布局的Rect

     * @param drawablePaddingRect borderDrawable的Rect

     */

    private void mergeRect(Rect layoutRect, Rect drawablePaddingRect) {

        layoutRect.left -= drawablePaddingRect.left;

        layoutRect.right += drawablePaddingRect.right;

        layoutRect.top -= drawablePaddingRect.top;

        layoutRect.bottom += drawablePaddingRect.bottom;

    }



    /**

     * 指定一个焦点框图片资源,如果不调用此方法默认用,R.drawable.drawable_recommend_focused

     *

     * @param focusDrawableRes

     */

    public void setFocusDrawable(@DrawableRes int focusDrawableRes) {

        mFocusedDrawable = ResourceUtils.getDrawable(focusDrawableRes);

        mFocusedDrawable.getPadding(mFocusDrawableRect);

    }

总结

以上就是在开发AndroidTV、机顶盒中遇到的焦点框问题的解决方案，后来在CS某N社区中找到一套关于AndroidTV项目开发实战的视频教程看了一下还不错，在其它地方也找不更好的资源。再加上项目实现太赶没有那么多的试错时间成本，然后就报名买了那教程。后来边看边开发，用着这套视频的作者提供的一个UI库，来开发我的项目确定方便快速了很多。现在整套视频教程还没看完，一边学习一边写公司的项目和写博客。