起因：

为什么想写这样一篇文章呢，最开始是我的一个朋友和我说想换一个QQ头像但是苦于里面一个常用的模块被下架了在网页中找无关信息太多也显得杂乱，我就萌生了这样一个想法，我是一个程序员这种事能不能通过技术手段实现或者说简化一下说干咱就干

(PS：目前只通过Java实现了爬虫的功能就不多赘述了具体的可以自行百度，python的部分并未能全部实现故只介绍前期的准备流程及部分结果)

需要准备的工具：

Android Studio，adaconda

接下来让我们开始吧！

1. 首先为了能在as中创建python文件我们需要先下载一个插件。在Plugins中搜索Python Community Edition插件下载，安装重启as后就可以在as中创建python文件了，因为Chaquopy没有与这个插件集成，所以.py文件中的代码会报错这是正常现象可以忽略，实际错误请以logcat为准
2. 打开根目录下build.gradle文件引入chaquo模块

buildscript {
    repositories {
        xxx
        maven { url 'https://jitpack.io' }
        //引入chaquo模块
        maven { url "https://chaquo.com/maven" }

    }
    dependencies {
        classpath 'com.android.tools.build:gradle:4.1.3'
         //如果该模块的版本引入不对会引起编译失败
        //如果这里使用的版本是12.0.0及更早的版本会在模块启动时弹出吐司及通知栏显示许可证警告，并且一次只能运行五分钟
        //想要删除限制需要在local.properties文件中引入chaquopy.license = free，12.0.1及之后的版本则为开源的无需额外配置
        classpath "com.chaquo.python:gradle:12.0.1"
    }
}

local.properties文件中内容如下

#使用闭源 Chaquopy 版本（12.0.0 及更早版本）将在启动时显示许可证警告，并且一次只能运行 5 分钟。要删除这些限制，请将以下内容添加到您的项目.
#chaquopy.license=free
#如果使用闭源代码的Chapuopy版本来构建AAR，还需要增添如下标识将AAR内置到应用程序中
#chaquopy.applicationId=your.applicationId

3.接下来让我们打开app目录下的build.gradle文件加入以下引用

plugins {
    //应用模块
    id 'com.android.application'
     id 'com.chaquo.python'
}

android {
        ndk {
            //引入python模块后不支持架构为armeabi的cpu类型
            abiFilters 'armeabi-v7a', 'arm64-v8a', "x86", "x86_64"
            // 还可以添加 'x86', 'x86_64', 'mips', 'mips64'
        }

        python {
            //adaconda中的python编译器，目的引入虚拟环境让python文件在安卓应用中运行,buildPython中的路径需要替换为你自己的安装地址
            buildPython "D:\\ana_2\\python.exe"
            pip {
                //指定库的镜像下载地址：阿里云，清华等
                //options "--index-url", "https://mirrors.aliyun.com/pypi/simple/"
                options "--extra-index-url", "https://pypi.tuna.tsinghua.edu.cn/simple/"
                //install "opencv-python"
                //下载的库，需要什么模块就自行下载下载什么模块，另有些模块不支持引入详情请参阅https://chaquo.com/chaquopy/doc/current/android.html#stdlib-unsupported
                install "requests"
            }
        }
}

4.完成以上配置后就可以开始真正的旅程了

//初始化python模块的相关文件
void initPython() {
    if (!Python.isStarted()) {
        Python.start(new AndroidPlatform(this));
    }
}

//调用python中的内容
void callPythonCode() {
    Python py = Python.getInstance();
    //getModule:py文件名，不用加.py的后缀；callAttr:方法名；如果方法有返回值那pyObject就是返回值
    PyObject pyObject = py.getModule("SearchHeadImg").callAttr("sjs");
    String a = String.valueOf(pyObject);
    Log.e(".py返回值", a);
}

这样我们就可以在app中调用python的相关功能了！

这些内容虽说不多但也是我花了很长时间踩坑一步一步总结出来的，如果有问题或者缺失的内容欢迎大佬指正补充。

接：Android进阶宝典 -- 告别繁琐的AIDL吧，手写IPC通信框架，5行代码实现进程间通信(上)

2.3 内部通讯协议完善

当客户端发起请求，想要执行某个方法的时候，首先服务端会先向Registery中查询注册的服务，从而找到这个要执行的方法，这个流程是在内部完成。

override fun send(request: Request?): Response? {
   //获取服务对象id
   val serviceId = request?.serviceId
   val methodName = request?.methodName
   val params = request?.params
   // 反序列化拿到具体的参数类型
   val neededParams = parseParameters(params)
   val method = Registry.instance.findMethod(serviceId, methodName, neededParams)
   Log.e("TAG", "method $method")
   Log.e("TAG", "neededParams $neededParams")
   when (request?.type) {

       REQUEST_TYPE.GET_INSTANCE.ordinal -> {
           //==========执行静态方法
           try {
               var instance: Any? = null
               instance = if (neededParams == null || neededParams.isEmpty()) {
                   method?.invoke(null)
              } else {
                   method?.invoke(null, neededParams)
              }
               if (instance == null) {
                   return Response("instance == null", -101)
              }
               //存储实例对象
               Registry.instance.setServiceInstance(serviceId ?: "", instance)
               return Response(null, 200)
          } catch (e: Exception) {
               return Response("${e.message}", -102)
          }
      }
       REQUEST_TYPE.INVOKE_METHOD.ordinal -> {
           //==============执行普通方法
           val instance = Registry.instance.getServiceInstance(serviceId)
           if (instance == null) {
               return Response("instance == null ", -103)
          }
           //方法执行返回的结果
           return try {

               val result = if (neededParams == null || neededParams.isEmpty()) {
                   method?.invoke(instance)
              } else {
                   method?.invoke(instance, neededParams)
              }
               Response(gson.toJson(result), 200)
          } catch (e: Exception) {
               Response("${e.message}", -104)
          }

      }
  }

   return null
}

当客户端发起请求时，会将请求的参数封装到Request中，在服务端接收到请求后，就会解析这些参数，变成Method执行时需要传入的参数。

private fun parseParameters(params: Array<Parameters>?): Array<Any?>? {
   if (params == null || params.isEmpty()) {
       return null
  }
   val objects = arrayOfNulls<Any>(params.size)
   params.forEachIndexed { index, parameters ->
       objects[index] =
           gson.fromJson(parameters.value, Class.forName(parameters.className))
  }
   return objects
}

例如用户中心调用setUserInfo方法时，需要传入一个User实体类，如下所示：

UserManager().setUserInfo(User("ming",25))

那么在调用这个方法的时候，首先会把这个实体类转成一个JSON字符串，例如：

{
  "name":"ming",
  "age":25
}

为啥要”多此一举“呢？其实这种处理方式是最快速直接的，转成json字符串之后，能够最大限度地降低数据传输的大小，等到服务端处理这个方法的时候，再把Request中的params反json转成User对象即可。

fun findMethod(serviceId: String?, methodName: String?, neededParams: Array<Any?>?): Method? {
   //获取服务
   val serviceClazz = serviceMaps[serviceId] ?: return null
   //获取方法集合
   val methods = methodsMap[serviceClazz] ?: return null
   return methods[rebuildParamsFunc(methodName, neededParams)]
}

private fun rebuildParamsFunc(methodName: String?, params: Array<Any?>?): String {

   val stringBuffer = StringBuffer()
   stringBuffer.append(methodName).append("(")

   if (params == null || params.isEmpty()) {
       stringBuffer.append(")")
       return stringBuffer.toString()
  }
   stringBuffer.append(params[0]?.javaClass?.name)
   for (index in 1 until params.size) {
       stringBuffer.append(",").append(params[index]?.javaClass?.name)
  }
   stringBuffer.append(")")
   return stringBuffer.toString()
}

那么在查找注册方法的时候就简单多了，直接抽丝剥茧一层一层取到最终的Method。在拿到Method之后，这里是有2种处理方式，一种是通过静态单例的形式拿到实例对象，并保存在服务端；另一种就是执行普通方法，因为在反射的时候需要拿到类的实例对象才能调用，所以才在GET_INSTANCE的时候存一遍。

3 客户端 - connect

在第二节中，我们已经完成了通讯协议的建设，最终一步就是客户端通过绑定服务，向服务端发起通信了。

3.1 bindService

/**
* 绑定服务
*
*/
fun connect(
   context: Context,
   pkgName: String,
   action: String = "",
   service: Class<out IPCService>
) {
   val intent = Intent()
   if (pkgName.isEmpty()) {
       //同app内的不同进程
       intent.setClass(context, service)
  } else {
       //不同APP之间进行通信
       intent.setPackage(pkgName)
       intent.setAction(action)
  }
   //绑定服务
   context.bindService(intent, IpcServiceConnection(service), Context.BIND_AUTO_CREATE)
}

inner class IpcServiceConnection(val simpleService: Class<out IPCService>) : ServiceConnection {

   override fun onServiceConnected(name: ComponentName?, service: IBinder?) {
       val mService = IIPCServiceInterface.Stub.asInterface(service) as IIPCServiceInterface
       binders[simpleService] = mService
  }

   override fun onServiceDisconnected(name: ComponentName?) {
       //断连之后，直接移除即可
       binders.remove(simpleService)
  }
}

对于绑定服务这块，相信伙伴们也很熟悉了，这个需要说一点的就是，在Android 5.0以后，启动服务不能只依赖action启动，还需要指定应用包名，否则就会报错。

在服务连接成功之后，即回调onServiceConnected方法的时候，需要拿到服务端的一个代理对象，即IIPCServiceInterface的实例对象，然后存储在binders集合中，key为绑定的服务类class对象，value就是对应的服务端的代理对象。

fun send(
   type: Int,
   service: Class<out IPCService>,
   serviceId: String,
   methodName: String,
   params: Array<Parameters>
): Response? {
   //创建请求
   val request = Request(type, serviceId, methodName, params)
   //发起请求
   return try {
       binders[service]?.send(request)
  } catch (e: Exception) {
       null
  }
}

当拿到服务端的代理对象之后，就可以在客户端调用send方法向服务端发送消息。

class Channel {

   //====================================
   /**每个服务对应的Binder对象*/
   private val binders: ConcurrentHashMap<Class<out IPCService>, IIPCServiceInterface> by lazy {
       ConcurrentHashMap()
  }

   //====================================

   /**
    * 绑定服务
    *
    */
   fun connect(
       context: Context,
       pkgName: String,
       action: String = "",
       service: Class<out IPCService>
  ) {
       val intent = Intent()
       if (pkgName.isEmpty()) {
           intent.setClass(context, service)
      } else {
           intent.setPackage(pkgName)
           intent.setAction(action)
           intent.setClass(context, service)
      }
       //绑定服务
       context.bindService(intent, IpcServiceConnection(service), Context.BIND_AUTO_CREATE)
  }

   inner class IpcServiceConnection(val simpleService: Class<out IPCService>) : ServiceConnection {

       override fun onServiceConnected(name: ComponentName?, service: IBinder?) {
           val mService = IIPCServiceInterface.Stub.asInterface(service) as IIPCServiceInterface
           binders[simpleService] = mService
      }

       override fun onServiceDisconnected(name: ComponentName?) {
           //断连之后，直接移除即可
           binders.remove(simpleService)
      }
  }


   fun send(
       type: Int,
       service: Class<out IPCService>,
       serviceId: String,
       methodName: String,
       params: Array<Parameters>
  ): Response? {
       //创建请求
       val request = Request(type, serviceId, methodName, params)
       //发起请求
       return try {
           binders[service]?.send(request)
      } catch (e: Exception) {
           null
      }
  }


   companion object {
       private val instance by lazy {
           Channel()
      }

       /**
        * 获取单例对象
        */
       fun getDefault(): Channel {
           return instance
      }
  }
}

3.2 动态代理获取接口实例

回到1.2小节中，我们定义了一个IUserManager接口，通过前面我们定义的通信协议，只要我们获取了IUserManager的实例对象，那么就能够调用其中的任意普通方法，所以在客户端需要设置一个获取接口实例对象的方法。

fun <T> getInstanceWithName(
   service: Class<out IPCService>,
   classType: Class<T>,
   clazz: Class<*>,
   methodName: String,
   params: Array<Parameters>
): T? {
   
   //获取serviceId
   val serviceId = clazz.getAnnotation(ServiceId::class.java)

   val response = Channel.getDefault()
      .send(REQUEST.GET_INSTANCE.ordinal, service, serviceId.name, methodName, params)
   Log.e("TAG", "response $response")
   if (response != null && response.result) {
       //请求成功，返回接口实例对象
       return Proxy.newProxyInstance(
           classType.classLoader,
           arrayOf(classType),
           IPCInvocationHandler()
      ) as T
  }

   return null
}

当我们通过客户端发送一个获取单例的请求后，如果成功了，那么就直接返回这个接口的单例对象，这里直接使用动态代理的方式返回一个接口实例对象，那么后续执行这个接口的方法时，会直接走到IPCInvocationHandler的invoke方法中。

class IPCInvocationHandler(
   val service: Class<out IPCService>,
   val serviceId: String?
) : InvocationHandler {

   private val gson = Gson()

   override fun invoke(proxy: Any?, method: Method?, args: Array<out Any>?): Any? {

       //执行客户端发送方法请求
       val response = Channel.getDefault()
          .send(
               REQUEST.INVOKE_METHOD.ordinal,
               service,
               serviceId,
               method?.name ?: "",
               args
          )
       //拿到服务端返回的结果
       if (response != null && response.result) {
           //反序列化得到结果
           return gson.fromJson(response.value, method?.returnType)
      }


       return null
  }

}

因为服务端在拿到Method的返回结果时，将javabean转换为了json字符串，因此在IPCInvocationHandler中，当调用接口中方法获取结果之后，用Gson将json转换为javabean对象，那么就直接获取到了结果。

3.3 框架使用

服务端：

UserManager2.getDefault().setUserInfo(User("ming", 25))
IPC.register(UserManager2::class.java)

同时在服务端需要注册一个IPCService的实例，这里用的是IPCService01

<service
   android:name=".UserService"
   android:enabled="true"
   android:exported="true" />
<service
   android:name="com.lay.ipc.service.IPCService01"
   android:enabled="true"
   android:exported="true">
   <intent-filter>
       <action android:name="android.intent.action.GET_USER_INFO" />
   </intent-filter>
</service>

客户端：

调用connect方法，需要绑定服务端的服务，传入包名和action

IPC.connect(
   this,
   "com.lay.learn.asm",
   "android.intent.action.GET_USER_INFO",
   IPCService01::class.java
)

首先获取IUserManager的实例，注意这里要和服务端注册的UserManager2是同一个ServiceId，而且接口、javabean需要存放在与服务端一样的文件夹下。

val userManager = IPC.getInstanceWithName(
   IPCService01::class.java,
   IUserManager::class.java,
   "getDefault",
   null
)
val info = userManager?.getUserInfo()

通过动态代理拿到接口的实例对象，只要调用接口中的方法，就会进入到InvocationHandler中的invoke方法，在这个方法中，通过查找服务端注册的方法名从而找到对应的Method，通过反射调用拿到UserManager中的方法返回值。

这样其实就通过5-6行代码，就完成了进程间通信，是不是比我们在使用AIDL的时候要方便地许多。

4 总结

如果我们面对下面这个类，如果这个类是个私有类，外部没法调用，想通过反射的方式调用其中某个方法。

@ServiceId(name = "UserManagerService")
public class UserManager2 implements IUserManager {

   private static UserManager2 userManager2 = new UserManager2();

   public static UserManager2 getDefault() {
       return userManager2;
  }

   private User user;

   @Nullable
   @Override
   public User getUserInfo() {
       return user;
  }

   @Override
   public void setUserInfo(@NonNull User user) {
       this.user = user;
  }

   @Override
   public int getUserId() {
       return 0;
  }

   @Override
   public void setUserId(int id) {

  }
}

那么我们可以这样做：

val method = UserManager2::class.java.getDeclaredMethod("getUserInfo")
method.isAccessible = true
method.invoke(this,params)

其实这个框架的原理就是上面这几行代码所能够完成的事；通过服务端注册的形式，将UserManager2中所有的方法Method收集起来；当另一个进程，也就是客户端想要调用其中某个方法的时候，通过方法名来获取到对应的Method，调用这个方法得到最终的返回值。

作者：layz4android
来源：juejin.cn/post/7192465342159912997

对于进程间通信，很多项目中可能根本没有涉及到多进程，很多公司的app可能就一个主进程，但是对于进程间通信，我们也是必须要了解的。

如果在Android中想要实现进程间通信，有哪些方式呢？

（1）发广播（sendBroadcast）：e.g. 两个app之间需要通信，那么可以通过发送广播的形式进行通信，如果只想单点通信，可以指定包名。但是这种方式存在的弊端在于发送方无法判断接收方是否接收到了广播，类似于UDP的通信形式，而且存在丢数据的形式；

（2）Socket通信：这种属于Linux层面的进程间通信了，除此之外，还包括管道、信号量等，像传统的IPC进程间通信需要数据二次拷贝，这种效率是最低的；

（3）AIDL通信：这种算是Android当中主流的进程间通信方案，通过Service + Binder的形式进行通信，具备实时性而且能够通过回调得知接收方是否收到数据，弊端在于需要管理维护aidl接口，如果不同业务方需要使用不同的aidl接口，维护的成本会越来越高。

那么本篇文章并不是说完全丢弃掉AIDL，它依然不失为一个很好的进程间通信的手段，只是我会封装一个适用于任意业务场景的IPC进程间通讯框架，这个也是我在自己的项目中使用到的，不需要维护很多的AIDL接口文件。

有需要源码的伙伴，可以去我的github首页获取 FastIPC源码地址，分支：feature/v0.0.1-snapshot，有帮助的话麻烦给点个star⭐️⭐️⭐️

1 服务端 - register

首先这里先说明一下，就是对于传统的AIDL使用方式，这里就不再过多介绍了，这部分还是比较简单的，有兴趣的伙伴们可以去前面的文章中查看，本文将着重介绍框架层面的逻辑。

那么IPC进程间通信，需要两个端：客户端和服务端。服务端会提供一个注册方法，例如客户端定义的一些服务，通过向服务端注册来做一个备份，当客户端调用服务端某个方法的时候来返回值。

object IPC {

   //==========================================

   /**
    * 服务端暴露的接口，用于注册服务使用
    */
   fun register(service: Class<*>) {
       Registry.instance.register(service)
  }

}

其实在注册的时候，我们的目的肯定是能够方便地拿到某个服务，并且能够调用这个服务提供的方法，拿到我想要的值；所以在定义服务的时候，需要注意以下两点：

（1）需要定义一个与当前服务一一对应的serviceId，通过serviceId来获取服务的实例；

（2）每个服务当中定义的方法同样需要对应起来，以便拿到服务对象之后，通过反射调用其中的方法。

所以在注册的时候，需要从这两点入手。

1.1 定义服务唯一标识serviceId

@Target(AnnotationTarget.TYPE)
@Retention(AnnotationRetention.RUNTIME)
annotation class ServiceId(
   val name: String
)

一般来说，如果涉及到反射，最常用的就是通过注解给Class做标记，因为通过反射能够拿到类上标记的注解，就能够拿到对应的serviceId。

class Registry {

   //=======================================
   /**用于存储 serviceId 对应的服务 class对象*/
   private val serviceMaps: ConcurrentHashMap<String, Class<*>> by lazy {
       ConcurrentHashMap()
  }

   /**用于存储 服务中全部的方法*/
   private val methodsMap: ConcurrentHashMap<Class<*>, ConcurrentHashMap<String, Method>> by lazy {
       ConcurrentHashMap()
  }


   //=======================================

   /**
    * 服务端注册方法
    * @param service 服务class对象
    */
   fun register(service: Class<*>) {

       // 获取serviceId与服务一一对应
       val serviceIdAnnotation = service.getAnnotation(ServiceId::class.java)
           ?: throw IllegalArgumentException("只有标记@ServiceId的服务才能够被注册")
       //获取serviceId
       val name = serviceIdAnnotation.name
       serviceMaps[name] = service
       //temp array
       val methods: ConcurrentHashMap<String, Method> = ConcurrentHashMap()
       // 获取服务当中的全部方法
       for (method in service.declaredMethods) {

           //这里需要注意，因为方法中存在重载方法，所以不能把方法名当做key，需要加上参数
           val buffer = StringBuffer()
           buffer.append(method.name).append("(")
           val params = method.parameterTypes
           if (params.size > 0) {
               buffer.append(params[0].name)
          }
           for (index in 1 until params.size) {
               buffer.append(",").append(params[index].name)
          }
           buffer.append(")")
           //保存
           methods[buffer.toString()] = method
      }
       //存入方法表
       methodsMap[service] = methods
  }

   companion object {
       val instance by lazy { Registry() }
  }
}

通过上面的register方法，当传入定义的服务class对象的时候，首先获取到服务上标记的@ServiceId注解，注意这里如果要注册必须标记，否则直接抛异常；拿到serviceId之后，存入到serviceMaps中。

然后需要获取服务中的全部方法，因为考虑到重载方法的存在，所以不能单单以方法名作为key，而是需要把参数也加上，因此这里做了一个逻辑就是将方法名与参数名组合一个key，存入到方法表中。

这样注册任务就完成了，其实还是比较简单的，关键在于完成2个表：服务表和方法表的初始化以及数据存储功能。

1.2 使用方式

@ServiceId("UserManagerService")
interface IUserManager {

   fun getUserInfo(): User?
   fun setUserInfo(user: User)
   fun getUserId(): Int
   fun setUserId(id: Int)
}

假设项目中有一个用户信息管理的服务，这个服务用于给所有的App提供用户信息查询。

@ServiceId("UserManagerService")
class UserManager : IUserManager {

   private var user: User? = null
   private var userId: Int = 0

   override fun getUserInfo(): User? {
       return user
  }

   override fun setUserInfo(user: User) {
       this.user = user
  }

   override fun getUserId(): Int {
       return userId
  }

   override fun setUserId(id: Int) {
       this.userId = id
  }

}

用户中心可以注册这个服务，并且调用setUserInfo方法保存用户信息，那么其他App（客户端）连接这个服务之后，就可以调用getUserInfo这个方法，获取用户信息，从而完成进程间通信。

2023-01-23 22:15:54.729 13361-13361/com.lay.learn.asm E/TAG: entrySet key class com.lay.learn.asm.binder.UserManager
2023-01-23 22:15:54.729 13361-13361/com.lay.learn.asm E/TAG: mapValue key setUserInfo(com.lay.learn.asm.binder.User)
2023-01-23 22:15:54.729 13361-13361/com.lay.learn.asm E/TAG: mapValue value public void com.lay.learn.asm.binder.UserManager.setUserInfo(com.lay.learn.asm.binder.User)
2023-01-23 22:15:54.729 13361-13361/com.lay.learn.asm E/TAG: mapValue key getUserInfo()
2023-01-23 22:15:54.729 13361-13361/com.lay.learn.asm E/TAG: mapValue value public com.lay.learn.asm.binder.User com.lay.learn.asm.binder.UserManager.getUserInfo()
2023-01-23 22:15:54.729 13361-13361/com.lay.learn.asm E/TAG: mapValue key getUserId()
2023-01-23 22:15:54.729 13361-13361/com.lay.learn.asm E/TAG: mapValue value public int com.lay.learn.asm.binder.UserManager.getUserId()
2023-01-23 22:15:54.729 13361-13361/com.lay.learn.asm E/TAG: mapValue key setUserId(int)
2023-01-23 22:15:54.729 13361-13361/com.lay.learn.asm E/TAG: mapValue value public void com.lay.learn.asm.binder.UserManager.setUserId(int)

我们看调用register方法之后，每个方法的key值都是跟参数绑定在一起，这样服务端注册就完成了。

2 客户端与服务端的通信协议

对于客户端的连接，其实就是绑定服务，那么这里就会使用到AIDL通信，但是跟传统的相比，我们是将AIDL封装到框架层内部，对于用户来说是无感知的。

2.1 创建IPCService

这个服务就是用来完成进程间通信的，客户端需要与这个服务建立连接，通过服务端分发消息，或者接收客户端发送来的消息。

abstract class IPCService : Service() {
   override fun onBind(intent: Intent?): IBinder? {
       return null
  }
}

这里我定义了一个抽象的Service基类，为啥要这么做，前面我们提到过是因为整个项目中不可能只有一个服务，因为业务众多，为了保证单一职责，需要划分不同的类型，所以在框架中会衍生多个实现类，不同业务方可以注册这些服务，当然也可以自定义服务继承IPCService。

class IPCService01 : IPCService() {
}

在IPCService的onBind需要返回一个Binder对象，因此需要创建aidl文件。

2.2 定义通讯协议

像我们在请求接口的时候，通常也是向服务端发起一个请求（Request），然后得到服务端的一个响应（Response），因此在IPC通信的的时候，也可以根据这种方式建立通信协议。

data class Request(
   val type: Int,
   val serviceId: String?,
   val methodName: String?,
   val params: Array<Parameters>?
) : Parcelable {
   //=====================================
   /**请求类型*/
   //获取实例的对象
   val GET_INSTANCE = "getInstance"
   //执行方法
   val INVOKE_METHOD = "invokeMethod"
   
   //=======================================

   constructor(parcel: Parcel) : this(
       parcel.readInt(),
       parcel.readString(),
       parcel.readString(),
       parcel.createTypedArray(Parameters.CREATOR)
  )

   override fun writeToParcel(parcel: Parcel, flags: Int) {
       parcel.writeInt(type)
       parcel.writeString(serviceId)
       parcel.writeString(methodName)
  }

   override fun describeContents(): Int {
       return 0
  }

   override fun equals(other: Any?): Boolean {
       if (this === other) return true
       if (javaClass != other?.javaClass) return false

       other as Request

       if (type != other.type) return false
       if (serviceId != other.serviceId) return false
       if (methodName != other.methodName) return false
       if (params != null) {
           if (other.params == null) return false
           if (!params.contentEquals(other.params)) return false
      } else if (other.params != null) return false

       return true
  }

   override fun hashCode(): Int {
       var result = type
       result = 31 * result + (serviceId?.hashCode() ?: 0)
       result = 31 * result + (methodName?.hashCode() ?: 0)
       result = 31 * result + (params?.contentHashCode() ?: 0)
       return result
  }

   companion object CREATOR : Parcelable.Creator<Request> {
       override fun createFromParcel(parcel: Parcel): Request {
           return Request(parcel)
      }

       override fun newArray(size: Int): Array<Request?> {
           return arrayOfNulls(size)
      }
  }

}

对于客户端来说，致力于发起请求，请求实体类Request参数介绍如下：

type表示请求的类型，包括两种分别是：执行静态方法和执行普通方法（考虑到反射传参）；

serviceId表示请求的服务id，要请求哪个服务，便可以获取到这个服务的实例对象，调用服务中提供的方法；

methodName表示要请求的方法名，也是在serviceId服务中定义的方法；

params表示请求的方法参数集合，我们在服务端注册的时候，方法名 + 参数名 作为key，因此需要知道请求的方法参数，以便获取到Method对象。

data class Response(
   val value:String?,
   val result:Boolean
):Parcelable {
   @SuppressLint("NewApi")
   constructor(parcel: Parcel) : this(
       parcel.readString(),
       parcel.readBoolean()
  )

   override fun writeToParcel(parcel: Parcel, flags: Int) {
       parcel.writeString(value)
       parcel.writeByte(if (result) 1 else 0)
  }

   override fun describeContents(): Int {
       return 0
  }

   companion object CREATOR : Parcelable.Creator<Response> {
       override fun createFromParcel(parcel: Parcel): Response {
           return Response(parcel)
      }

       override fun newArray(size: Int): Array<Response?> {
           return arrayOfNulls(size)
      }
  }
}

对于服务端来说，在接收到请求之后，需要针对具体的请求返回相应的结果，Response实体类参数介绍：

result表示请求成功或者失败；

value表示服务端返回的结果，是一个json字符串。

因此定义aidl接口文件如下，输入一个请求之后，返回一个服务端的响应。

interface IIPCServiceInterface {
   Response send(in Request request);
}

这样IPCService就可以将aidl生成的Stub类作为Binder对象返回。

abstract class IPCService : Service() {
   
   override fun onBind(intent: Intent?): IBinder? {
       return BINDERS
  }

   companion object BINDERS : IIPCServiceInterface.Stub() {
       override fun send(request: Request?): Response? {

           when(request?.type){
               
               REQUEST.GET_INSTANCE.ordinal->{
                   
              }
               REQUEST.INVOKE_METHOD.ordinal->{
                   
              }
          }
           
           return null
      }
  }
}

续：Android进阶宝典 -- 告别繁琐的AIDL吧，手写IPC通信框架，5行代码实现进程间通信（下）

作者：layz4android

来源：juejin.cn/post/7192465342159912997

在之前的文章给你的 Android App 添加自定义表情中我们介绍了自定义表情的原理，没看过的建议看一下。这一篇文章将介绍它的应用，这里以B站的自定义表情面板为例，效果如下：

自定义表情的大小

当我们写死表情的大小时，文字的 textSize 变大变小时都会有一点问题。

文字大于图片大小时，在多行的情况下，只有表情的行间距明显小于其他行的间距。如图：

为什么会出现这种情况呢？如下图所示，我在top, ascent, baseline, descent, bottom的位置标注了辅助线。

可以很清晰的看到，在只有表情的情况下，top, ascent, descent, bottom的位置有明显的问题。原因是 DynamicDrawableSpan 的 getSize 方法里面对 FontMetricsInt 进行了修改。解决的方式很简单，就是注释掉修改代码就行，代码如下。修改后，效果如下图所示。

@Override
    public int getSize(@NonNull Paint paint, CharSequence text, int start, int end, @Nullable FontMetricsInt fm) {
          Drawable d = getDrawable();
          Rect rect = d.getBounds();
//
//        if (fm != null) {
//            fm.ascent = -rect.bottom;
//            fm.descent = 0;
//
//            fm.top = fm.ascent;
//            fm.bottom = 0;
//        }

        return rect.right;
    }

不知道你还记不记得，我们说过getSize 的返回值是表情的宽度。上面的注释代码其实是设置了表情的高度，如果文本的大小少于表情时，就会显示不全，如下图所示：

那这种情况下，应该怎么办？这里不卖关子了，最终代码如下。解决方式非常简单就是分情况来判断。当文本的高度小于表情的高度时，设置 fm 的top, ascent, descent, bottom的值，让行的高度变大的同时让大的 emoji 图片居中。

 @Override
    public int getSize(@NonNull Paint paint, CharSequence text, int start, int end, @Nullable FontMetricsInt fm) {
        Drawable d = getDrawable();
        Rect rect = d.getBounds();

        float drawableHeight = rect.height();
        Paint.FontMetrics paintFm = paint.getFontMetrics();

        if (fm != null) {
            int textHeight = fm.bottom - fm.top;
            if(textHeight <= drawableHeight) {//当文本的高度小于表情的高度时
                //解决文字的大小小于图片大小的情况
                float textCenter = (paintFm.descent + paintFm.ascent) / 2;
                fm.ascent = fm.top = (int) (textCenter - drawableHeight / 2);
                fm.descent = fm.bottom = (int) (textCenter + drawableHeight / 2);
            }
        }
    return rect.right;
}

当然，你可能发现了，B站的 emoji 表情好像不是居中的。如下图所示，B站对 emoji 表情的处理类似基于 baseline 对齐。

上面最难理解的居中已经介绍，对于其他方式比如 baseline 和 bottom 就简单了。完整代码如下：

@Override
    public int getSize(@NonNull Paint paint, CharSequence text, int start, int end, @Nullable FontMetricsInt fm) {
        Drawable d = getDrawable();
        if(d == null) {
            return 48;
        }
        Rect rect = d.getBounds();

        float drawableHeight = rect.height();
        Paint.FontMetrics paintFm = paint.getFontMetrics();

        if (fm != null) {
            if (mVerticalAlignment == ALIGN_BASELINE) {
                fm.ascent = fm.top = (int) (paintFm.bottom - drawableHeight);
                fm.bottom = (int) (paintFm.bottom);
                fm.descent = (int) paintFm.descent;
            } else if(mVerticalAlignment == ALIGN_BOTTOM) {
                fm.ascent = fm.top = (int) (paintFm.bottom - drawableHeight);
                fm.bottom = (int) (paintFm.bottom);
                fm.descent = (int) paintFm.descent;
            } else if (mVerticalAlignment == ALIGN_CENTER) {
                int textHeight = fm.bottom - fm.top;
                if(textHeight <= rect.height()) {
                    float textCenter = (paintFm.descent + paintFm.ascent) / 2;
                    fm.ascent = fm.top = (int) (textCenter - drawableHeight / 2);
                    fm.descent = fm.bottom = (int) (textCenter + drawableHeight / 2);
                }
            }
        }

        return rect.right;
    }

动态表情

动态表情实际上就是 gif 图。我们可以使用 android-gif-drawable 来实现。在 build.gradle 中增加依赖：

dependencies {
    ...
    implementation 'pl.droidsonroids.gif:android-gif-drawable:1.2.25'
}

然后在我们创建自定义 ImageSpan 的时候传入参数就可以了：

val size = 192
val gifFromResource = GifDrawable(getResources(), gifData.drawableResource)
gifFromResource.stop()
gifFromResource.setBounds(0,0, size, size)
val content = mBinding.editContent.text as SpannableStringBuilder
val stringBuilder = SpannableStringBuilder(gifData.text)
stringBuilder.setSpan(BilibiliEmojiSpan(gifFromResource, ALIGN_BASELINE),
    0, stringBuilder.length, Spannable.SPAN_EXCLUSIVE_EXCLUSIVE)

关于 android-gif-drawable 更具体用法可以看 Android加载Gif动画android-gif-drawable的使用

作者：小墙程序员

来源：juejin.cn/post/7196592276159823931

很多App一打开，首页都会有各种各样的交互，比如权限授权，版本更新，阅读协议，活动介绍，用户权限变更等，这些交互大多数都是以弹框为主，也会有少数几个是以页面或者别的形式出现，但是无论是弹框还是页面，这些只是表现形式，这种交互难点在于

1. 如何去判断它们什么时候出来

2. 它们出来的先后次序是什么

3. 中途需求如果增加或者删除一个弹框或者页面，我们应该改动哪些逻辑

常见的做法

可能这种需求刚开始由于弹框少，交互还简单，所以大多数的做法就是直接在首页用if-else去完成了

if(条件1){
   //弹框1 
}else if(条件2){
    //弹框2
}

但是当需求慢慢迭代下去，首页弹框越来越多，判断的逻辑也越来越复杂，判断条件之间还存在依赖关系的时候，我们的代码就变得很可怕了

if(条件1 && 条件2 && 条件3){
   //弹框1
}else if(条件1 && (条件2 || 条件3)){
    //弹框2
}else if(条件2 && 条件3){
    //弹框3
}else if(....){
    ....
}

这种情况下，这些代码就变的越来越难维护，长久下来，造成的问题也越来越多，比如

1. 代码可读性变差，不是熟悉业务的人无法去理解这些逻辑代码

2. 增加或者减少弹框或者条件需要更改中间的逻辑，容易产生bug

3. 每个分支的弹框结束后，需要重新从第一个if再执行一遍判断下一个弹框是哪一个，如果条件里面牵扯到io操作，也会产生一定的性能问题

设计思路

能否让每个弹框作为一个单独的任务，生成一条任务链，链上的节点为单个任务，节点维护任务执行的条件以及任务本身逻辑,节点之间无任何依赖关系,具体执行由任务链去管理，这样的话如果增加或者删除某一个任务，我们只需要插拔任务节点就可以

定义任务

首先我们先简单定一个任务，以及需要执行的操作

interface SingleJob {
    fun handle(): Boolean
    fun launch(context: Context, callback: () -> Unit)
}

• handle():判断任务是否应该执行的条件

• launch():执行任务，并在任务结束后通过callback通知任务链执行下一条任务

实现任务

定义一个TaskJobOne,让它去实现SingleJob

class TaskJobOne : SingleJob {
    override fun handle(): Boolean {
        println("start handle job one")
        return true
    }
    override fun launch(context: Context, callback: () -> Unit) {
        println("start launch job one")
        AlertDialog.Builder(context).setMessage("这是第一个弹框")
            .setPositiveButton("ok") {x,y->
                callback()
            }.show()
    }
}

这个任务里面，我们先默认handle的执行条件是true,一定会执行，实际开发过程中可以根据需要来定义条件，比如判断登录态等，lanuch里面我们简单的弹一个框，然后在弹框的关闭的时候，callback给任务链，为了调试的时候看的清楚一些，在这两个函数入口分别打印了日志，同样的任务我们再创建一个TaskJobTwo,TaskJobThree,具体实现差不多，就不贴代码了

任务链

首先思考下如何存放任务，由于任务之间需要体现出优先级关系，所以这里决定使用一个LinkedHashMap,K表示优先级，V表示任务

object JobTaskManager {
    val jobMap = linkedMapOf(
        1 to TaskJobOne(),
        2 to TaskJobTwo(),
        3 to TaskJobThree()
    )
}

接着就是思考如何设计整条任务链的执行任务，因为这个是对jobMap里面的任务逐个拿出来执行的过程，所以我们很容易就想到可以用Flow去控制这些任务，但是有两个问题需要去考虑下

1. 如果直接将jobMap转成Flow去执行，那么出现的问题就是所有任务全部都一次性执行完，显然不符合设计初衷

2. 我们都知道Flow是由上游发送数据，下游接收并处理数据的一个自上而下的过程，但是这里我们需要一个job执行完以后，通过callback通知任务链去执行下一个任务，任务的发送是由前一个任务控制的，所以必须设计出一个环形的过程

首先我们需要一个变量去保存当前需要执行的任务优先级，我们定义它为curLevel,并设置初始值为1，表示第一个执行的是优先级为1的任务

var curLevel = 1

这个变量将会在任务执行完以后，通过callback回调以后再自增，至于自增之后如何再去执行下一条任务，这个通知的事情我们交给StateFlow

val stateFlow = MutableStateFlow(curLevel)
fun doJob(context: Context, job: SingleJob) {
    if (job.handle()) {
        job.launch(context) {
            curLevel++
            if (curLevel <= jobMap.size)
                stateFlow.value = curLevel
        }
    } else {
        curLevel++
        if (curLevel <= jobMap.size)
            stateFlow.value = curLevel
    }
}

stateFlow初始值是curlevel，当上层开始订阅的时候，不给stateFlow设置value，那么stateFlow初始值1就会发送出去，开始执行优先级为1的任务，在doJob里面，当任务的执行条件不满足或者任务已经执行完成，就自增curLevel，再给stateFlow赋值，从而执行下一个任务，这样一个环形过程就有了，下面是在上层如何执行任务链

MainScope().launch {
    JobTaskManager.apply {
        stateFlow.collect {
            flow {
                emit(jobMap[it])
            }.collect {
                doJob(this@MainActivity, it!!)
            }
        }
    }
}

我们的任务链就完成了，看下效果

通过日志我们可以看到，的确是每次关闭一个弹框，才开始执行下一条任务，这样一来，如果某个任务的条件不满足，或者不想让它执行了，只需要改变对应job的handle条件就可以，比如现在把TaskJobOne的handel设置为false,在看下效果

class TaskJobOne : SingleJob {
    override fun handle(): Boolean {
        println("start handle job one")
        return false
    }
    override fun launch(context: Context, callback: () -> Unit) {
        println("start launch job one")
        AlertDialog.Builder(context).setMessage("这是第一个弹框")
            .setPositiveButton("ok") {x,y->
                callback()
            }.show()
    }
}

可以看到经过第一个task的时候，由于已经把handle条件设置成false了，所以直接跳过,执行下一个任务了

依赖于外界因素

上面只是简单的模拟了一个任务链的工作流程，实际开发过程中，我们有的任务会依赖于其他因素，最常见的就是必须等到某个接口返回数据以后才去执行，所以这个时候，执行你的任务需要判断的东西就更多了

• 是否优先级已经轮到它了

• 是否依赖于某个接口

• 这个接口是否已经成功返回数据了

• 接口数据是否需要传递给这个任务 鉴于这些，我们就要重新设计我们的任务与任务链，首先要定义几个状态值，分别代表任务的不同状态

const val JOB_NOT_AVAILABLE = 100
const val JOB_AVAILABLE = 101
const val JOB_COMBINED_BY_NOTHING = 102
const val JOB_CANCELED = 103

• JOB_NOT_AVAILABLE:该任务还没有达到执行条件

• JOB_AVAILABLE:该任务达到了执行任务的条件

• JOB_COMBINED_BY_NOTHING:该任务不关联任务条件，可直接执行

• JOB_CANCELED:该任务不能执行

接着需要去扩展一下SingleJob的功能，让它可以设置状态，获取状态，并且可以传入数据

interface SingleJob {
    ......
    /**
     * 获取执行状态
     */
    fun status():Int

    /**
     * 设置执行状态
     */
    fun setStatus(level:Int)

    /**
     * 设置数据
     */
    fun setBundle(bundle: Bundle)
}

更改一下任务的实现

class TaskJobOne : SingleJob {
    var flag = JOB_NOT_AVAILABLE
    var data: Bundle? = null
    override fun handle(): Boolean {
        println("start handle job one")
        return  flag != JOB_CANCELED
    }
    override fun launch(context: Context, callback: () -> Unit) {
        println("start launch job one")
        val type = data?.getString("dialog_type")
        AlertDialog.Builder(context).setMessage(if(type != null)"这是第一个${type}弹框" else "这是第一个弹框")
            .setPositiveButton("ok") {x,y->
                callback()
            }.show()
    }
    override fun setStatus(level: Int) {
        if(flag != JOB_COMBINED_BY_NOTHING)
            this.flag = level
    }
    override fun status(): Int = flag

    override fun setBundle(bundle: Bundle) {
        this.data = bundle
    }
}

现在的任务执行条件已经变了，变成了状态不是JOB_CANCELED的任务才可以执行，增加了一个变量flag表示这个任务的当前状态，如果是JOB_COMBINED_BY_NOTHING表示不依赖外界因素，外界也不能改变它的状态，其余状态则通过setStatus函数来改变，增加了setBundle函数允许外界向任务传入数据，并且在launch函数里面接收数据并展示在弹框上，我们在任务链里面增加一个函数，用来给对应优先级的任务设置状态与数据

fun setTaskFlag(level: Int, flag: Int, bundle: Bundle = Bundle()) {
        if (level > jobMap.size) {
            return
        }
        jobMap[level]?.apply {
            setStatus(flag)
            setBundle(bundle)
        }
    }

我们现在可以把任务链同接口一起关联起来了，首先我们先创建个viewmodel,在里面创建三个flow,分别模拟三个不同接口，并且在flow里面向下游发送数据

class MainViewModel : ViewModel(){
    val firstApi = flow {
        kotlinx.coroutines.delay(1000)
        emit("元宵节活动")
    }
    val secondApi = flow {
        kotlinx.coroutines.delay(2000)
        emit("端午节活动")
    }
    val thirdApi = flow {
        kotlinx.coroutines.delay(3000)
        emit("中秋节活动")
    }
}

接着我们如果想要去执行任务链，就必须等到所有接口执行完毕才可以，刚好flow里面的zip操作符就可以满足这一点，它可以让异步任务同步执行，等到都执行完任务之后，才将数据传递给下游，代码实现如下

val mainViewModel: MainViewModel by lazy {
    ViewModelProvider(this)[MainViewModel::class.java]
}

MainScope().launch {
    JobTaskManager.apply {
        mainViewModel.firstApi
            .zip(mainViewModel.secondApi) { a, b ->
                setTaskFlag( 1, JOB_AVAILABLE, Bundle().apply {
                    putString("dialog_type", a)
                })
                setTaskFlag( 2, JOB_AVAILABLE, Bundle().apply {
                    putString("dialog_type", b)
                })
            }.zip(mainViewModel.thirdApi) { _, c ->
                setTaskFlag( 3, JOB_AVAILABLE, Bundle().apply {
                    putString("dialog_type", c)
                })
            }.collect {
                stateFlow.collect {
                    flow {
                        emit(jobMap[it])
                    }.collect {
                        doJob(this@MainActivity, it!!)
                    }
                }
            }
    }
}

运行一下，效果如下

我们看到启动后第一个任务并没有立刻执行，而是等了一会才去执行，那是因为zip操作符是等所有flow里面的同步任务都执行完毕以后才发送给下游，flow里面已经执行完毕的会去等待还没有执行完毕的任务，所以才会出现刚刚页面有一段等待的时间，这样的设计一般情况下已经可以满足需求了，毕竟正常情况一个接口的响应时间都是毫秒级别的，但是难防万一出现一些极端情况，某一个接口响应忽然变慢了，就会出现我们的任务链迟迟得不到执行，产品体验方面就大打折扣了，所以需要想个方案解决一下这个问题

优化

首先我们需要当应用启动以后就立马执行任务链，判断当前需要执行任务的优先级与curLevel是否一致，另外，该任务的状态是可执行状态

/**
 * 应用启动就执行任务链
 */
fun loadTask(context: Context) {
    judgeJob(context, curLevel)
}

/**
 * 判断当前需要执行任务的优先级是否与curLevel一致，并且任务可执行
 */
private fun judgeJob(context: Context, cur: Int) {
    val job = jobMap[cur]
    if(curLevel == cur && job?.status() != JOB_NOT_AVAILABLE){
        MainScope().launch {
            doJob(context, cur)
        }
    }
}

我们更改一下doJob函数，让它成为一个挂起函数，并且在里面执行完任务以后，直接去判断它的下一级任务应不应该执行

private suspend fun doJob(context: Context, index: Int) {
    if (index > jobMap.size) return
    val singleJOb = jobMap[index]
    callbackFlow {
        if (singleJOb?.handle() == true) {
            singleJOb.launch(context) {
                trySend(index + 1)
            }
        } else {
            trySend(index + 1)
        }
        awaitClose { }
    }.collect {
        curLevel = it
        judgeJob(context,it)
    }
}

流程到了这里，如果所有任务都不依赖接口，那么这个任务链就能一直执行下去，如果遇到JOB_NOT_AVAILABLE的任务，需要等到接口响应的，那么任务链停止运行，那什么时候重新开始呢？就在我们接口成功回调之后给任务更改状态的时候，也就是setTaskFlag

fun setTaskFlag(context:Context,level: Int, flag: Int, bundle: Bundle = Bundle()) {
    if (level > jobMap.size) {
        return
    }
    jobMap[level]?.apply {
        setStatus(flag)
        setBundle(bundle)
    }
    judgeJob(context,level)
}

这样子，当任务链走到一个JOB_NOT_AVAILABLE的任务的时候，任务链暂停，当这个任务依赖的接口成功回调完成对这个任务状态的设置之后，再重新通过judgeJob继续走这条任务链，而一些优先级比较低的任务依赖的接口先完成了回调，那也只是完成对这个任务的状态更改，并不会执行它，因为curLevel还没到这个任务的优先级，现在可以试一下效果如何，我们把threeApi这个接口响应时间改的长一点

val thirdApi = flow {
    kotlinx.coroutines.delay(5000)
    emit("中秋节活动")
}

上层执行任务链的地方也改一下

MainScope().launch {
    JobTaskManager.apply {
        loadTask(this@MainActivity)
        mainViewModel.firstApi.collect{
            setTaskFlag(this@MainActivity, 1, JOB_AVAILABLE, Bundle().apply {
                putString("dialog_type", it)
            })
        }
        mainViewModel.secondApi.collect{
            setTaskFlag(this@MainActivity, 2, JOB_AVAILABLE, Bundle().apply {
                putString("dialog_type", it)
            })
        }
        mainViewModel.thirdApi.collect{
            setTaskFlag(this@MainActivity, 3, JOB_AVAILABLE, Bundle().apply {
                putString("dialog_type", it)
            })
        }
    }
}

应用启动就loadTask，然后三个接口已经从同步又变成异步操作了，运行一下看看效果

总结

大致的一个效果算是完成了，这只是一个demo,实际需求当中可能更复杂，弹框，页面，小气泡来回交互的情况都有可能，这里也只是想给一些正在优化项目的的同学提供一个思路，或者接手新需求的时候，鼓励多思考一下有没有更好的设计方案

作者：Coffeeee
来源：juejin.cn/post/7195336320435601467

我们通常可以在通知栏上看到“飞行模式”、“移动数据”、“屏幕录制”等开关按钮，这些按钮都属于通知栏上的快捷开关，点击快捷开关可以轻易调用某种系统能力或打开某个应用程序的特定页面。那是否可以在通知栏上自定义一个快捷开关呢？答案是可以的，具体是通过TileService的方案实现。

TileService继承自Service，所以它也是Android的四大组件之一，不过它是一个特殊的组件，开发者不需要手动开启调用，系统可以自动识别并完成调用，系统会通过绑定服务（bindService）的方式调用。

创建使用：

快捷开关是Android 7（target 24）的新能力，因此在使用该能力前必须先判断版本大小（大于等于target 24）。

1、自定义一个TileService类。

class MyQSTileService: TileService() {
  override fun onTileAdded() {    
      super.onTileAdded()  
  }
  
  override fun onStartListening() {    
      super.onStartListening()  
  }
  
  override fun onStopListening() {    
      super.onStopListening()  
  }
  
  override fun onClick() {    
      super.onClick()  
  }
  
  override fun onTileRemoved() {    
      super.onTileRemoved()  
  }
}

TileService是通过绑定服务（bindService）的方式被调用的，因此，绑定服务生命周期包含的四种典型的回调方法（onCreate()、onBind()、onUnbind()和 onDestroy()）都会被调用。但是，TileService也包含了以下特殊的生命周期回调方法：

• onTileAdded()：当用户从编辑栏添加快捷开关到通知栏的快速设置中会调用。

• onTileRemoved()：当用户从通知栏的快速设置移除快捷开关时调用。

• onClick()：当用户点击快捷开关时调用。

• onStartListening()：当用户打开通知栏的快速设置时调用。当快捷开关并没有从编辑栏拖到设置栏中不会调用。在TileAdded添加之后会调用一次。

• onStopListening()：当用户打开通知栏的快速设置时调用。当快捷开关并没有从编辑栏拖到设置栏中不会调用。在TileRemoved移除之前会调用一次。

2、在应用程序的清单文件中声明TileService。

<service
     android:name=".MyQSTileService"
     android:label="@string/my_default_tile_label"  
     android:icon="@drawable/my_default_icon_label"
     android:exported="true"
     android:permission="android.permission.BIND_QUICK_SETTINGS_TILE">
     <intent-filter>
         <action android:name="android.service.quicksettings.action.QS_TILE" />
     </intent-filter>
 </service>

• name：自定义的TileService的类名。

• label：快捷开关在通知栏上显示的名称。

• icon：快捷开关在通知栏上显示的图标。

• exported：该服务能否被外部应用调用。该属性必须为true。如果为false，那么快捷开关的功能将失效，原因是exported="false"时，TileService将不支持外部应用调起，手机系统自然不能再和该快捷开关交互。必须配置。

• permission：需要给service配置的权限，BIND_QUICK_SETTINGS_TILE即允许应用程序绑定到第三方快速设置。必须配置。

• intent-filter：意图过滤器，只有匹配内部的action，才能调起该service。必须配置。

监听模式

TileService的监听模式（或理解为启动模式）有两种，一种是主动模式，另一种是标准模式。

• 主动模式

在主动模式下，TileService被请求时该服务会被绑定，并且TileService的onStartListening也会被调用。该模式需要在AndroidManifeast清单文件中声明：

<service ...>
    <meta-data android:name="android.service.quicksettings.ACTIVE_TILE"
         android:value="true" />
    ...
</service>

通过TileService.requestListeningState()这一静态方法，就可以实现对TileService的请求，示例如下：

      TileService.requestListeningState(
            applicationContext, ComponentName(
                BuildConfig.APPLICATION_ID,
                MyQSTileService::class.java.name
            )
        )

主动模式下值得注意的是：

• 用户在通知栏快速设置的地方点击快捷开关时，TileService会自动完成绑定、TileService的onStartListening会被调用。

• TileService无论是通过点击被绑定还是通过requestListeningState请求被绑定，TileService所在的进程都会被调起。

标准模式

在标准模式下，TileService可见时（即用户下拉通知栏看见快捷开关）该服务会被绑定，并且TileService的onStartListening也会被调用。标准模式不需要在AndroidManifeast清单文件中进行额外的声明，默认就是标准模式。

标准模式下值得注意的是：

• 和主动模式相同，TileService被绑定时，TileService所在的进程就会被调起。

• 而和主动模式不同的是，标准模式绑定TileService是通过用户下拉通知栏实现的，这意味着TileService所在的进程会被多次调起。因此为了避免主进程被频繁调起、避免DAU等数据统计受到影响，我们还需要为TileService指定一个特定的子进程，在Androidmanifest清单文件中设置：

      <service
            ......
            android:process="自定义子进程的名称">
            ......
        </service>

更新快捷开关

如果需要对快捷开关的数据进行更新，可以通过getQsTile()获取快捷开关的对象，然后通过setIcon（更新icon）、setLable（更新名称）、setState（更新状态，包括STATE_ACTIVE——表示开启或启用状态、STATE_INACTIVE——表示关闭或暂停状态、STATE_UNAVAILABLE：表示暂时不可用状态，在此状态下，用户无法与您的磁贴交互）等方法设置快捷开关新的数据，最后调用updateTile()方法实现。

  override fun onStartListening() {
    super.onStartListening()
    if (qsTile.state === Tile.STATE_ACTIVE) {
        qsTile.label = "inactive"
        qsTile.icon = Icon.createWithResource(context, R.drawable.inactive)
        qsTile.state = Tile.STATE_INACTIVE
    } else {
        qsTile.label = "active"
        qsTile.icon = Icon.createWithResource(context, R.drawable.active)
        qsTile.state = Tile.STATE_ACTIVE
    }
    qsTile.updateTile()
  }

操作快捷开关

• 如果想要实现点击快捷开关时、关闭通知栏并跳转到某个页面，可以调用以下方法：

startActivityAndCollapse(Intent intent)

• 如果想要在点击快捷开关时弹出对话框进行交互，可以调用以下方法：

override fun onClick() {
    super.onClick()
    if(!isLocked()) {
        showDialog()
    }
 }

因为快捷开关有可能在用户锁屏时出现，所以必须加上isLocked()的判断。只有非锁屏的情况下，对话框才会出现。

• 如果快捷开关含有敏感信息，需要使用isSecure()进行设备安全性判断，当设备安全时，才能执行快捷开关相关的逻辑（如点击的逻辑）。当设备不安全时（手机处于锁屏状态时），可调用unlockAndRun(Runnable runnable)，提示用户解锁屏幕并执行自定义的runnable操作。

以上是通知栏增加快捷开关的全部介绍。欢迎关注公众号度熊君，一起分享交流。

作者：度熊君
来源：juejin.cn/post/7190663063631036473

背景

对于一个普通的android应用来说，so库的占比通常都是巨高不下的，因为我们无可避免的在开发中遇到各种各样需要用到native的需求，所以so库的动态化可以减少极大的包体积，自从2020腾讯的bugly团队发部关于动态化so的相关文章后，已经过去两年了，相关文章，经过两年的考验，实际上so动态加载也是非常成熟的一项技术了，但是很遗憾，许多公司都还没有这方面的涉略又或者说不知道从哪里开始进行，因为so动态其实涉及到下载，so版本管理，动态加载实现等多方面，我们不妨抛开这些额外的东西，从最本质的so动态加载出发吧！这里是本次的例子，我把它命名为sillyboy，欢迎pr还有后续点赞呀！

so动态加载介绍

动态加载，其实就是把我们的so库在打包成apk的时候剔除，在合适的时候通过网络包下载的方式，通过一些手段，在运行的时候进行分离加载的过程。这里涉及到下载器，还有下载后的版本管理等等确保一个so库被正确的加载等过程，在这里，我们不讨论这些辅助的流程，我们看下怎么实现一个最简单的加载流程。

从一个例子出发

我们构建一个native工程，然后在里面编入如下内容，下面是cmake

# For more information about using CMake with Android Studio, read the
# documentation: https://d.android.com/studio/projects/add-native-code.html

# Sets the minimum version of CMake required to build the native library.

cmake_minimum_required(VERSION 3.18.1)

# Declares and names the project.

project("nativecpp")

# Creates and names a library, sets it as either STATIC
# or SHARED, and provides the relative paths to its source code.
# You can define multiple libraries, and CMake builds them for you.
# Gradle automatically packages shared libraries with your APK.

add_library( # Sets the name of the library.
        nativecpp

        # Sets the library as a shared library.
        SHARED

        # Provides a relative path to your source file(s).
        native-lib.cpp)

add_library(
        nativecpptwo
        SHARED
        test.cpp

)

# Searches for a specified prebuilt library and stores the path as a
# variable. Because CMake includes system libraries in the search path by
# default, you only need to specify the name of the public NDK library
# you want to add. CMake verifies that the library exists before
# completing its build.

find_library( # Sets the name of the path variable.
        log-lib

        # Specifies the name of the NDK library that
        # you want CMake to locate.
        log)

# Specifies libraries CMake should link to your target library. You
# can link multiple libraries, such as libraries you define in this
# build script, prebuilt third-party libraries, or system libraries.

target_link_libraries( # Specifies the target library.
        nativecpp

        # Links the target library to the log library
        # included in the NDK.
        ${log-lib})


target_link_libraries( # Specifies the target library.
        nativecpptwo

        # Links the target library to the log library
        # included in the NDK.
        nativecpp
        ${log-lib})

可以看到，我们生成了两个so库一个是nativecpp，还有一个是nativecpptwo（为什么要两个呢？我们可以继续看下文） 这里也给出最关键的test.cpp代码

#include <jni.h>
#include <string>
#include<android/log.h>


extern "C"
JNIEXPORT void JNICALL
Java_com_example_nativecpp_MainActivity_clickTest(JNIEnv *env, jobject thiz) {
    // 在这里打印一句话
    __android_log_print(ANDROID_LOG_INFO,"hello"," native 层方法");

}

很简单，就一个native方法，打印一个log即可，我们就可以在java/kotin层进行方法调用了，即

public native void clickTest();

so库检索与删除

要实现so的动态加载，那最起码是要知道本项目过程中涉及到哪些so吧！不用担心，我们gradle构建的时候，就已经提供了相应的构建过程，即构建的task【 mergeDebugNativeLibs】，在这个过程中，会把一个project里面的所有native库进行一个收集的过程，紧接着task【stripDebugDebugSymbols】是一个符号表清除过程，如果了解native开发的朋友很容易就知道，这就是一个减少so体积的一个过程，我们不在这里详述。所以我们很容易想到，我们只要在这两个task中插入一个自定义的task，用于遍历和删除就可以实现so的删除化了，所以就很容易写出这样的代码

ext {
    deleteSoName = ["libnativecpptwo.so","libnativecpp.so"]
}
// 这个是初始化 -配置 -执行阶段中，配置阶段执行的任务之一，完成afterEvaluate就可以得到所有的tasks，从而可以在里面插入我们定制化的数据
task(dynamicSo) {
}.doLast {
    println("dynamicSo insert!!!! ")
    //projectDir 在哪个project下面，projectDir就是哪个路径
    print(getRootProject().findAll())

    def file = new File("${projectDir}/build/intermediates/merged_native_libs/debug/out/lib")
    //默认删除所有的so库
    if (file.exists()) {
        file.listFiles().each {
            if (it.isDirectory()) {
                it.listFiles().each {
                    target ->
                        print("file ${target.name}")
                        def compareName = target.name
                        deleteSoName.each {
                            if (compareName.contains(it)) {
                                target.delete()
                            }
                        }
                }
            }
        }
    } else {
        print("nil")
    }
}
afterEvaluate {
    print("dynamicSo task start")
    def customer = tasks.findByName("dynamicSo")
    def merge = tasks.findByName("mergeDebugNativeLibs")
    def strip = tasks.findByName("stripDebugDebugSymbols")
    if (merge != null || strip != null) {
        customer.mustRunAfter(merge)
        strip.dependsOn(customer)
    }

}

可以看到，我们定义了一个自定义task dynamicSo，它的执行是在afterEvaluate中定义的，并且依赖于mergeDebugNativeLibs，而stripDebugDebugSymbols就依赖于我们生成的dynamicSo，达到了一个插入操作。那么为什么要在afterEvaluate中执行呢？那是因为android插件是在配置阶段中才生成的mergeDebugNativeLibs等任务，原本的gradle构建是不存在这样一个任务的，所以我们才需要在配置完所有task之后，才进行的插入，我们可以看一下gradle的生命周期

通过对条件检索，我们就删除掉了我们想要的so，即ibnativecpptwo.so与libnativecpp.so。

动态加载so

根据上文检索出来的两个so，我们就可以在项目中上传到自己的后端中，然后通过网络下载到用户的手机上，这里我们就演示一下即可，我们就直接放在data目录下面吧

真实的项目过程中，应该要有校验操作，比如md5校验或者可以解压等等操作，这里不是重点，我们就直接略过啦！

那么，怎么把一个so库加载到我们本来的apk中呢？这里是so原本的加载过程，可以看到，系统是通过classloader检索native目录是否存在so库进行加载的，那我们反射一下，把我们自定义的path加入进行不就可以了吗？这里采用tinker一样的思路，在我们的classloader中加入so的检索路径即可，比如

private static final class V25 {
    private static void install(ClassLoader classLoader, File folder)  throws Throwable {
        final Field pathListField = ShareReflectUtil.findField(classLoader, "pathList");
        final Object dexPathList = pathListField.get(classLoader);

        final Field nativeLibraryDirectories = ShareReflectUtil.findField(dexPathList, "nativeLibraryDirectories");

        List<File> origLibDirs = (List<File>) nativeLibraryDirectories.get(dexPathList);
        if (origLibDirs == null) {
            origLibDirs = new ArrayList<>(2);
        }
        final Iterator<File> libDirIt = origLibDirs.iterator();
        while (libDirIt.hasNext()) {
            final File libDir = libDirIt.next();
            if (folder.equals(libDir)) {
                libDirIt.remove();
                break;
            }
        }
        origLibDirs.add(0, folder);

        final Field systemNativeLibraryDirectories = ShareReflectUtil.findField(dexPathList, "systemNativeLibraryDirectories");
        List<File> origSystemLibDirs = (List<File>) systemNativeLibraryDirectories.get(dexPathList);
        if (origSystemLibDirs == null) {
            origSystemLibDirs = new ArrayList<>(2);
        }

        final List<File> newLibDirs = new ArrayList<>(origLibDirs.size() + origSystemLibDirs.size() + 1);
        newLibDirs.addAll(origLibDirs);
        newLibDirs.addAll(origSystemLibDirs);

        final Method makeElements = ShareReflectUtil.findMethod(dexPathList, "makePathElements", List.class);

        final Object[] elements = (Object[]) makeElements.invoke(dexPathList, newLibDirs);

        final Field nativeLibraryPathElements = ShareReflectUtil.findField(dexPathList, "nativeLibraryPathElements");
        nativeLibraryPathElements.set(dexPathList, elements);
    }
}

我们在原本的检索路径中，在最前面，即数组为0的位置加入了我们的检索路径，这样一来classloader在查找我们已经动态化的so库的时候，就能够找到！

结束了吗？

一般的so库，比如不依赖其他的so的时候，直接这样加载就没问题了，但是如果存在着依赖的so库的话，就不行了！相信大家在看其他的博客的时候就能看到，是因为Namespace的问题。具体是我们动态库加载的过程中，如果需要依赖其他的动态库，那么就需要一个链接的过程对吧！这里的实现就是Linker，Linker 里检索的路径在创建 ClassLoader 实例后就被系统通过 Namespace 机制绑定了，当我们注入新的路径之后，虽然 ClassLoader 里的路径增加了，但是 Linker 里 Namespace 已经绑定的路径集合并没有同步更新，所以出现了 libxxx.so 文件（当前的so）能找到，而依赖的so 找不到的情况。bugly文章

很多实现都采用了Tinker的实现，既然我们系统的classloader是这样，那么我们在合适的时候把这个替换掉不就可以了嘛！当然bugly团队就是这样做的，但是笔者认为，替换一个classloader显然对于一个普通应用来说，成本还是太大了，而且兼容性风险也挺高的，当然，还有很多方式，比如采用Relinker这个库自定义我们加载的逻辑。

为了不冷饭热炒，嘿嘿，虽然我也喜欢吃炒饭（手动狗头），这里我们就不采用替换classloader的方式，而是采用跟relinker的思想，去进行加载！具体的可以看到sillyboy的实现，其实就不依赖relinker跟tinker，因为我把关键的拷贝过来了，哈哈哈，好啦，我们看下怎么实现吧！不过在此这前，我们需要了解一些前置知识

ELF文件

我们的so库，本质就是一个elf文件，那么so库也符合elf文件的格式，ELF文件由4部分组成，分别是ELF头（ELF header）、程序头表（Program header table）、节（Section）和节头表（Section header table）。实际上，一个文件中不一定包含全部内容，而且它们的位置也未必如同所示这样安排，只有ELF头的位置是固定的，其余各部分的位置、大小等信息由ELF头中的各项值来决定。

那么我们so中，如果依赖于其他的so，那么这个信息存在哪里呢！？没错，它其实也存在elf文件中，不然链接器怎么找嘛，它其实就存在.dynamic段中，所以我们只要找打dynamic段的偏移，就能到dynamic中，而被依赖的so的信息，其实就存在里面啦 我们可以用readelf(ndk中就有toolchains目录后) 查看，readelf -d nativecpptwo.so 这里的 -d 就是查看dynamic段的意思

这里面涉及到动态加载so的知识，可以推荐大家一本书，叫做程序员的自我修养-链接装载与库这里就画个初略图

我们再看下本质，dynamic结构体如下，定义在elf.h中

typedef struct{
Elf32_Sword d_tag;
union{
Elf32_Addr d_ptr;
....
}
}

当d_tag的数值为DT_NEEDED的时候，就代表着依赖的共享对象文件,d_ptr表示所依赖的共享对象的文件名。看到这里读者们已经知道了，如果我们知道了文件名，不就可以再用System.loadLibrary去加载这个文件名确定的so了嘛！不用替换classloader就能够保证被依赖的库先加载！我们可以再总结一下这个方案的原理，如图

比如我们要加载so3，我们就需要先加载so2，如果so2存在依赖，那我们就调用System.loadLibrary先加载so1，这个时候so1就不存在依赖项了，就不需要再调用Linker去查找其他so库了。我们最终方案就是，只要能够解析对应的elf文件，然后找偏移，找到需要的目标项（DT_NEED）所对应的数值（即被依赖的so文件名）就可以了

public List<String> parseNeededDependencies() throws IOException {
    channel.position(0);
    final List<String> dependencies = new ArrayList<String>();
    final Header header = parseHeader();
    final ByteBuffer buffer = ByteBuffer.allocate(8);
    buffer.order(header.bigEndian ? ByteOrder.BIG_ENDIAN : ByteOrder.LITTLE_ENDIAN);

    long numProgramHeaderEntries = header.phnum;
    if (numProgramHeaderEntries == 0xFFFF) {
        /**
         * Extended Numbering
         *
         * If the real number of program header table entries is larger than
         * or equal to PN_XNUM(0xffff), it is set to sh_info field of the
         * section header at index 0, and PN_XNUM is set to e_phnum
         * field. Otherwise, the section header at index 0 is zero
         * initialized, if it exists.
         **/
        final SectionHeader sectionHeader = header.getSectionHeader(0);
        numProgramHeaderEntries = sectionHeader.info;
    }

    long dynamicSectionOff = 0;
    for (long i = 0; i < numProgramHeaderEntries; ++i) {
        final ProgramHeader programHeader = header.getProgramHeader(i);
        if (programHeader.type == ProgramHeader.PT_DYNAMIC) {
            dynamicSectionOff = programHeader.offset;
            break;
        }
    }

    if (dynamicSectionOff == 0) {
        // No dynamic linking info, nothing to load
        return Collections.unmodifiableList(dependencies);
    }

    int i = 0;
    final List<Long> neededOffsets = new ArrayList<Long>();
    long vStringTableOff = 0;
    DynamicStructure dynStructure;
    do {
        dynStructure = header.getDynamicStructure(dynamicSectionOff, i);
        if (dynStructure.tag == DynamicStructure.DT_NEEDED) {
            neededOffsets.add(dynStructure.val);
        } else if (dynStructure.tag == DynamicStructure.DT_STRTAB) {
            vStringTableOff = dynStructure.val; // d_ptr union
        }
        ++i;
    } while (dynStructure.tag != DynamicStructure.DT_NULL);

    if (vStringTableOff == 0) {
        throw new IllegalStateException("String table offset not found!");
    }

    // Map to file offset
    final long stringTableOff = offsetFromVma(header, numProgramHeaderEntries, vStringTableOff);
    for (final Long strOff : neededOffsets) {
        dependencies.add(readString(buffer, stringTableOff + strOff));
    }

    return dependencies;
}

扩展

我们到这里，就能够解决so库的动态加载的相关问题了，那么还有人可能会问，项目中是会存在多处System.load方式的，如果加载的so还不存在怎么办？比如还在下载当中，其实很简单，这个时候我们字节码插桩就派上用场了，只要我们把System.load替换为我们自定义的加载so逻辑，进行一定的逻辑处理就可以了，嘿嘿，因为笔者之前就有写一个字节码插桩的库的介绍，所以在本次就不重复了，可以看Sipder，同时也可以用其他的字节码插桩框架实现，相信这不是一个问题。

总结

看到这里的读者，相信也能够明白动态加载so的步骤了，最后源代码可以在SillyBoy，当然也希望各位点赞呀！当然，有更好的实现也欢迎评论！！

作者：Pika
来源：juejin.cn/post/7107958280097366030

背景说明

原本已经基于系统方案适配了暗黑主题，实现了白/黑两套皮肤，以及跟随系统。后来老板研究学习友商时，发现友商 App 有三套皮肤可选，除了常规的亮白和暗黑，还有一套暗蓝色。并且在跟随系统暗黑模式下，用户可选暗黑还是暗蓝。这不，新的需求马上就来了。

其实我们之前两个 App 的换肤方案都是使用 Android-skin-support 来做的，在此基础上再加套皮肤也不是难事。但在新的 App 实现多皮肤时，由于前两个 App 做了这么久都只有两套皮肤，而且新的 App 需要实现跟随系统，为了更好的体验和较少的代码实现，就采用了系统方案进行适配暗黑模式。

以 Android-skin-support 和系统两种方案适配经验来看，系统方案适配改动的代码更少，所花费的时间当然也就更少了。所以在需要新添一套皮肤的时候，也不可能再去切方案了。那么在使用系统方案的情况下，如何再加一套皮肤呢？来，先看源码吧。

源码分析

以下源码基于 android-31

首先，在代码中获取资源一般通过 Context 对象的一些方法，例如：

// Context.java

@ColorInt
public final int getColor(@ColorRes int id) {
    return getResources().getColor(id, getTheme());
}

@Nullable
public final Drawable getDrawable(@DrawableRes int id) {
    return getResources().getDrawable(id, getTheme());
}