前言

Android Hook 插件化其实已经不是什么新鲜的技术了，不知你有没有想过，支付宝中那么多小软件：淘票票 ，火车票等软件，难道是支付宝这个软件自己编写的吗?那不得写个十年，软件达到几十G，但是并没有，玩游戏时那么多的皮肤包肯定时用户使用哪个就下载哪个皮肤包。

一 未在配置文件中注册的Activity可以启动吗？

       从0学的时候就知道Activity必须在配置文件中注册，否则无法启动且报错。但是Hook告诉你的是，未在配置文件中注册Activity是可以启动的，惊不惊喜？意不意外？

通过本文你可以学到：

1.通过对startActivity方法进行Hook，实现为startActivity方法添加日志。

    1.1 通过对Instrumentation进行Hook

    1.2 通过对AMN进行Hook

2.如何启动一个未在配置文件中注册的Activity实现插件化

本片文章基础建立在 Java反射机制和App启动流程解析，建议不太了解的小伙伴可以先移步至这两篇文章。

二 对startActivity方法进行Hook

    通过对查阅startActivity的源码可以看出startActivity最终都会走到startActivityFoResult方法中

public void startActivityForResult(Intent intent, int requestCode, Bundle options) {

    if(this.mParent == null) {

        ActivityResult ar = this.mInstrumentation.execStartActivity(this, this.mMainThread.getApplicationThread(), this.mToken, this, intent, requestCode, options);

        if(ar != null) {

            this.mMainThread.sendActivityResult(this.mToken, this.mEmbeddedID, requestCode, ar.getResultCode(), ar.getResultData());

        }



        if(requestCode >= 0) {

            this.mStartedActivity = true;

        }

    } else if(options != null) {

        this.mParent.startActivityFromChild(this, intent, requestCode, options);

    } else {

        this.mParent.startActivityFromChild(this, intent, requestCode);

    }



}

通过mInstrumentation.execStartActivity调用（ps：详细的源码解析已在上篇文章中讲解），再看mInstrumentation.execStartActivity方法源码如下：

public Instrumentation.ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options) {

    IApplicationThread whoThread = (IApplicationThread)contextThread;

    if(this.mActivityMonitors != null) {

        Object e = this.mSync;

        synchronized(this.mSync) {

            int N = this.mActivityMonitors.size();



            for(int i = 0; i < N; ++i) {

                Instrumentation.ActivityMonitor am = (Instrumentation.ActivityMonitor)this.mActivityMonitors.get(i);

                if(am.match(who, (Activity)null, intent)) {

                    ++am.mHits;

                    if(am.isBlocking()) {

                        return requestCode >= 0?am.getResult():null;

                    }

                    break;

                }

            }

        }

    }



    try {

        intent.setAllowFds(false);

        intent.migrateExtraStreamToClipData();

        int var16 = ActivityManagerNative.getDefault().startActivity(whoThread, intent, intent.resolveTypeIfNeeded(who.getContentResolver()), token, target != null?target.mEmbeddedID:null, requestCode, 0, (String)null, (ParcelFileDescriptor)null, options);

        checkStartActivityResult(var16, intent);

    } catch (RemoteException var14) {

        ;

    }



    return null;

}

最终会交给 int var16 = ActivityManagerNative.getDefault().startActivity(whoThread, intent,...处理，所以如果我们想对startActivity方法进行Hook，可以从这两个地方入手（其实不止这两个地方，我们只讲解着两个地方，下面使用的反射封装类也在上篇文章中给出）。

•  2.1 对mInstrumentation进行Hook

  在Activity.class类中定义了私有变量

private Instrumentation mInstrumentation;

我们首先要做的就是修改这个私有变量的值，在执行方法前打印一行日志，首先我们通过反射来获取这一私有变量。

Instrumentation instrumentation = (Instrumentation) Reflex.getFieldObject(Activity.class,MainActivity.this,"mInstrumentation");

我们要做的是将这个Instrumentation替换成我们自己的Instrumentation，所以下面我们新建MyInstrumentation继承自Instrumentation，并且MyInstrumentation的execStartActivity方法不变。

public class MyInstrumentation extends Instrumentation {



    private Instrumentation instrumentation;



    public MyInstrumentation(Instrumentation instrumentation) {

        this.instrumentation = instrumentation;

    }



    public  ActivityResult execStartActivity(Context who, IBinder contextThread, IBinder token, Activity target, Intent intent, int requestCode, Bundle options) {





        Log.d("-----","啦啦啦我是hook进来的!");

        Class[] classes = {Context.class,IBinder.class,IBinder.class,Activity.class,Intent.class,int.class,Bundle.class};

        Object[] objects = {who,contextThread,token,target,intent,requestCode,options};

        Log.d("-----","啦啦啦我是hook进来的!!");

        return (ActivityResult) Reflex.invokeInstanceMethod(instrumentation,"execStartActivity",classes,objects);



    }

我们直接通过反射调用这个方法 参数就是 Class[] classes = {Context.class,IBinder.class,IBinder.class,Activity.class,Intent.class,int.class,Bundle.class}与方法名中一致

(ActivityResult) Reflex.invokeInstanceMethod(instrumentation,"execStartActivity",classes,objects)

如果我们这里不调用它本身的execStartActivity方法的话，那么startActivity就无效了。

然后我们将自定义的替换为原来的Instrumentation

Reflex.setFieldObject(Activity.class,this,"mInstrumentation",instrumentation1);

完整代码就是

Instrumentation instrumentation = (Instrumentation) Reflex.getFieldObject(Activity.class,MainActivity.this,"mInstrumentation");

MyInstrumentation instrumentation1 = new MyInstrumentation(instrumentation);

Reflex.setFieldObject(Activity.class,this,"mInstrumentation",instrumentation1);

   运行日志如下：

这个时候我们就成功的Hook了startActivity方法

2.2 对AMN进行Hook

execStartActivity方法最终会走到ActivityManagerNative.getDefault().startActivity方法

try {

    intent.setAllowFds(false);

    intent.migrateExtraStreamToClipData();

    int var16 = ActivityManagerNative.getDefault().startActivity(whoThread, intent, intent.resolveTypeIfNeeded(who.getContentResolver()), token, target != null?target.mEmbeddedID:null, requestCode, 0, (String)null, (ParcelFileDescriptor)null, options);

    checkStartActivityResult(var16, intent);

} catch (RemoteException var14) {

    ;

}

你可能会说上面说过了啊，替换ActivityManagerNative.getDefault()，重写startActivity方法，我们来看ActivityManagerNative.getDefault()

public static IActivityManager getDefault() {

    return (IActivityManager)gDefault.get();

}

public final T get() {

    synchronized(this) {

        if(this.mInstance == null) {

            this.mInstance = this.create();

        }



        return this.mInstance;

    }

}

可以看出IActivityManager是一个接口，gDefault.get()返回的是一个泛型，上述方案我们无法入手，所以我们这里要用动态代理方案

我们定义一个AmsHookHelperUtils类，在AmsHookHelperUtils类中处理反射代码

gDefault是个final静态类型的字段，首先我们获取gDefault字段

Object gDefault = Reflex.getStaticFieldObject("android.app.ActivityManagerNative","gDefault");

gDefault是 Singleton<IActivityManager>类型的对象，Singleton是一个单例模式

public abstract class Singleton<T> {

    private T mInstance;



    public Singleton() {

    }



    protected abstract T create();



    public final T get() {

        synchronized(this) {

            if(this.mInstance == null) {

                this.mInstance = this.create();

            }



            return this.mInstance;

        }

    }

}

接下里我们来取出mInstance字段

Object mInstance = Reflex.getFieldObject("android.util.Singleton",gDefault,"mInstance");

然后创建一个代理对象

Class<?> classInterface = Class.forName("android.app.IActivityManager");

Object proxy = Proxy.newProxyInstance(classInterface.getClassLoader(),

        new Class<?>[]{classInterface},new AMNInvocationHanlder(mInstance));

我们的代理对象就是new AMNInvocationHanlder(mInstance)，（ps：代理模式分为静态代理和动态代理，如果对代理模式不了解可以百度一波，也可以关注我，等待我的代理模式相关文章）

public class AMNInvocationHanlder implements InvocationHandler {





    private String actionName = "startActivity";



    private Object target;



    public AMNInvocationHanlder(Object target) {

        this.target = target;

    }



    @Override

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {



        if (method.getName().equals(actionName)){

            Log.d("---","啦啦啦我是hook AMN进来的");

            return method.invoke(target,args);

        }



        return method.invoke(target,args);

    }

}

所有的代理类都要实现InvocationHandler接口，在invoke方法中method.invoke(target,args);表示的就是 执行被代理对象所对应的方法。因为AMN Singleton做的事情比较多，所以这里只对startActivity方法hook

if (method.getName().equals(actionName)){

    Log.d("---","啦啦啦我是hook AMN进来的");

    return method.invoke(target,args);

}

然后我们将gDefault字段替换为我们的代理类

Reflex.setFieldObject("android.util.Singleton",gDefault,"mInstance",proxy);

AmsHookHelperUtils方法整体如下：

public class AmsHookHelperUtils {



    public static void hookAmn() throws ClassNotFoundException {

        Object gDefault = Reflex.getStaticFieldObject("android.app.ActivityManagerNative","gDefault");

        Object mInstance = Reflex.getFieldObject("android.util.Singleton",gDefault,"mInstance");



        Class<?> classInterface = Class.forName("android.app.IActivityManager");

        Object proxy = Proxy.newProxyInstance(classInterface.getClassLoader(),

                new Class<?>[]{classInterface},new AMNInvocationHanlder(mInstance));

        Reflex.setFieldObject("android.util.Singleton",gDefault,"mInstance",proxy);

    }

}

我们调用AmsHookHelperUtils.hookAmn();然后启动一个新的Activity，运行日志如下:

这样我们就成功Hook了AMN的getDefault方法。

2.3 如何启动一个未注册的Activity

    如何启动一个未注册的Activity，首先我们了解Activity的启动流程，App的启动流程已经在上篇文章中讲解了，APP启动流程解析,还不了解的小伙伴，可先移步至上篇文章。假设现在MainActivity，Main2Activity，Main3Activity，其中Main3Activity未注册，我们在MainActivity中启动Main3Activity,当启动Main3Activity的时候，AMS会在配置文件中检查，是否有Main3Activity的配置信息如果不存在则报错，存在则启动Main3Activity。

    所以我们可以做的是，将要启动的Activity发送给AMS之前，将要启动的Activity替换未已经注册Activity Main2Activity，这样AMS就可以检验通过，当AMS要启动目标Activity的时候再将Main2Activity替换为真正要启动的Activity。

   首先我们按照上面逻辑先对startActivity方法进行Hook，这里采用对AMN Hook的方式。和上述代码一样，不一样的地方在于mInstance的代理类不同。

  新建一个AMNInvocationHanlder1对象同样继承自InvocationHandler，只拦截startActivity方法。

if (method.getName().equals(actionName)){}

在这里我们要做的就是将要启动的Main3Activity替换为Main2Activity，这样能绕过AMS的检验，首先我们从目标方法中取出目标Activity。

Intent intent;

int index = 0;

for (int i = 0;i<args.length;i++){

    if (args[i] instanceof Intent){

        index = i;

        break;

    }

}

你可能会问你怎么知道args中一定有intent类的参数，因为invoke方法中最终会执行

return method.invoke(target,args);

表示会执行原本的方法，而我们来看原本的startActivity方法如下：

int var16 = ActivityManagerNative.getDefault().startActivity(whoThread, intent, intent.resolveTypeIfNeeded(who.getContentResolver()), token, target != null?target.mEmbeddedID:null, requestCode, 0, (String)null, (ParcelFileDescriptor)null, options);

所以我们说args中肯定有个intent类型的参数，获取真实目标Activity之后，我们获取目标的包名

intent = (Intent) args[index];

String packageName = intent.getComponent().getPackageName();

新建一个Intent 将intent设置为 冒充者Main2Activity的相关信息

Intent newIntent = new Intent();

ComponentName componentName = new ComponentName(packageName,Main2Activity.class.getName());

newIntent.setComponent(componentName);

args[index] = newIntent;

这样目标Activity就被替换成了Main2Activity，不过这个冒充者还要将原本的目标携带过去，等待真正打开的时候再替换回来，否则就真的启动这个冒充者了

newIntent.putExtra(AmsHookHelperUtils.TUREINTENT,intent);

这个时候我们调用这个方法什么都不做，这个时候启动Main3Activity

startActivity(new Intent(this,Main3Activity.class));

显示的其实是Main2Activity，如图所示：

这样说明我们的冒充者已经成功替换了真实目标，所以我们接下来要在启动的时候，将冒充者再重新替换为目标者，ActivityThread通过mH发消息给AMS

synchronized(this) {

    Message msg = Message.obtain();

    msg.what = what;

    msg.obj = obj;

    msg.arg1 = arg1;

    msg.arg2 = arg2;

    this.mH.sendMessage(msg);

}

AMS收到消息后进行处理

public void handleMessage(Message msg) {

    ActivityThread.ActivityClientRecord data;

    switch(msg.what) {

    case 100:

        Trace.traceBegin(64L, "activityStart");

        data = (ActivityThread.ActivityClientRecord)msg.obj;

        data.packageInfo = ActivityThread.this.getPackageInfoNoCheck(data.activityInfo.applicationInfo, data.compatInfo);

        ActivityThread.this.handleLaunchActivity(data, (Intent)null);

        Trace.traceEnd(64L);

mH是Handler类型的消息处理类，所以sendMessage方法会调用callback，Handler消息处理机制可看我之前一篇博客

深入理解Android消息机制，所以我们可以对callback字段进行Hook。如果不明白怎么办？关注我！

新建hookActivityThread方法，首先我们获取当前的ActivityThread对象

Object currentActivityThread = Reflex.getStaticFieldObject("android.app.ActivityThread", "sCurrentActivityThread");

然后获取对象的mH对象

Handler mH = (Handler) Reflex.getFieldObject(currentActivityThread, "mH");

将mH替换为我们的自己自定义的MyCallback。

Reflex.setFieldObject(Handler.class, mH, "mCallback", new MyCallback(mH));

自定义MyCallback首先 Handler.Callback接口，重新处理handleMessage方法

@Override

public boolean handleMessage(Message msg) {



    switch (msg.what) {

      

        case 100:

            handleLaunchActivity(msg);

            break;

        default:

            break;



    }



    mBase.handleMessage(msg);

    return true;

}

我们获取传递过来的目标对象

Object obj = msg.obj;

Intent intent = (Intent) Reflex.getFieldObject(obj, "intent");

然后从目标对象中取出携带过来的真实对象，并将intent修改为真实目标对象的信息，这样就可以启动真实的目标Activity

Intent targetIntent = intent.getParcelableExtra(AmsHookHelperUtils.TUREINTENT);

intent.setComponent(targetIntent.getComponent());

MyCallbackt如下

**

 * Created by Huanglinqing on 2019/4/30.

 */



public class MyCallback implements Handler.Callback {



    Handler mBase;



    public MyCallback(Handler base) {

        mBase = base;

    }



    @Override

    public boolean handleMessage(Message msg) {



        switch (msg.what) {

         

            case 100:

                handleLaunchActivity(msg);

                break;

            default:

                break;



        }



        mBase.handleMessage(msg);

        return true;

    }



    private void handleLaunchActivity(Message msg) {

    

        Object obj = msg.obj;

        Intent intent = (Intent) Reflex.getFieldObject(obj, "intent");

        Intent targetIntent = intent.getParcelableExtra(AmsHookHelperUtils.TUREINTENT);

        intent.setComponent(targetIntent.getComponent());

    }



}

这个时候再启动未注册的Main3Activity，就可以成功启动了

startActivity(new Intent(this,Main3Activity.class));

这样我们就成功的启动了未注册Activity

介绍

今天使用Idea写代码的时候，看到之前的项目中显示有warning的提示，去看了下，是如下代码?

@Autowire

private JdbcTemplate jdbcTemplate;

提示的警告信息

Field injection is not recommended Inspection info: Spring Team recommends: "Always use constructor based dependency injection in your beans. Always use assertions for mandatory dependencies".

这段是Spring工作组的建议，大致翻译一下：

属性字段注入的方式不推荐，检查到的问题是：Spring团队建议:"始终在bean中使用基于构造函数的依赖项注入，始终对强制性依赖项使用断言"

如图

Field注入警告

注入方式

虽然当前有关Spring Framework（5.0.3）的文档仅定义了两种主要的注入类型，但实际上有三种:

基于构造函数的依赖注入

public class UserServiceImpl implents UserService{

    private UserDao userDao;

    

    @Autowire

    public UserServiceImpl(UserDao userDao){

        this.userDao = userDao;

    }

}

基于Setter的依赖注入

public class UserServiceImpl implents UserService{

     private UserDao userDao;

     

     @Autowire

     public serUserDao(UserDao userDao){

         this.userDao = userDao;

     }

 }

基于字段的依赖注入

public class UserServiceImpl implents UserService{

     @Autowire

     private UserDao userDao;

 }

基于字段的依赖注入方式会在Idea当中吃到黄牌警告，但是这种使用方式使用的也最广泛，因为简洁方便.您甚至可以在一些Spring指南中看到这种注入方法，尽管在文档中不建议这样做.(有点执法犯法的感觉)

如图

Spring自己的文档

基于字段的依赖注入缺点

对于有final修饰的变量不好使

Spring的IOC对待属性的注入使用的是set形式，但是final类型的变量在调用class的构造函数的这个过程当中就得初始化完成，这个是基于字段的依赖注入做不到的地方．只能使用基于构造函数的依赖注入的方式

掩盖单一职责的设计思想

我们都知道在OOP的设计当中有一个单一职责思想，如果你采用的是基于构造函数的依赖注入的方式来使用Spring的IOC的时候，当你注入的太多的时候，这个构造方法的参数就会很庞大，类似于下面.

当你看到这个类的构造方法那么多参数的时候，你自然而然的会想一下:这个类是不是违反了单一职责思想?.但是使用基于字段的依赖注入不会让你察觉，你会很沉浸在@Autowire当中

public class VerifyServiceImpl implents VerifyService{

    

  private AccountService accountService;

  private UserService userService;

  private IDService idService;

  private RoleService roleService;

  private PermissionService permissionService;

  private EnterpriseService enterpriseService;

  private EmployeeService employService;

  private TaskService taskService;

  private RedisService redisService;

  private MQService mqService;



  public SystemLogDto(AccountService accountService, 

                      UserService userService, 

                      IDService idService, 

                      RoleService roleService, 

                      PermissionService permissionService, 

                      EnterpriseService enterpriseService, 

                      EmployeeService employService, 

                      TaskService taskService, 

                      RedisService redisService, 

                      MQService mqService) {

      this.accountService = accountService;

      this.userService = userService;

      this.idService = idService;

      this.roleService = roleService;

      this.permissionService = permissionService;

      this.enterpriseService = enterpriseService;

      this.employService = employService;

      this.taskService = taskService;

      this.redisService = redisService;

      this.mqService = mqService;

  }

}

与Spring的IOC机制紧密耦合

当你使用基于字段的依赖注入方式的时候，确实可以省略构造方法和setter这些个模板类型的方法，但是，你把控制权全给Spring的IOC了，别的类想重新设置下你的某个注入属性，没法处理(当然反射可以做到).

本身Spring的目的就是解藕和依赖反转，结果通过再次与类注入器（在本例中为Spring）耦合，失去了通过自动装配类字段而实现的对类的解耦，从而使类在Spring容器之外无效.

隐藏依赖性

当你使用Spring的IOC的时候，被注入的类应当使用一些public类型(构造方法，和setter类型方法)的方法来向外界表达:我需要什么依赖.但是基于字段的依赖注入的方式，基本都是private形式的，private把属性都给封印到class当中了.

无法对注入的属性进行安检

基于字段的依赖注入方式，你在程序启动的时候无法拿到这个类，只有在真正的业务使用的时候才会拿到，一般情况下，这个注入的都是非null的，万一要是null怎么办，在业务处理的时候错误才爆出来，时间有点晚了，如果在启动的时候就暴露出来，那么bug就可以很快得到修复(当然你可以加注解校验).

如果你想在属性注入的时候，想根据这个注入的对象操作点东西，你无法办到．我碰到过的例子：一些配置信息啊，有些人总是会配错误，等到了自己测试业务阶段才知道配错了，例如线程初始个数不小心配置成了3000，机器真的是狂叫啊!这个时候就需要再某些Value注入的时候做一个检测机制.

结论

通过上面，我们可以看到，基于字段的依赖注入方式有很多缺点,我们应当避免使用基于字段的依赖注入.推荐的方法是使用基于构造函数和基于setter的依赖注入.对于必需的依赖项，建议使用基于构造函数的注入，以使它们成为不可变的，并防止它们为null。对于可选的依赖项，建议使用基于Setter的注入

以下所有设计图均来自网络，如有侵权，请联系我删除，感谢各位分享~

本人最喜欢的一张😎：（大家在评论区投票选出最喜欢的一张吧）

按钮的圆角让我看了真的是身心愉悦，简约却又不是高雅！ 

其他的十九张😍：

1.这一款我也是吹爆，层次非常明显，颜色令人舒适，各位觉得怎么样呢？

2.这张就是经典款，左侧突出自己网页的主题，右侧是一个简约的登录，这张非常实用，只需将左侧的图片一换即可！

3. 这就很像校园的网站，这样的配色突出校园青春气息，登录框与背景的交叠凸显层次

4.这一款可是上榜2020年6月的设计榜，层次相当丰富，主题也很突出，不愧是上榜的作品

5.哇塞当时看到这一款的时候，我是惊讶到的，这款色彩和层次是真的丰富🤩！！！

6.这款也是相当的好，一款卡通风格的旅游网页，用于游戏的官网也可以（例如原神），个人很喜欢

7.这篇也是很通用的网页，不过右边的圆角登录框也是比较有特色的

8.这一款乍一看很普通，但是当你关注到了细节时，它的背景分块真的是很好，爱了爱了

9.这一款是相较于其他有很大不同的，它更多的是在展示自己的界面美，没有去注意功能的突出，这样别具一格的其实也很不错！

10.以蓝色为底色，利用圆角层次分明，也突出了功能，很适合电商网页

11.这一款除了背景有点留白太多，其他还是很不错的，换一下背景就可以直接商用了~

12.也是一如往常的好，乍一看是很常规，但是当你细看的时候，它对于输入框的处理还是很到位的

13.这一款就比较有特色的，左侧一个轮播图用于展示网页与业务的特点，右侧的输入框与背景交叠丰富了层次，很棒的作品！

14.这款就是介绍自己app的一个网页，也是很不错，但是不知道为啥图片有点糊😭

15.这款黑色与紫色交融，满满的高级感！

16.这一款也在设计榜上，不过，我水平不够，没有欣赏到它的美，蓝色的底色(好了我真是编不下去啦哈哈,原作者看到的话不要打我，这只能证明我的审美不够)

17.漫威蜘蛛侠咱就不用多说了吧，懂得都懂，5星通过👌

18.唯美风格，相当舒服了，很适合一些助睡眠的网页🌙

19.外星风格，我觉得可以卖玩具了哈哈😝

每一张都是设计师辛辛苦苦设计的，每一张都很棒，感谢！！！

我们对 DiffUtil 的使用可能被带偏了

前面都是我的流水账, 觉得看起来很没劲的, 可以直接跳转到本质小节,.

DiffUtil 的优势

我在最初接触 DiffUtil 时, 心中便对它有颇多的好感, 包括:

1. 算法听提来就很nb, 一定是个好东西;


2. 简化了 RecyclerView 的刷新逻辑, 无须关心该调用 notifyItemInserted 还是 notifyItemChanged, 一律submitList 就完事了(虽然 notifyDataSetChanged 也能做到, 但是性能拉胯, 而且没有动画);


3. LiveData 或者 Flow 监听单一 List 数据源时, 往往很难知道, 整个 List 中到底哪些数据项被更新了, 只能调用notifyDataSetChanged 方法, 而 DiffUtil 恰好就能解决这个问题, 无脑 submitList 就完事了.

DiffUtil 代码示例

使用 DiffUtil 时, 代码大致如下:

data class Item (

    var id: Long = 0,

    var data: String = ""

)



class DiffAdapter : RecyclerView.Adapter<DiffAdapter.MyViewHolder>() {

    // AsyncListDiffer 类位于 androidx.recyclerview.widget 包下

    // 这里以 AsyncListDiffer 的使用来举例, 使用 ListAdapter 或者直接用 DiffUtil, 也存在后面的问题

    private val differ = AsyncListDiffer<Item>(this, object : DiffUtil.ItemCallback<Item>() {

        override fun areItemsTheSame(oldItem: Item, newItem: Item): Boolean {

            return oldItem.id == newItem.id

        }



        override fun areContentsTheSame(oldItem: Item, newItem: Item): Boolean {

            // Kotlin中的 == 运算符, 相当于 Java 中调用 equals 方法

            return oldItem == newItem

        }



        private val payloadResult = Any()

        override fun getChangePayload(oldItem: Item, newItem: Item): Any {

            // payload 用于Item局部字段更新的时候使用,具体用法可以自行搜索了解

            // 当检测到同一个Item有更新时, 会调用此方法

            // 此方法默认返回null, 此时会触发Item的更新动画, 表现为Item会闪一下

            // 当返回值不为null时, 可以关闭Item的更新动画

            return payloadResult

        }

    })



    class MyViewHolder(val view: View):RecyclerView.ViewHolder(view){

        private val dataTv:TextView by lazy{ view.findViewById(R.id.dataTv) }

        fun bind(item: Item){

            dataTv.text = item.data

        }

    }



    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): MyViewHolder {

        return MyViewHolder(LayoutInflater.from(parent.context).inflate(

            R.layout.item_xxx,

            parent,

            false

        ))

    }



    override fun onBindViewHolder(holder: MyViewHolder, position: Int) {

        holder.bind(differ.currentList[position])

    }



    override fun getItemCount(): Int {

        return differ.currentList.size

    }

    

    public fun submitList(newList: List<Item>) {

        differ.submitList(newList)

    }

}



val dataList = mutableListOf<Item>(item1, item2)

differ.submitList(dataList)

以上代码的关键在于以下两个方法的实现, 作用分别是:

• areItemsTheSame(oldItem: Item, newItem: Item) :比较两个 Item 是否表示同一项数据;


• areContentsTheSame(oldItem: Item, newItem: Item) :比较两个 Item 的数据是否相同.

DiffUtil 的踩坑过程

上述示例代码很看起来简单, 也比较好理解, 当我们尝试添加一条数据时:

val dataList = mutableListOf<Item>(item1, item2)

differ.submitList(dataList)



// 增加数据

dataList.add(item3)

differ.submitList(dataList)

发现 item3 并未在界面上显示出来, 怎么回事呢? 我们来看 AsyncListDiffer 关键代码的实现:

public void submitList(@Nullable final List<T> newList) {

    submitList(newList, null);

}



public void submitList(@Nullable final List<T> newList, @Nullable final Runnable commitCallback) {

    // ...省略无关代码

    // 注意这里是 Java 代码, 正在比较 newList 与 mList 是否为同一个引用

    if (newList == mList) {

        // nothing to do (Note - still had to inc generation, since may have ongoing work)

        if (commitCallback != null) {

            commitCallback.run();

        }

        return;

    }

    // ...省略无关代码



    mConfig.getBackgroundThreadExecutor().execute(new Runnable() {

        @Override

        public void run() {

            final DiffUtil.DiffResult result = DiffUtil.calculateDiff(new DiffUtil.Callback() {

                // ...省略 newList 和 mList 的 Diff 算法比较代码

            });



            // ...省略无关代码

            mMainThreadExecutor.execute(new Runnable() {

                @Override

                public void run() {

                    if (mMaxScheduledGeneration == runGeneration) {

                        latchList(newList, result, commitCallback);

                    }

                }

            });

        }

    });

}



void latchList(

        @NonNull List<T> newList,

        @NonNull DiffUtil.DiffResult diffResult,

        @Nullable Runnable commitCallback) {

    // ...省略无关代码

    mList = newList;

    // 将结果更新到具体的

    diffResult.dispatchUpdatesTo(mUpdateCallback);

    // ...省略无关代码

}

可以看到, 单参数的 submitList 方法会调用 双参数的 submitList 方法, 重点在于双参数的submitList 方的实现:

• 首先检查新提交的 newList 与内部持有的 mList 的引用是否相同, 如果相同, 就直接返回;


• 如果不同的引用, 就对 newList 和 mList 做 Diff 算法比较, 并生成比较结果 DiffUtil.DiffResult;


• 最后通过 latchList 方法将 newList 赋值给 mList , 并将 Diff 算法的结果 DiffUtil.DiffResult 应用给 mUpdateCallback.

最后的 mUpdateCallback, 其实就是上述示例代码中, 创建 AsyncListDiffer 对象时, 传入的 RecyclerView.Adapter 对象, 这里就不贴代码了.

浅拷贝

分析代码后, 我们可以知道, 每次 submitList 时, 必须传入不同的 List 对象, 否者方法内部不会做 Diff 算法比较, 而是直接返回, 界面也不会刷新. 需要要不同的 List 是吧? 哪还不简单, 我创建一个新的 List 不就行了?

于是我们修改一下 submitList 方法:

class DiffAdapter : RecyclerView.Adapter<DiffAdapter.MyViewHolder>() {

    private val differ = AsyncListDiffer<Item>(this, object : DiffUtil.ItemCallback<Item>() {

        override fun areItemsTheSame(oldItem: Item, newItem: Item): Boolean {

            return oldItem.id == newItem.id

        }



        override fun areContentsTheSame(oldItem: Item, newItem: Item): Boolean {

            return oldItem == newItem

        }

    })



    // ...省略无关代码



    public fun submitList(newList: List<Item>) {

        // 创建一个新的 List, 再调用 submitList

        differ.submitList(newList.toList())

    }

}

相应的测试代码也变成了:

val diffAdapter = ...

val dataList = mutableListOf<Item>(item1, item2)

diffAdapter.submitList(dataList)



// 增加数据

dataList.add(item3)

diffAdapter.submitList(dataList)



// 删除数据

dataList.removeAt(0)

diffAdapter.submitList(dataList)



// 更新数据

dataList[1].data = "最新的数据"

diffAdapter.submitList(dataList)

运行代码后发现, 单独运行"增加数据"和"删除数据"的测试代码, 表现都是正常的, 唯独"更新数据"单独运行时, 界面毫无反应.

其实仔细想想也能明白, 虽然我们调用 differ.submitList(newList.toList()) 方法时, 确实对 List 做了一份拷贝, 但却是浅拷贝, 真正在运行 Diff 算法比较时, 其实是同一个 Item 对象在自己和自己比较(areContentsTheSame 方法参数的 oldItem 和 newItem 为同一个对象引用), 也就判定为没有数据更新.

data class 的 copy

有的同学,可能有话要说: "你应该在更新 data 字段时, 应该调用 copy 方法, 拷贝一个新的对象, 更新新的值后, 再把原始的 Item 替换掉!".

于是就有了以下代码:

val diffAdapter = ...

val dataList = mutableListOf<Item>(item1, item2)

diffAdapter.submitList(dataList)



// 更新数据

dataList[0] = dataList[0].copy(data = "最新的数据")

diffAdapter.submitList(dataList)

运行代码后, "更新数据"也变得正常了, 当业务比较简单时, 也就到此为止了, 没有新的坑来踩了. 但如果业务比较复杂时, 更新数据的代码可能是这样的:

data class InnerItem(

    val innerData: String = ""

)

data class Item(

    val id: Long = 0,

    val data: String = "",

    val innerItem: InnerItem = InnerItem()

)



val diffAdapter = ...

val dataList = mutableListOf<Item>(item1, item2)

diffAdapter.submitList(dataList)



// 更新数据

val item = dataList[0]

// 内部的数据也不能直接赋值, 需要拷贝一份, 否者和上面的情况类似了

val innerNewItem = item.innerItem.copy(innerData = "内部最新的数据")

dataList[0] = item.copy(innerItem = innerNewItem)

diffAdapter.submitList(dataList)

好像稍微有些复杂的样子, 那如果我们嵌套再深一些呢? 我里面还嵌套了一个List呢? 就要依次递归copy, 代码好像就比较复杂了.

此时我们再回想起开篇提到的 DiffUtil 第 2 点优势要打个疑问了. 本来以为会简化代码, 反而使代码变得更复杂了, 我还不如手动赋值, 然后自己去调用 notifyItemXxx , 代码怕是要简单一些.

深拷贝

于是乎, 为了避免递归copy, 导致更新数据的代码变得过于复杂, 就有了深拷贝的方案. 我管你套了几层, 我先深拷贝一份, 我直接对深拷贝的数据进行修改, 然后直接设置回去, 代码如下:

data class InnerItem(

    var innerData: String = ""

)

data class Item(

    val id: Long = 0,

    var data: String = "",

    var innerItem: InnerItem = InnerItem()

)





val diffAdapter = ...

val dataList = mutableListOf<Item>(item1, item2)

diffAdapter.submitList(dataList)



// 更新数据

dataList[0] = dataList[0].deepCopy().apply { 

    innerItem.innerData = "内部最新的数据"

}

diffAdapter.submitList(dataList)

代码看上去又变得简洁了许多, 我们的关注点又来到了深拷贝的如何实现:

利用 Serializable 或者 Parcelable 即可实现对象深拷贝, 具体可自行搜索.

• 使用 Serializable, 代码看起来比较简单, 但是性能稍差;


• 使用 Parcelable, 性能好, 但是需要生成更多额外的代码, 看起来不够简洁;

其实选择 Serializable 或者 Parcelable 都无所谓, 看个人喜好即可. 关键在于实现了 Serializable 或者 Parcelable 接口后, Item 中的数据类型会被限制, 要求 Item 中所有的直接或间接字段也必须实现 Serializable Parcelable 接口, 否者就会序列化失败.

比如说, Item 中就不能声明类型为 android.text.SpannableString 的字段(用于显示富文本), 因为 SpannableString 既没有实现 Serializable 接口, 也没有实现 Parcelable 接口.

本质

回过头去, 我们再来审视一下 DiffUtil 两个核心方法:

• areItemsTheSame(oldItem: Item, newItem: Item) : 比较两个 Item 是否表示同一项数据;


• areContentsTheSame(oldItem: Item, newItem: Item) : 比较两个 Item 的数据是否相同.

先问个问题, 这两个方法分别为了实现什么目的呢, 或者说他们在算法中起的作用是什么?

简单, 就算不懂 DiffUtil 算法实现(其实是我不懂 o(￣▽￣)o ), 也能猜到, 仅凭 areItemsTheSame 方法我们就能实现以下三种操作:

• itemRemove


• itemInsert


• itemMove

而最后一种 itemChange 操作, 需要 areItemsTheSame 方法先返回 true, 然后调用 areContentsTheSame 方法返回 false, 才能判定为 itemChange 操作, 这也和此方法的注释说明相对应:

This method is called only if {@link #areItemsTheSame(T, T)} returns {@code true} for these items.

所以, areContentsTheSame 方法的作用, 仅仅是为了判定 Item 用于界面显示的部分是否有更新, 而不一定需要调用 equals 方法来全量比较两个item的所有字段. 其实 areContentsTheSame 方法的代码注释也有说明:

This method to check equality instead of {@link Object#equals(Object)} so that you can change its behavior depending on your UI.

For example, if you are using DiffUtil with a {@link RecyclerView.Adapter RecyclerView.Adapter}, you should return whether the items' visual representations are the same.

你会发现, 网上很多教程的代码示例就是用的 equals 来判定数据是否被修改, 然后基于 equals 的比较前提, 更新数据的时候, 又是递归copy, 又是深拷贝, 其实是被带偏了, 思想被限制住了.

改进办法

既然 areItemsTheSame 方法仅用于判定 Item 用于显示的部分是否有更新, 从而判定 itemChange 操作, 那我们完全可以新起一个 contentId 字段, 用于标识内容的唯一性, areItemsTheSame 方法的实现也仅比较 contentId , 代码看起来像这样:

private val contentIdCreator = AtomicLong()

abstract class BaseItem(

    open val id: Long,

    val contentId: Long = contentIdCreator.incrementAndGet()

)

data class InnerItem(

    var innerData: String = ""

)

data class ItemImpl(

    override val id: Long,

    var data: String = "",

    var innerItem: InnerItem = InnerItem()

) : BaseItem(id)



class DiffAdapter : RecyclerView.Adapter<DiffAdapter.MyViewHolder>() {

    private val differ = AsyncListDiffer<Item>(this, object : DiffUtil.ItemCallback<Item>() {

        override fun areItemsTheSame(oldItem: Item, newItem: Item): Boolean {

            return oldItem.id == newItem.id

        }



        override fun areContentsTheSame(oldItem: Item, newItem: Item): Boolean {

            // contentId不一致时, 就认为此Item数据有更新

            return oldItem.contentId == newItem.contentId

        }

        

        private val payloadResult = Any()

        override fun getChangePayload(oldItem: Item, newItem: Item): Any {

            // payload 用于Item局部字段更新的时候使用,具体用法可以自行搜索了解

            // 当检测到同一个Item有更新时, 会调用此方法 

            // 此方法默认返回null, 此时会触发Item的更新动画, 表现为Item会闪一下

            // 当返回值不为null时, 可以关闭Item的更新动画

            return payloadResult

        }

    })



    // ... 省略无关代码



    public fun submitList(newList: List<Item>) {

        // 创建新的List的浅拷贝, 再调用submitList

        differ.submitList(newList.toList())

    }

}





val diffAdapter: DiffAdapter = ...

val dataList = mutableListOf<Item>(item1, item2)

diffAdapter.submitList(dataList)



// 更新数据

// 仅需copy外层的数据,保证contentId不一致即可, 内部嵌套的数据仅需直接赋值即可

// 由于ItemImpl继承自BaseItem, 当执行ItemImpl.copy方法时, 会调用父类BaseItem的构造方法, 生成新的contentId

dataList[0] = dataList[0].copy().apply { 

    data = "最新的数据"

    innerItem.innerData = "内部最新的数据"

}

diffAdapter.submitList(dataList)

因为 areContentsTheSame 方法执行时,需要不同的两个对象比较,所以有字段更新时,还是需要通过 copy 方法生成新的对象.

这种方式存在误判的可能, 因为 ItemImpl 中的一些字段的更新可能不会影响到界面的显示, 此时 areContentsTheSame 方法应该返回 false. 但个人认为这种情况是少数, 误判是可以接受的, 代价仅仅只会额外多更新了一次界面 item 而已.

其实, 了解了本质后, 我们还可以根据自己的业务需求按自己的方式来定制. 比如说用Java该怎么办? 我们也许可以这么做:

class Item{

    int id;

    boolean isUpdate; // 此字段用于标记此Item是否有更新

    String data;

}



class JavaDiffAdapter extends RecyclerView.Adapter<JavaDiffAdapter.MyViewHolder>{

    public void submitList(List<Item> dataList){

        differ.submitList(new ArrayList<>(dataList));

    }

    @NonNull

    @Override

    public MyViewHolder onCreateViewHolder(@NonNull ViewGroup parent, int viewType) {

        return new MyViewHolder(LayoutInflater.from(parent.getContext()).inflate(

                R.layout.item_xxx, 

                parent,

                false

        ));

    }

    @Override

    public void onBindViewHolder(@NonNull MyViewHolder holder, int position) {

        // 绑定一次数据后, 将需要更新的标识赋值为false

        differ.getCurrentList().get(position).isUpdate = false;

        holder.bind(differ.getCurrentList().get(position));

    }

    @Override

    public int getItemCount() {

        return differ.getCurrentList().size();

    }

    class MyViewHolder extends RecyclerView.ViewHolder{

        private TextView dataTv;

        public MyViewHolder(View itemView) {

            super(itemView);

            dataTv = itemView.findViewById(R.id.dataTv);

        }

        private void bind(Item item){

            dataTv.setText(item.data);

        }

    }

    private AsyncListDiffer<Item> differ = new AsyncListDiffer<Item>(this, new DiffUtil.ItemCallback<Item>() {

        @Override

        public boolean areItemsTheSame(@NonNull Item oldItem, @NonNull Item newItem) {

            return oldItem.id == newItem.id;

        }

        @Override

        public boolean areContentsTheSame(@NonNull Item oldItem, @NonNull Item newItem) {

            // 通过读取isUpdate来确定数据是否有更新

            return !newItem.isUpdate;

        }

        private final Object payloadResult = new Object();

        @Nullable

        @Override

        public Object getChangePayload(@NonNull Item oldItem, @NonNull Item newItem) {

            // payload 用于Item局部字段更新的时候使用,具体用法可以自行搜索了解

            // 当检测到同一个Item有更新时, 会调用此方法

            // 此方法默认返回null, 此时会触发Item的更新动画, 表现为Item会闪一下

            // 当返回值不为null时, 可以关闭Item的更新动画

            return payloadResult;

        }

    });

}





// 更新数据

List<Item> dataList = ...;

Item target = dataList.get(0);

// 标识数据有更新

target.isUpdate = true;

target.data = "新的数据";

adapter.submitList(dataList);

最后

其实, 如果我们的 List<Item> 来源于 Room, 其实没有这么多麻烦事, 直接调用 submitList 即可, 不用考虑这里提到的问题, 因为 Room 数据有更新时, 会自动生成新的 List<Item>, 里面的每项 Item 也是新的, 具体代码示例可参考 AsyncListDiffer 或者 ListAdapter 类的顶部的注释. 需要注意的是数据更新太频繁时, 会不会生成了太多的临时对象.

我们在开发一个项目时通常需要登录认证，常用的登录认证技术实现框架有Spring Security和shiro

Spring Security

Spring Security是一个功能强大且高度可定制的身份验证和访问控制框架。它是保护基于spring的应用程序的事实上的标准。

Spring Security是一个专注于为Java应用程序提供身份验证和授权的框架。与所有Spring项目一样，Spring Security的真正强大之处在于它可以很容易地扩展以满足定制需求，并且Spring Security和spring更加适配贴合，我们工作中常常使用到Spring Security。

Apache Shiro

Apache Shiro 是 Java 的一个安全框架。目前，使用 Apache Shiro 的人越来越多，因为它相当简单，对比Spring Security，可能没有 Spring Security 做的功能强大，但是在实际工作时可能并不需要那么复杂的东西，所以使用小而简单的 Shiro 就足够了。

不足：

这些都是认证技术框架，在单体应用中都是常用的技术框架，但是在分布式中，应用可能要部署多份，这时通过nginx分发请求，但是每个单体应用都要可能重复验证，因为他们的seesion数据是放在他们自己服务中的。

Session作用

Session是客户端与服务器通讯会话跟踪技术，服务器与客户端保持整个通讯的会话基本信息。

客户端在第一次访问服务端的时候，服务端会响应一个sessionId并且将它存入到本地cookie中，在之后的访问会将cookie中的sessionId放入到请求头中去访问服务器。

spring-session

Spring Session是Spring的项目之一，Spring Session把servlet容器实现的httpSession替换为spring-session，专注于解决session管理问题。

Spring Session提供了集群Session（Clustered Sessions）功能，默认采用外置的Redis来存储Session数据，以此来解决Session共享的问题。

spring-session提供对用户session管理的一系列api和实现。提供了很多可扩展、透明的封装方式用于管理httpSession/WebSocket的处理。

支持功能

1. 轻易把session存储到第三方存储容器，框架提供了redis、jvm的map、mongo、gemfire、hazelcast、jdbc等多种存储session的容器的方式。这样可以独立于应用服务器的方式提供高质量的集群。


2. 同一个浏览器同一个网站，支持多个session问题。 从而能够很容易地构建更加丰富的终端用户体验。


3. Restful API，不依赖于cookie。可通过header来传递jessionID 。控制session id如何在客户端和服务器之间进行交换，这样的话就能很容易地编写Restful API，因为它可以从HTTP 头信息中获取session id，而不必再依赖于cookie


4. WebSocket和spring-session结合，同步生命周期管理。当用户使用WebSocket发送请求的时候

分布式seesion实战

步骤1：依赖包

因为是web应用。我们加入springboot的常用依赖包web，加入SpringSession、redis的依赖包，移支持把session存储在redis

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-web</artifactId>

</dependency>



<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-test</artifactId>

    <scope>test</scope>

</dependency>



<dependency>

    <groupId>org.projectlombok</groupId>

    <artifactId>lombok</artifactId>

    <version>1.18.8</version>

</dependency>



<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-redis</artifactId>

    <version>1.4.7.RELEASE</version>

</dependency>



<dependency>

    <groupId>org.springframework.session</groupId>

    <artifactId>spring-session-data-redis</artifactId>

</dependency>

这里因为是把seesion存储在redis，这样每个服务登录都是去查看redis中数据进行验证的，所有是分布式的。
这里要引入spring-session-data-redis和spring-boot-starter-redis

步骤2：配置文件

spring.application.name=spring-boot-redis

server.port=9090

# 设置session的存储方式，采用redis存储

spring.session.store-type=redis

# session有效时长为15分钟

server.servlet.session.timeout=PT15M



## Redis 配置

## Redis数据库索引

spring.redis.database=1

## Redis服务器地址

spring.redis.host=127.0.0.1

## Redis服务器连接端口

spring.redis.port=6379

## Redis服务器连接密码（默认为空）

spring.redis.password=

步骤3：实现逻辑

初始化用户数据

@Slf4j

@RestController

@RequestMapping(value = "/user")

public class UserController {



    Map<String, User> userMap = new HashMap<>();



    public UserController() {

        //初始化1个用户，用于模拟登录

        User u1=new User(1,"user1","user1");

        userMap.put("user1",u1);

    }

}

这里就不用使用数据库了，初始化两条数据代替数据库,用于模拟登录

登录

 @GetMapping(value = "/login")

    public String login(String username, String password, HttpSession session) {

        //模拟数据库的查找

        User user = this.userMap.get(username);

        if (user != null) {

            if (!password.equals(user.getPassword())) {

                return "用户名或密码错误！！！";

            } else {

                session.setAttribute(session.getId(), user);

                log.info("登录成功{}",user);

            }

        } else {

            return "用户名或密码错误！！！";

        }

        return "登录成功！！！";

    }

登录接口，根据用户名和密码登录，这里进行验证，如果验证登录成功，使用 session.setAttribute(session.getId(), user);把相关信息放到session中。

查找用户

    /**

     * 通过用户名查找用户

     */

    @GetMapping(value = "/find/{username}")

    public User find(@PathVariable String username) {

        User user=this.userMap.get(username);

        log.info("通过用户名={},查找出用户{}",username,user);

        return user;

    }

模拟通过用户名查找用户

获取session

  /**

     *拿当前用户的session

     */

    @GetMapping(value = "/session")

    public String session(HttpSession session) {

        log.info("当前用户的session={}",session.getId());

        return session.getId();

    }

退出登录

  /**

     * 退出登录

     */

    @GetMapping(value = "/logout")

    public String logout(HttpSession session) {

        log.info("退出登录session={}",session.getId());

        session.removeAttribute(session.getId());

        return "成功退出！！";

    }

这里退出时，要把session中的用户信息删除。

步骤4：编写session拦截器

session拦截器的作用：验证当前用户发来的请求是否有携带sessionid，如果没有携带，提示用户重新登录。

 @Configuration

    public class SecurityInterceptor implements HandlerInterceptor {

        @Override

        public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws IOException {

            HttpSession session = request.getSession();

            //验证当前session是否存在，存在返回true true代表能正常处理业务逻辑

            if (session.getAttribute(session.getId()) != null){

                log.info("session拦截器，session={}，验证通过",session.getId());

                return true;

            }

            //session不存在，返回false，并提示请重新登录。

            response.setCharacterEncoding("UTF-8");

            response.setContentType("application/json; charset=utf-8");

            response.getWriter().write("请登录！！！！！");

            log.info("session拦截器，session={}，验证失败",session.getId());

            return false;

        }

    }

步骤5：把拦截器注入到拦截器链中

@Slf4j

@Configuration

public class SessionCofig implements WebMvcConfigurer {



    @Override

    public void addInterceptors(InterceptorRegistry registry) {

        registry.addInterceptor(new SecurityInterceptor())

                //排除拦截的2个路径

                .excludePathPatterns("/user/login")

                .excludePathPatterns("/user/logout")

                //拦截所有URL路径

                .addPathPatterns("/**");

    }

}

步骤6：测试

登录user1用户：http://127.0.0.1:9090/user/login?username=user1&password=user1

查询user1用户session：http://127.0.0.1:9090/user/session

退出登录： http://127.0.0.1:9090/user/logout

登录后查看redis中数据：

seesion数据已经保存到redis了，到这里我们就整合了使用spring-seesion实现分布式seesion功能。

1. 啥是反射

1.初识反射

刚开始学反射的时候，我是一脸懵逼的，这玩意真的是“抽象的妈妈给抽象开门-抽象到家了。”

为什么创建对象要先获取 Class 对象？这不多此一举吗？我直接 new 一下不是更简单吗？

什么是程序运行时获取类的属性和方法？平时都是程序编译出错了再修改代码，我为什么要考虑程序运行时的状态？

我平时开发也用不到，学这玩意有啥用？

后来学了注解、spring、SpringMVC 等技术之后，发现反射无处不在。

2.JVM 加载类

我们写的 java 程序要放到 JVM 中运行，所以要学习反射，首先需要了解 JVM 加载类的过程。

1.我们写的 .java 文件叫做源代码。

2.我们在一个类中写了一个 main 方法，然后点击 IDEA 的 run 按钮，JVM 运行时会触发 jdk 的 javac 指令将源代码编译成 .class 文件，这个文件又叫做字节码文件。

3.JVM 的类加载器（你可以理解成一个工具）通过一个类的全限定名来获取该类的二进制字节流，然后将该 class 文件加载到 JVM 的方法区中。

4.类加载器加载一个 .class 文件到方法区的同时会在堆中生成一个唯一的 Class 对象，这个 Class 包含这个类的成员变量、构造方法以及成员方法。

5.这个 Class 对象会创建与该类对应的对象实例。

所以表面上你 new 了一个对象，实际上当 JVM 运行程序的时候，真正帮你创建对象的是该类的 Class 对象。

也就是说反射其实就是 JVM 在运行程序的时候将你创建的所有类都封装成唯一一个 Class 对象。这个 Class 对象包含属性、构造方法和成员方法。你拿到了 Class 对象，也就能获取这三个东西。

你拿到了反射之后（Class）的属性，就能获取对象的属性名、属性类别、属性值，也能给属性设置值。

你拿到了反射之后（Class）的构造方法，就能创建对象。

你拿到了反射之后（Class）的成员方法，就能执行该方法。

3.反射的概念

JAVA 反射机制是在程序运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意方法和属性；这种动态获取信息以及动态调用对象方法的功能称为 java 语言的反射机制。

知道了 JVM 加载类的过程，相信你应该更加深入的了解了反射的概念。

反射：JVM 运行程序 --> .java 文件 --> .class 文件 --> Class 对象 --> 创建对象实例并操作该实例的属性和方法

接下来我就讲一下反射中的相关类以及常用方法。

2. Class 对象

获取 Class 对象

先建一个 User 类：

public class User {

    private  String name = "知否君";

    public String sex = "男";



    public User() {

    }



    public User(String name, String sex) {

        this.name = name;

        this.sex = sex;

    }



    public void eat(){

        System.out.println("人要吃饭！");

    }



    private void run(){

        System.out.println("人要跑步！");

    }



    public String getName() {

        return name;

    }



    public void setName(String name) {

        this.name = name;

    }



    public String getSex() {

        return sex;

    }



    public void setSex(String sex) {

        this.sex = sex;

    }

}

获取 Class 对象的三种方式：

1. Class.forName("全类名")

全类名：包名+类名

Class userClass = Class.forName("com.xxl.model.User");

2. 类名.class

Class userClass = User.class;

3. 对象.getClass()

User user = new User();

Class userClass = user.getClass();

尽管有三种方式获取 Class 对象，但是我们一般采用上述第一种方式。

拿到 Class 对象之后，我们就可以操作与它相关的方法了。

3. 获取类名

1.获取完整类名：包名+类名

getName()

Class userClass = Class.forName("com.xxl.model.User");

String name = userClass.getName();

System.out.println(name);

打印结果：

2.获取简单类名：不包括包名

getSimpleName()

Class userClass = Class.forName("com.xxl.model.User");

String simpleName = userClass.getSimpleName();

System.out.println(simpleName);

打印结果：

4. 属性

4.1 获取属性

1.获取所有公有属性：public 修饰

getFields()

Class userClass = Class.forName("com.xxl.model.User");

Field[] fields = userClass.getFields();

for (Field field : fields) {

    System.out.println(field);

}

打印结果：

2.获取单个公有属性

getField("属性名")

Class userClass = Class.forName("com.xxl.model.User");

Field field = userClass.getField("sex");

System.out.println(field);

打印结果：

3.获取所有属性：公有+私有

getDeclaredFields()

Class userClass = Class.forName("com.xxl.model.User");

Field[] fields = userClass.getDeclaredFields();

for (Field field : fields) {

    System.out.println(field);

}

打印结果：

4.获取单个属性：公有或者私有

getDeclaredField("属性名")

Class userClass = Class.forName("com.xxl.model.User");

Field nameField = userClass.getDeclaredField("name");

Field sexField = userClass.getDeclaredField("sex");

System.out.println(nameField);

System.out.println(sexField);

打印结果：

4.2 操作属性

1.获取属性名称

getName()

Class userClass = Class.forName("com.xxl.model.User");

Field nameField = userClass.getDeclaredField("name");

System.out.println(nameField.getName());

打印结果：

2.获取属性类型

getType()

Class userClass = Class.forName("com.xxl.model.User");

Field nameField = userClass.getDeclaredField("name");

System.out.println(nameField.getType());

打印结果：

3.获取属性值

get(object)

Class userClass = Class.forName("com.xxl.model.User");

Field nameField = userClass.getDeclaredField("sex");

User user = new User();

System.out.println(nameField.get(user));

打印结果：

注： 通过反射不能直接获取私有属性的值，但是可以通过修改访问入口来获取私有属性的值。

设置允许访问私有属性：

field.setAccessible(true);

例如：

Class userClass = Class.forName("com.xxl.model.User");

Field nameField = userClass.getDeclaredField("name");

nameField.setAccessible(true);

User user = new User();

System.out.println(nameField.get(user));

打印方法：

4.设置属性值

set(object,"属性值")

Class userClass = Class.forName("com.xxl.model.User");

Field nameField = userClass.getDeclaredField("name");

nameField.setAccessible(true);

User user = new User();

nameField.set(user,"张无忌");

System.out.println(nameField.get(user));

打印结果：

5. 构造方法

1.获取所有公有构造方法

getConstructors()

Class userClass = Class.forName("com.xxl.model.User");

Constructor[] constructors = userClass.getConstructors();

for (Constructor constructor : constructors) {

    System.out.println(constructor);

}

打印结果：

2.获取与参数类型匹配的构造方法

getConstructor(参数类型)

Class userClass = Class.forName("com.xxl.model.User");

Constructor constructor = userClass.getConstructor(String.class, String.class);

System.out.println(constructor);

打印结果：

6. 成员方法

6.1获取成员方法

1.获取所有公共方法

getMethods()

Class userClass = Class.forName("com.xxl.model.User");

Method[] methods = userClass.getMethods();

for (Method method : methods) {

    System.out.println(method);

}

打印结果：

我们发现，打印结果除了自定义的公共方法，还有继承自 Object 类的公共方法。

2.获取某个公共方法

getMethod("方法名", 参数类型)

Class userClass = Class.forName("com.xxl.model.User");

Method method = userClass.getMethod("setName", String.class);

System.out.println(method);

打印结果：

3.获取所有方法：公有+私有

getDeclaredMethods()

Class userClass = Class.forName("com.xxl.model.User");

Method[] declaredMethods = userClass.getDeclaredMethods();

for (Method method : declaredMethods) {

    System.out.println(method);

}

打印结果：

4.获取某个方法：公有或者私有

getDeclaredMethod("方法名", 参数类型)

Class userClass = Class.forName("com.xxl.model.User");

Method method = userClass.getDeclaredMethod("run");

System.out.println(method);

打印结果：

6.2 执行成员方法

invoke(object,"方法参数")

Class userClass = Class.forName("com.xxl.model.User");

Method method = userClass.getDeclaredMethod("eat");

User user = new User();

method.invoke(user);

打印结果：

注： 通过反射不能直接执行私有成员方法，但是可以设置允许访问。

设置允许执行私有方法：

method.setAccessible(true);

7. 注解

1.判断类上或者方法上时候包含某个注解

isAnnotationPresent(注解名.class)

例如：

Class userClass = Class.forName("com.xxl.model.User");

if(userClass.isAnnotationPresent(Component.class)){

    Component annotation = (Component)userClass.getAnnotation(Component.class);

    String value = annotation.value();

    System.out.println(value);

};

2.获取注解

getAnnotation(注解名.class)

例如：

Class userClass = Class.forName("com.xxl.model.User");

// 获取类上的注解

Annotation annotation1 = userClass.getAnnotation(Component.class);

Method method = userClass.getMethod("eat");

// 获取方法上的某个注解

Annotation annotation2 = userClass.getAnnotation(Component.class);

8. 创建类的实例

1.通过 Class 实例化对象

Class.newInstance()

Class userClass = Class.forName("com.xxl.model.User");

User user = (User)userClass.newInstance();

System.out.println("姓名："+user.getName()+" 性别："+user.getSex());

打印结果：

2.通过构造方法实例化对象

constructor.newInstance(参数值)

Class userClass = Class.forName("com.xxl.model.User");

Constructor constructor = userClass.getConstructor(String.class, String.class);

User user = (User)constructor.newInstance\("李诗情", "女"\);

System.out.println("姓名："+user.getName()+" 性别："+user.getSex());

打印结果：

9. 反射案例

有一天技术总监对张三说："张三，听说你最近学反射了呀。那你设计一个对象的工厂类给我看看。"

张三心想："哟，快过年了，领导这是要给我涨工资啊。这次我一定好好表现一次。"

5分钟过后，张三提交了代码：

public class ObjectFactory {

    

    public static User getUser() {

        

        User user = null;

        try {

            Class userClass = Class.forName("com.xxl.model.User");

            user = (User) userClass.newInstance();

        } catch (ClassNotFoundException e) {

            e.printStackTrace();

        } catch (IllegalAccessException e) {

            e.printStackTrace();

        } catch (InstantiationException e) {

            e.printStackTrace();

        }

        return user;

    }



    public static UserService getUserService() {

        UserService userService = null;

        try {

            Class userClass = Class.forName("com.xxl.service.impl.UserServiceImpl");

            userService = (UserService) userClass.newInstance();

        } catch (ClassNotFoundException e) {

            e.printStackTrace();

        } catch (IllegalAccessException e) {

            e.printStackTrace();

        } catch (InstantiationException e) {

            e.printStackTrace();

        }

        return userService;

    }

}

技术总监瞄了一眼代码，对张三说："你这个工厂类存在两个问题。"

1.代码存在大量冗余。如果有一万个类，你是不是要写一万个静态方法？

2.代码耦合度太高。如果这些类存放的包路径发生改变，你再用 forName（）获取 Class 对象是不是就会有问题？你还要一个个手动改代码，然后再编译、打包、部署。。你不觉得麻烦吗？

“发散你的思维想一下，能不能只设计一个静态类，通过传参的方式用反射创建对象，传递的参数要降低和工厂类的耦合度。顺便提醒你一下，可以参考一下 JDBC 获取数据库连接参数的方式。”

张三一听："不愧是总监啊，醍醐灌顶啊！等我 10 分钟。"

10 分钟后，张三再次提交了代码：

object.properties

user=com.xxl.model.User

userService=com.xxl.service.impl.UserServiceImpl

ObjectFactory

public class ObjectFactory {



    private static Properties objectProperty = new Properties();



    // 静态方法在类初始化时执行，且只执行一次

    static{

        try {

            InputStream inputStream = ObjectFactory.class.getResourceAsStream("/object.properties");

            objectProperty.load(inputStream);

            inputStream.close();

        } catch (IOException e) {

            e.printStackTrace();

        }

    }

    

    public static Object getObject(String key){

        Object object = null;

        try {

            Class objectClass = Class.forName(objectProperty.getProperty(key));

            object = objectClass.newInstance();

        } catch (Exception e) {

            e.printStackTrace();

        }

        return object;

    }

}

测试方法：

@Test

  void testObject() {

      User user = (User)ObjectFactory.getObject("user");

      UserService userService = (UserService)ObjectFactory.getObject("userService");

      System.out.println(user);

      System.out.println(userService);

  }

执行结果：

总监看后连连点头，笑着对张三说：“用 properties 文件存放类的全限定名降低了代码的耦合度，通过传参的方式使用反射创建对象又降低了代码的冗余性，这次改的可以。"

"好啦，今晚项目要上线，先吃饭去吧，一会还要改 bug。”

张三："..........好的总监。"

10. 反射的作用

我们或多或少都听说过设计框架的时候会用到反射，例如 Spring 的 IOC
就用到了工厂模式和反射来创建对象，BeanUtils 的底层也是使用反射来拷贝属性。所以反射无处不在。

尽管我们日常开发几乎用不到反射，但是我们必须要搞懂反射的原理，因为它能帮我们理解框架设计的原理。

新年快乐

新年伊始，万象更新，虾哥开卷，天下无敌。

首先感谢各位大佬的支持，今年终于喜提掘金优秀作者了。

给各位大佬跪了，祝各位安卓同学新年快乐啊。

开篇

先介绍下徐公大佬的文章，如果有前置需要的话建议看下这个系列。

启动优化这个系列都可以好好看看，感谢徐公大佬。

本文将不发表任何关于 有向无环图（DAG） 相关，会更细致的说一些我自己的奇怪的观点，以及从一些问题出发，介绍如何做一些有意思的调整。

当前仓库还处于一个迭代状态中，并不是一个特别稳定的状态，所以文章更多的是给大家打开一些小思路。

有想法的同学可以留言啊，我个人感觉一个迭代库才是可以持续演进的啊。

demo 地址 AndroidStartup

demo中很多代码参考了android-startup，感谢这位大佬，u1s1这位大佬很强啊。

Task粒度

这一点其实蛮重要的，相信很多人在接入启动框架之后，更多的事情是把原来可以用的代码，直接用几个Task的把之前的代码包裹起来，之后然后这样就相当于完成了简单的启动框架接入了。

其实这个基本算是违背了启动框架设计的初衷了。我先抛出一个观点，启动框架并不会真实帮你加快多少启动速度，他解决的场景只是让你的sdk的初始化更加的有序，让你可以在长时间的迭代过程中，可以更加稳妥的添加一些新的sdk。

举个栗子，当你的埋点框架依赖了网络库，abtest配置中心也依赖了网络库，然后网络库则依赖了dns等等，之后所有的业务依赖了埋点配置中心图片库等等sdk的初始化完成之后。

当然还是有极限情况下会出现依赖成环问题，这个时候可能就需要开发同学手动的把这个依赖问题给解决了 比如特殊情况网络库需要唯一id，上报库依赖了网络库，而上报库又依赖了唯一id，唯一id又需要进行数据上报

所以我个人的看法启动框架的粒度应该细化到每个sdk的初始化，如果粒度可以越细致当然就越好了。其实一般的启动框架都会对每个task的耗时进行统计的，这样我们后续在跟进对应的问题也会变的更简便，比如查看某些的任务耗时是否增加了啊之类的。

当前我们在设计的时候可能会把一个sdk的初始化拆分成三个部分去做，就是为了去解决这种依赖成环的问题。

子线程间的等待

之前发现项目内的启动框架只保证了放入线程的时候的顺序是按照dag执行的。如果只有主线程和池子大小为1线程池的情况下，这种是ok的。但是如果多线程并发的情况下，这个就变成了一个危险操作了。

所以我们需要在并发场景下加上一个等待的情况下，一定要等到依赖的任务完成了之后，才能继续向下执行初始化代码。

机制的话还是使用CountDownLatch，当依赖的任务都执行完成之后，await会被释放，继续向下执行。而设计上我还是采取了装饰者，不需要使用方更改原始的逻辑就能继续使用了。

代码如下，主要就是一次任务完成的分发，之后发现当前的依赖是有该任务的则latch-1. 当latch到0的情况下就会释放当前线程了。

class StartupAwaitTask(val task: StartupTask) : StartupTask {



    private var dependencies = task.dependencies()

    private lateinit var countDownLatch: CountDownLatch

    private lateinit var rightDependencies: List

    var awaitDuration: Long = 0



    override fun run(context: Context) {

        val timeUsage = SystemClock.elapsedRealtime()

        countDownLatch.await()

        awaitDuration = (SystemClock.elapsedRealtime() - timeUsage) / 1000

        KLogger.i(

            TAG, "taskName:${task.tag()}  await costa:${awaitDuration} "

        )

        task.run(context)

    }



    override fun dependencies(): MutableList {

        return dependencies

    }



    fun allTaskTag(tags: HashSet) {

        rightDependencies = dependencies.filter { tags.contains(it) }

        countDownLatch = CountDownLatch(rightDependencies.size)

    }



    fun dispatcher(taskName: String) {

        if (rightDependencies.contains(taskName)) {

            countDownLatch.countDown()

        }

    }



    override fun mainThread(): Boolean {

        return task.mainThread()

    }



    override fun await(): Boolean {

        return task.await()

    }



    override fun tag(): String {

        return task.tag()

    }



    override fun onTaskStart() {

        task.onTaskStart()

    }



    override fun onTaskCompleted() {

        task.onTaskCompleted()

    }



    override fun toString(): String {

        return task.toString()

    }



    companion object {

        const val TAG = "StartupAwaitTask"

    }

}

这个算是一个能力的补充完整，也算是多线程依赖必须要完成的一部分。

同时将依赖模式从class变更成tag的形式，但是这个地方还没完成最后的设计，当前还是有点没想好的。主要是解决组件化情况下，可以更随意一点。

线程池关闭

这里是我个人考虑哦，当整个启动流程结束之后，默认情况下是不是应该考虑把线程池关闭了呢。我发现很多都没有写这些的，会造成一些线程使用的泄漏问题。

fun dispatcherEnd() {

    if (executor != mExecutor) {

        KLogger.i(TAG, "auto shutdown default executor")

        mExecutor.shutdown()

    }

}

代码如上，如果当前线程池并不是传入的线程池的情况下，考虑执行完毕之后关闭线程池。

dsl + 锚点

因为我既是开发人员，同时也是框架的使用方。所以我自己在使用的过程中发现原来的设计上问题还是很多的，我自己想要插入一个在所有sdk完成之后的任务非常不方便。

然后我就考虑这部分通过dsl的方式去写了动态添加task。kotlin是真的很香，如果后续开发没糖我估计就是个废人了。

我就是死从这里跳下去，卧槽语法糖真香。

fun Application.createStartup(): Startup.Builder = run {

    startUp(this) {

        addTask {

            simpleTask("taskA") {

                info("taskA")

            }

        }

        addTask {

            simpleTask("taskB") {

                info("taskB")

            }

        }

        addTask {

            simpleTask("taskC") {

                info("taskC")

            }

        }

        addTask {

            simpleTaskBuilder("taskD") {

                info("taskD")

            }.apply {

                dependOn("taskC")

            }.build()

        }

        addTask("taskC") {

            info("taskC")

        }

        setAnchorTask {

            MyAnchorTask()

        }

        addTask {

            asyncTask("asyncTaskA", {

                info("asyncTaskA")

            }, {

                dependOn("asyncTaskD")

            })

        }

        addAnchorTask {

            asyncTask("asyncTaskB", {

                info("asyncTaskB")

            }, {

                dependOn("asyncTaskA")

                await = true

            })

        }

        addAnchorTask {

            asyncTaskBuilder("asyncTaskC") {

                info("asyncTaskC")

                sleep(1000)

            }.apply {

                await = true

                dependOn("asyncTaskE")

            }.build()

        }

        addTaskGroup { taskGroup() }

        addTaskGroup { StartupTaskGroupApplicationKspMain() }

        addMainProcTaskGroup { StartupTaskGroupApplicationKspAll() }

        addProcTaskGroup { StartupProcTaskGroupApplicationKsp() }

    }

}

这种DSL写法适用于插入一些简单的任务，可以是一些没有依赖的任务，也可以是你就是偷懒想这么写。好处就是可以避免自己用继承等的形式去写过多冗余的代码，然后在这个启动流程内能看到自己做了些什么事情。

一般等到项目稳定之后，会设立几个锚点任务。他们的作用是后续任务只要挂载到锚点任务之后执行即可，定下一些标准，让后续的同学可以更快速的接入。

我们会把这些设置成一些任务组设置成基准，比如说是网络库，图片库，埋点框架,abtest等等，等到这些任务完成之后，别的业务代码就可以在这里进行初始化了。这样就不需要所有人都写一些基础的依赖关系，也可以让开发同学舒服一点点。

怎么又成环了

在之前的排序阶段，存在一个非常鬼畜的问题，如果你依赖的任务并不在当前的图中存在，就会报出依赖成环问题，但是你并不知道是因为什么原因成环的。

这个就非常不方便开发同学调试问题了，所以我增加了前置任务有效性判断，如果不存在的则会直接打印Log日志，也增加了debugmode，如果测试情况下可以直接已任务不存在的崩溃结束。

ksp

我想偷懒所以用ksp生成了一些代码，同时我希望我的启动框架也可以应用于项目的组件化和插件化中，这样反正就是牛逼啦。

启动任务分组

当前完成的一个功能就是通过注解+ksp生成一个启动任务的分组，这次ksp的版本我们采用的是1.5.30的版本，同时api也有了一些变更。

之前在ksp的文章说过process死循环的问题，最近和米忽悠乌蝇哥交流（吹牛）的时候发现，系统提供一个finish方法，因为process的时候只要有类生成就会重新出发process方法，导致stackoverflow，所以后续代码生成可以考虑迁移到新方法内。

class StartupProcessor(

    val codeGenerator: CodeGenerator,

    private val logger: KSPLogger,

    val moduleName: String

) : SymbolProcessor {

    private lateinit var startupType: KSType

    private var isload = false

    private val taskGroupMap = hashMapOf>()

    private val procTaskGroupMap =

        hashMapOf>>>()



    override fun process(resolver: Resolver): List {

        logger.info("StartupProcessor start")



        val symbols = resolver.getSymbolsWithAnnotation(StartupGroup::class.java.name)

        startupType = resolver.getClassDeclarationByName(

            resolver.getKSNameFromString(StartupGroup::class.java.name)

        )?.asType() ?: kotlin.run {

            logger.error("JsonClass type not found on the classpath.")

            return emptyList()

        }

        symbols.asSequence().forEach {

            add(it)

        }

        return emptyList()

    }



    private fun add(type: KSAnnotated) {

        logger.check(type is KSClassDeclaration && type.origin == Origin.KOTLIN, type) {

            "@JsonClass can't be applied to $type: must be a Kotlin class"

        }



        if (type !is KSClassDeclaration) return



        //class type



        val routerAnnotation = type.findAnnotationWithType(startupType) ?: return

        val groupName = routerAnnotation.getMember("group")

        val strategy = routerAnnotation.arguments.firstOrNull {

            it.name?.asString() == "strategy"

        }?.value.toString().toValue() ?: return

        if (strategy.equals("other", true)) {

            val key = groupName

            if (procTaskGroupMap[key] == null) {

                procTaskGroupMap[key] = mutableListOf()

            }

            val list = procTaskGroupMap[key] ?: return

            list.add(type.toClassName() to (routerAnnotation.getMember("processName")))

        } else {

            val key = "${groupName}${strategy}"

            if (taskGroupMap[key] == null) {

                taskGroupMap[key] = mutableListOf()

            }

            val list = taskGroupMap[key] ?: return

            list.add(type.toClassName())

        }

    }



    private fun String.toValue(): String {

        var lastIndex = lastIndexOf(".") + 1

        if (lastIndex <= 0) {

            lastIndex = 0

        }

        return subSequence(lastIndex, length).toString().lowercase().upCaseKeyFirstChar()

    }

       // 开始代码生成逻辑

    override fun finish() {

        super.finish()

        // logger.error("className:${moduleName}")

        try {

            taskGroupMap.forEach { it ->

                val generateKt = GenerateGroupKt(

                    "${moduleName.upCaseKeyFirstChar()}${it.key.upCaseKeyFirstChar()}",

                    codeGenerator

                )

                it.value.forEach { className ->

                    generateKt.addStatement(className)

                }

                generateKt.generateKt()

            }

            procTaskGroupMap.forEach {

                val generateKt = GenerateProcGroupKt(

                    "${moduleName.upCaseKeyFirstChar()}${it.key.upCaseKeyFirstChar()}",

                    codeGenerator

                )

                it.value.forEach { pair ->

                    generateKt.addStatement(pair.first, pair.second)

                }

                generateKt.generateKt()

            }

        } catch (e: Exception) {

            logger.error(

                "Error preparing :" + " ${e.stackTrace.joinToString("\n")}"

            )

        }

    }

}





class StartupProcessorProvider : SymbolProcessorProvider {

    override fun create(

        environment: SymbolProcessorEnvironment

    ): SymbolProcessor {

        return StartupProcessor(

            environment.codeGenerator,

            environment.logger,

            environment.options[KEY_MODULE_NAME] ?: "application"

        )

    }

}



fun String.upCaseKeyFirstChar(): String {

    return if (Character.isUpperCase(this[0])) {

        this

    } else {

        StringBuilder().append(Character.toUpperCase(this[0])).append(this.substring(1)).toString()

    }

}



const val KEY_MODULE_NAME = "MODULE_NAME"

其中processor被拆分成两部分，SymbolProcessorProvider负责构造，SymbolProcessor则负责处理ast逻辑。以前的initapi 被移动到SymbolProcessorProvider中了。

逻辑也比较简单，收集注解，然后基于注解的入参生成一个taskGroup逻辑。这个组会被我手动加入到启动流程内。

未完成

另外我想做的一件事就是通过注解来去生成一个Task任务，然后通过不同的注解的排列组合，组合出一个新的task任务。

这部分功能还在设计中，后续完成之后再给大家水一篇好了。

调试组件

这部分是我最近设计的重中之重了。当接了启动框架这个活之后，更多的时候你是需要去追溯启动变慢的问题的，我们把这种情况叫做劣化。如何快速定位劣化问题也是启动框架所需要关心的。

一开始我们打算通过日志上报，之后在版本发布之后重新推导线上的任务耗时，但是因为计算出来的是平均值，而且我们的自动化测试同学每个版本发布前都会跑自动化case，观察启动时间的状况，如果时间均值变长就会来通知我们，这个时候看埋点数据其实挺难发现问题的。

核心原因还是我想偷懒，因为排查问题必须要基于之前的版本和当前版本进行对比，比较各个task之间的耗时状况，我们当前大概应该有30+的启动任务，这尼玛不是要了我老命了吗。

所以我和我大佬沟通了下，就对这部分进行了立项，打算折腾一个调试工具，可以记录下启动任务的耗时，还有启动任务的列表，通过本地对比的形式，可以快速推导出出现问题任务，方便我们快速定位问题。

小贴士 调试工具的开发最好不要有太多的依赖 然后通过debug 的buildtype来加入 所以使用了contentprovider来初始化

启动时间轴

江湖上一直流传着我的外号-ui大湿，在下也不是浪得虚名，ui大湿画出来的图形那叫一个美如画啊。

这部分原理比较简单，我们把当前启动任务的数据进行了收集，然后根据线程名进行分发，记录任务开始和结束的节点，然后通过图形化进行展示。

如果你第一时间看不懂，可以参考下自选股列表，每一列都是代表一个线程执行的时间轴。

启动顺序是否变更

我们会在每次启动的时候将当前启动的顺序进行数据库记录，然后通过数据库找出和当前hashcode不一样的任务，然后比对下用textview的形式展示出来，方便测试同学反馈问题。

这个地方的原理的，我是将整个启动任务通过字符串拼接，然后生成一个字符串，之后通过字符串的hashcode作为唯一标识符，不同字符串生成的hashcode也是不同的。

这里有个傻事就是我一开始对比的是stringbuilder的hashcode，然后发现一样的任务竟然值变更了，我真傻真的。

别问，问就是ui大湿，textview不香？

平均任务耗时

这个地方的数据库设计让我思考了好一会，之后我按照天为维度，之后记录时间和次数，然后在渲染的时候取出均值。

之后把之前的历史数据取出来，然后进行汇总统计，之后重新生成list，一个当前task下面跟随一个历史的task。然后进行牛逼的ui渲染。

这个时候你要喷了啊，为什么你全部都是textview还自称ui大湿啊。

虾扯蛋你听过吗，没错就是这样的。

总结

卷来，天不生我逮虾户，卷道万古长如夜。

与诸君共勉。

真的总结

UI方面我后续还是会进行迭代的，毕竟第一个版本丑陋不堪主要是想完成数据的手机，而且开发看起来也不是特别显眼，后面可能会把差异部分直接输出。

做大做强，搞一波大新闻。

1、SpringBoot Dedevtools

他是一个让SpringBoot支持热部署的工具，下面是引用的方法

要么在创建项目的时候直接勾选下面的配置：

要么给springBoot项目添加下面的依赖：

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-devtools</artifactId>

    <optional>true</optional>

</dependency>

• 
  

  idea修改完代码后再按下 ctrl + f9 使其重新编译一下，即完成了热部署功能

  
  


• 
  

  eclipse是按ctrl + s保存 即可自动编译

  
  

如果你想一修改代码就自动重新编译，无需按ctrl+f9。只需要下面的操作：

1.在idea的setting中把下面的勾都打上

2.进入pom.xml,在build的反标签后给个光标，然后按Alt+Shift+ctrl+/

3.然后勾选下面的东西，接着重启idea即可

2、Lombok

Lombok是简化JavaBean开发的工具，让开发者省去构造器，getter,setter的书写。

在项目初始化时勾选下面的配置，即可使用Lombok

或者在项目中导入下面的依赖：

<dependency>    

<groupId>org.projectlombok</groupId>    

<artifactId>lombok</artifactId>

    <optional>true</optional>

</dependency>

使用时，idea还需要下载下面的插件：

下面的使用的例子

@AllArgsConstructor

//全参构造器

@NoArgsConstructor

//无参构造器

@Data//getter + setterpublic

class User {    

private Long id;

    private String name;

   private Integer age;   

 private String email;

}

3、Spring Configuration Processor

该工具是给实体类的属性注入开启提示，自我感觉该工具意义不是特别大！

因为SpringBoot存在属性注入，比如下面的实体类：

@Component

@ConfigurationProperties(prefix = "mypet")

public class Pet {    

private String nickName;    

private String strain; 



public String getNickName() {

  return nickName; 

} 

public void setNickName(String nickName) {

  this.nickName = nickName; 

} 

public String getStrain() {

  return strain; 

} 

public void setStrain(String strain) {

  this.strain = strain; 

} 

@Override public String toString() {

  return "Pet [nickName=" + nickName + ", strain=" + strain + "]"; 

}

}

想要在application.properties和application.yml中给mypet注入属性，却没有任何的提示，为了解决这一问题，我们在创建SpringBoot的时候勾选下面的场景：

或者直接在项目中添加下面的依赖:

<dependency>     

<groupId>org.springframework.boot</groupId>     

<artifactId>spring-boot-configuration-processor</artifactId>     

<optional>true</optional>

</dependency>

并在build的标签中排除对该工具的打包：（减少打成jar包的大小）

<build>    

<plugins>        

<plugin>            

<groupId>org.springframework.boot</groupId>            

<artifactId>spring-boot-maven-plugin</artifactId>            

<configuration>                

<excludes>                    

<exclude>                        

<groupId>org.springframework.boot</groupId>                        

<artifactId>spring-boot-configuration-processor</artifactId>                    

</exclude>                

</excludes>            

</configuration>        

</plugin>    

</plugins></build>

在项目开发中，接口与接口之间、前后端之间的数据传输都使用 JSON 格式。

1 fastjson使用

阿里巴巴的 fastjson是目前应用最广泛的JSON解析框架。本文也将使用fastjson。

1.1 引入依赖

<dependency>

    <groupId>com.alibaba</groupId>

    <artifactId>fastjson</artifactId>

    <version>1.2.35</version>

</dependency>

2 统一封装返回数据

在web项目中，接口返回数据一般要包含状态码、信息、数据等，例如下面的接口示例：

import com.alibaba.fastjson.JSONObject;

import org.springframework.web.bind.annotation.RequestMapping;

import org.springframework.web.bind.annotation.RequestMethod;

import org.springframework.web.bind.annotation.RestController;



/**

 * @author guozhengMu

 * @version 1.0

 * @date 2019/8/21 14:55

 * @description

 * @modify

 */

@RestController

@RequestMapping(value = "/test", method = RequestMethod.GET)

public class TestController {

    @RequestMapping("/json")

    public JSONObject test() {

        JSONObject result = new JSONObject();

        try {

            // 业务逻辑代码

            result.put("code", 0);

            result.put("msg", "操作成功！");

            result.put("data", "测试数据");

        } catch (Exception e) {

            result.put("code", 500);

            result.put("msg", "系统异常，请联系管理员！");

        }

        return result;

    }

}

这样的话，每个接口都这样处理，非常麻烦，需要一种更优雅的实现方式。

2.1 定义统一的JSON结构

统一的 JSON 结构中属性包括数据、状态码、提示信息，其他项可以自己根据需要添加。一般来说，应该有默认的返回结构，也应该有用户指定的返回结构。由于返回数据类型无法确定，需要使用泛型，代码如下：

public class ResponseInfo<T> {

    /**

     * 状态码

     */

    protected String code;

    /**

     * 响应信息

     */

    protected String msg;

    /**

     * 返回数据

     */

    private T data;



    /**

     * 若没有数据返回，默认状态码为 0，提示信息为“操作成功！”

     */

    public ResponseInfo() {

        this.code = 0;

        this.msg = "操作成功！";

    }



    /**

     * 若没有数据返回，可以人为指定状态码和提示信息

     * @param code

     * @param msg

     */

    public ResponseInfo(String code, String msg) {

        this.code = code;

        this.msg = msg;

    }



    /**

     * 有数据返回时，状态码为 0，默认提示信息为“操作成功！”

     * @param data

     */

    public ResponseInfo(T data) {

        this.data = data;

        this.code = 0;

        this.msg = "操作成功！";

    }



    /**

     * 有数据返回，状态码为 0，人为指定提示信息

     * @param data

     * @param msg

     */

    public ResponseInfo(T data, String msg) {

        this.data = data;

        this.code = 0;

        this.msg = msg;

    }

    // 省略 get 和 set 方法

}

2.2 使用统一的JSON结构

我们封装了统一的返回数据结构后，在接口中就可以直接使用了。如下：

import com.example.demo.model.ResponseInfo;

import org.springframework.web.bind.annotation.RequestMapping;

import org.springframework.web.bind.annotation.RequestMethod;

import org.springframework.web.bind.annotation.RestController;



/**

 * @author guozhengMu

 * @version 1.0

 * @date 2019/8/21 14:55

 * @description

 * @modify

 */

@RestController

@RequestMapping(value = "/test", method = RequestMethod.GET)

public class TestController {

    @RequestMapping("/json")

    public ResponseInfo test() {

        try {

            // 模拟异常业务代码

            int num = 1 / 0;

            return new ResponseInfo("测试数据");

        } catch (Exception e) {

            return new ResponseInfo(500, "系统异常，请联系管理员！");

        }

    }

}

如上，接口的返回数据处理便优雅了许多。针对上面接口做个测试，启动项目，通过浏览器访问：localhost:8096/test/json，得到响应结果：

{"code":500,"msg":"系统异常，请联系管理员！","data":null}

3 全局异常处理

3.1 系统定义异常处理

新建一个 ExceptionHandlerAdvice 全局异常处理类，然后加上 @RestControllerAdvice 注解即可拦截项目中抛出的异常，如下代码中包含了几个异常处理，如参数格式异常、参数缺失、系统异常等，见下例：

@RestControllerAdvice

@Slf4j

public class ExceptionHandlerAdvice {



    // 参数格式异常处理

    @ExceptionHandler({IllegalArgumentException.class})

    @ResponseStatus(HttpStatus.BAD_REQUEST)

    public ResponseInfo badRequestException(IllegalArgumentException exception) {

     log.error("参数格式不合法：" + e.getMessage());

        return new ResponseInfo(HttpStatus.BAD_REQUEST.value() + "", "参数格式不符！");

    }



 // 权限不足异常处理

    @ExceptionHandler({AccessDeniedException.class})

    @ResponseStatus(HttpStatus.FORBIDDEN)

    public ResponseInfo badRequestException(AccessDeniedException exception) {

        return new ResponseInfo(HttpStatus.FORBIDDEN.value() + "", exception.getMessage());

    }



 // 参数缺失异常处理

    @ExceptionHandler({MissingServletRequestParameterException.class})

    @ResponseStatus(HttpStatus.BAD_REQUEST)

    public ResponseInfo badRequestException(Exception exception) {

        return new ResponseInfo(HttpStatus.BAD_REQUEST.value() + "", "缺少必填参数！");

    }



    // 空指针异常

    @ExceptionHandler(NullPointerException.class)

    @ResponseStatus(value = HttpStatus.INTERNAL_SERVER_ERROR)

    public ResponseInfo handleTypeMismatchException(NullPointerException ex) {

        log.error("空指针异常，{}", ex.getMessage());

        return new JsonResult("500", "空指针异常");

    }



    @ExceptionHandler(Exception.class)

    @ResponseStatus(value = HttpStatus.INTERNAL_SERVER_ERROR)

    public JsonResult handleUnexpectedServer(Exception ex) {

        log.error("系统异常：", ex);

        return new JsonResult("500", "系统发生异常，请联系管理员");

    }

    

    // 系统异常处理

    @ExceptionHandler(Throwable.class)

    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)

    public ResponseInfo exception(Throwable throwable) {

        log.error("系统异常", throwable);

        return new ResponseInfo(HttpStatus.INTERNAL_SERVER_ERROR.value() + "系统异常，请联系管理员！");

    }

}

1. @RestControllerAdvice 注解包含了 @Component 注解，说明在 Spring Boot 启动时，也会把该类作为组件交给 Spring 来管理。


2. @RestControllerAdvice 注解包含了 @ResponseBody 注解，为了异常处理完之后给调用方输出一个 JSON 格式的封装数据。


3. @RestControllerAdvice 注解还有个 basePackages 属性，该属性用来拦截哪个包中的异常信息，一般我们不指定这个属性，我们拦截项目工程中的所有异常。


4. 在方法上通过 @ExceptionHandler 注解来指定具体的异常，然后在方法中处理该异常信息，最后将结果通过统一的 JSON 结构体返回给调用者。


5. 但在项目中，我们一般都会比较详细地去拦截一些常见异常，拦截 Exception 虽然可以一劳永逸，但是不利于我们去排查或者定位问题。实际项目中，可以把拦截 Exception 异常写在 GlobalExceptionHandler 最下面，如果都没有找到，最后再拦截一下 Exception 异常，保证输出信息友好。

下面我们通过一个接口来进行测试：

@RestController

@RequestMapping(value = "/test", method = RequestMethod.POST)

public class TestController {

    @RequestMapping("/json")

    public ResponseInfo test(@RequestParam String userName, @RequestParam String password) {

        try {

            String data = "登录用户：" + userName + "，密码：" + password;

            return new ResponseInfo("0", "操作成功！", data);

        } catch (Exception e) {

            return new ResponseInfo("500", "系统异常，请联系管理员！");

        }

    }

}

接口调用，password这项故意空缺：

一、背景

最近在调试reactive-steams源码的时候看到spring-boot源码包里面的

• 
  

  spring-configuration-metadata.json

  
  


• 
  

  additional-spring-configuration-metadata.json

  
  

说实话主要是metadata吸引了我，因为最近在调整引擎元数据管理确实折腾了很久。

查了官方的资料发现这里也是 SpringBoot 提供的元数据配置拓展，但是这里的元数据不是只在 Spring bean 管理的元数据类似。

▐ 官方解释

访问地址：docs.spring.io/spring-boot…

简单点可以理解为这类元数据的配置时为了让我们在使用 IDEA 开发的过程中，使用application.properties或者 application.yml配置的时候更有注释说明，更方便我们开发使用。

▐ 官方案例

以我们常用的 logging 配置为例

• 
  

  元数据配置

  
  

• 定义配置

二、应用实例

▐ 插件工厂配置定义

配置元数据文件位于 jar 下面。META-INF/spring-configuration-metadata.json它们使用简单的 JSON 格式，其中的项目分类在“groups”或“properties”下

{

    "properties": [

        {

            "name": "plugin-cache.basePackage",

            "type": "java.lang.String",

            "description": "文档扫描包路径。"

        },

        {

            "name": "plugin-cache.title",

            "type": "java.lang.String",

            "description": "Plugin Cache 插件工厂"

        },

        {

            "name": "plugin-cache.description",

            "type": "java.lang.String",

            "description": "插件工厂描述"

        },

        {

            "name": "plugin-cache.version",

            "type": "java.lang.String",

            "defaultValue": "V1.0",

            "description": "版本。"

        }

    ]

}

大部分元数据文件是在编译时通过处理所有带注释的项目自动生成的

@ConfigurationProperties 可以查看先前的文章

@EnableConfigurationProperties 的工作原理

参考下面 properties 表格进行配置上的理解。

deprecation 每个 properties 元素的属性中包含的 JSON 对象可以包含以下属性：

▐ 插件工厂配置注入

@Data

@Component

@ConfigurationProperties(PluginCacheProperties.PREFIX)

class PluginCacheProperties {



    public static final String PREFIX = "plugin-cache";



    /**

     * 文档扫描包路径

     */

    private String basePackage = "";



    /**

     * Plugin Cache 插件工厂

     */

    private String title = "Plugin Cache 插件工厂";



    /**

     * 服务文件介绍

     */

    private String description = "插件缓存说明";



    /**

     * 版本

     */

    private String version = "V1.0";



    /**

     * 默认编码

     */

    private String charset="UTF-8";



}

▐ 配置应用

三、总结

对于元数据配置，理解起来不难！主要为了组件库为了让使用者更加优化使用提供的一套 IDEA 提示说明。借此我们在开放私有组件或者插件的时候在对于配置项可对外提供开放能力，可以根据元数据配置来完善 IDEA 提示说明。这样其他人用起来的时候能很快知道对应的参数的配置类型以及相关的配置属性说明。总结本篇文章希望对从事相关工作的同学能够有所帮助或者启发

本文由小声团队出品，小声团队是一个专注于音频&音乐技术的初创团队，深度使用Flutter构建跨平台应用，希望与大家一起共同探索Flutter在桌面端&移动端的可能性。

背景

我们计划研发一款全功能跨平台的音乐制作平台（DAW），从立项之初我们就已经明确了全平台的支持计划（即Windows / MacOS / Linux / iOS / Android ) ,也因此我们也是以这个为目标来寻找技术解决方案，经过一段时间的研究与学习，大致确定了几个可选项，内部的调研结果如下（本结果仅代表团队内部认知，如有差异还请包涵）：

为什么不使用基于HTML5打造的技术栈？

HTML5是众所周知的最易上手的跨平台UI解决方案，并且产业成熟，有众多可选的框架与开源组件可直接使用。但是DAW作为一款专业生产力工具并不适合完全在浏览器环境中运行，比如第三方插件系统浏览器则无法支撑，另外在内存资源上的使用也不是很便捷，通常一个音乐工程可能需要占据数G内存，运行时需要维护数万个对象，这对于Javascript来说还是浏览器来说都是很严重的负担。
从另一个方面来看，就算我们需要以一种阉割的形式支持Web,那么WASM技术则是我们更佳的选择。
因此，我们不考虑基于HTML5的技术方案。

为什么不选择QT & GTK 等老牌原生高性能框架？

在传统技术上来看，QT是最符合我们需求的技术方案，很多老牌工具厂商背后也都是基于QT技术栈完成。QT在运行效率上而言无疑是最佳的选择，我们的主要顾虑在对于CPP的掌控能力与研发效率，UI开发与引擎开发有一个很大的根本区别在于引擎开发通常使用单元测试来完成逻辑验证，而UI则很难使用单元测试来验证UI效果，也很少看到有团队真的依赖单元测试的方式来进行UI开发，而QT没有像Webpack类似的hot reload技术，UI的验证效率会非常的低下，甚至于不是我们一个小团队可以承受得起的。
而CPP也是入门门槛极高的编程语言，我们对于QT方案也存疑，但是没有完全放弃。

Flutter 的什么特性吸引了我们

• Flutter使用基于Skia绘图引擎直接构建组件，操作系统只需要提供像素级的绘图能力即可，因此也就保证了跨平台的UI一致性（像素级一致），而对React Native的兼容性吐槽一直充斥着社区。


• Dart对于UI开发也是非常舒服的。
  
  
  
  • 对象默认引用传递。
  
  
  • 支持HOT Reload。这为开发效率带来本质的提升，使得Flutter研发效率不弱于HTML5
  
  
  • AOT支持，生产级代码运行效率飞升，不逊色于原生应用的表现。
  
  
  • FFI 支持 。 可以直接与原生C & Cpp代码进行交互而几乎没有任何性能损失。
  
  
  • Web 支持。 Flutter 即可直接编译到Web运行，这也为我们提供Web服务打下了可能性。
  
  
  
  

Flutter的这些特性都是直击我们需求的，所以我们决定尝试使用Flutter来构建我们的平台。

结论

如果你也在寻找一个技术技术方案兼顾研发效率与运行时效率，那么Flutter应该是一个很不错的选择。

起因

摸鱼是不可能摸鱼的，这辈子都不会摸鱼。

缘起是 郭佬 分享了一则微博：share.api.weibo.cn/share/26900…

顿时这个念头划过了我的脑海：好东西，但是我用的是 MacBook，不能用这个应用。但是貌似我可以自己写一个？

准备工作

年轻最需要的就是行动力，想到就干，尽管我此刻正在理顺 DevFest 的讲稿，但丝毫不妨碍我用 10 分钟写一个 App。于是我打出了一套组合拳：

• flutter config --enable-macos-desktop
• flutter create --platforms=macos touch_fish_on_macos

一个支持 macOS 的 Flutter 项目就创建好了。（此时大约过去了 1 分钟）

开始敲代码

找到资源

我们首先需要一张高清无码的  图片，这里你可以在网上进行搜寻，有一点需要注意的是，使用 LOGO 要注意使用场景带来的版权问题。找到图片后，丢到 assets/apple-logo.png，并在 pubspec.yaml 中加上资源引用：

flutter:

  use-material-design: true

+ assets:

+   - assets/apple-logo.png

思考布局

我们来观察一下 macOS 的启动画面，有几个要点：

• LOGO 在屏幕中间，固定大小约为 100dp；
• LOGO 与进度条间隔约 100 dp；
• 进度条高度约 5dp，宽度约 200dp，圆角几乎完全覆盖高度，值部分为白色，背景部分为填充色+浅灰色边框。

（别问我为什么这些东西能观察出来，问就是天天教 UI 改 UI。）

确认了大概的布局模式，接下来我们开始搭布局。（此时大约过去了 2 分钟）

实现布局

首先将 LOGO 居中、着色、设定宽度为 100，上下间隔 100：

return Center(

  child: Column(

    mainAxisAlignment: MainAxisAlignment.center,

    children: <Widget>[

      const Spacer(),

      Padding(

        padding: const EdgeInsets.symmetric(vertical: 100),

        child: Image.asset(

          'assets/apple-logo.png',

          color: CupertinoColors.white, // 使用 Cupertino 系列的白色着色

          width: 100,

        ),

      ),

      const Spacer(),

    ],

  ),

);

然后在下方放一个相对靠上的进度条：

return Center(

  child: Column(

    mainAxisAlignment: MainAxisAlignment.center,

    children: <Widget>[

      const Spacer(),

      Padding(

        padding: const EdgeInsets.symmetric(vertical: 100),

        child: Image.asset(

          'assets/apple-logo.png',

          color: CupertinoColors.white, // 使用 Cupertino 系列的白色

          width: 100,

        ),

      ),

      Expanded(

        child: Container(

          width: 200,

          alignment: Alignment.topCenter, // 相对靠上中部对齐

          child: DecoratedBox(

            border: Border.all(color: CupertinoColors.systemGrey), // 设置边框

            borderRadius: BorderRadius.circular(10), // 这里的值比高大就行

          ),

          child: ClipRRect(

            borderRadius: BorderRadius.circular(10), // 需要进行圆角裁剪

            child: LinearProgressIndicator(

              value: 0.3, // 当前的进度值

              backgroundColor: CupertinoColors.lightBackgroundGray.withOpacity(.3),

              color: CupertinoColors.white,

              minHeight: 5, // 设置进度条的高度

            ),

          ),

        ),

      ),

    ],

  ),

);

到这里你可以直接 run，一个静态的界面已经做好了。（此时大约过去了 4 分钟）

打开 App，你已经可以放在一旁挂机了，老板走到你的身边，可能会跟你闲聊更新的内容。但是，更新界面不会动，能称之为更新界面？ 当老板一而再再而三地从你身边经过，发现还是这个进度的时候，也许就已经把你的工资划掉了，或者第二天你因为进办公室在椅子上坐下而被辞退。

那么下一步我们就要思考如何让它动起来。

思考动画

来看看启动动画大概是怎么样的：

• 开始是没有进度条的；
• 进度条会逐级移动、速度不一定相等。

基于以上两个条件，我设计了一种动画处理方式：

• 构造分段的时长 (Duration)，可以自由组合由多个时长；
• 动画通过时长的数量决定每个时长最终的进度；
• 每段时长控制起始值到结束值的间隔。

只有三个条件，简单到起飞，开动！（此时大约过去了 5 分钟）

实现动画

开局一个 AnimationController：

class _HomePageState extends State<HomePage> with SingleTickerProviderStateMixin {

  /// 巧用 late 初始化，节省代码量

  late final AnimationController _controller = AnimationController(vsync: this);



  /// 启动后等待的时长

  Duration get _waitingDuration => const Duration(seconds: 5);



  /// 分段的动画时长

  List<Duration> get _periodDurations {

    return <Duration>[

      const Duration(seconds: 5),

      const Duration(seconds: 10),

      const Duration(seconds: 4),

    ];

  }



  /// 当前进行到哪一个分段

  final ValueNotifier<int> _currentPeriod = ValueNotifier<int>(1);

接下来实现动画方法，采用了递归调用的方式，减少调用链的控制：

@override

void initState() {

  super.initState();

  // 等待对应秒数后，开始进度条动画

  Future.delayed(_waitingDuration).then((_) => _callAnimation());

}



Future<void> _callAnimation() async {

  // 取当前分段

  final Duration _currentDuration = _periodDurations[currentPeriod];

  // 准备下一分段

  currentPeriod++;

  // 如果到了最后一个分段，取空

  final Duration? _nextDuration = currentPeriod < _periodDurations.length ? _periodDurations.last : null;

  // 计算当前分段动画的结束值

  final double target = currentPeriod / _periodDurations.length;

  // 执行动画

  await _controller.animateTo(target, duration: _currentDuration);

  // 如果下一分段为空，即执行到了最后一个分段，重设当前分段，动画结束

  if (_nextDuration == null) {

    currentPeriod = 0;

    return;

  }

  // 否则调用下一分段的动画

  await _callAnimation();

}

以上短短几行代码，就完美的实现了进度条的动画操作。（此时大约过去了 8 分钟）

最后一步，将动画、分段二者与进度条绑定，在没进入分段前不展示进度条，在动画开始后展示对应的进度：

ValueListenableBuilder<int>(

  valueListenable: _currentPeriod,

  builder: (_, int period, __) {

    // 分段为0时，不展示

    if (period == 0) {

      return const SizedBox.shrink();

    }

    return DecoratedBox(

      decoration: BoxDecoration(

        border: Border.all(color: CupertinoColors.systemGrey),

        borderRadius: BorderRadius.circular(10),

      ),

      child: ClipRRect(

        borderRadius: BorderRadius.circular(10),

        child: AnimatedBuilder( // 使用 AnimatedBuilder，在动画进行时触发更新

          animation: _controller,

          builder: (_, __) => LinearProgressIndicator(

            value: _controller.value, // 将 controller 的值绑定给进度

            backgroundColor: CupertinoColors.lightBackgroundGray.withOpacity(.3),

            color: CupertinoColors.white,

            minHeight: 5,

          ),

        ),

      ),

    );

  },

大功告成，总共用时 10 分钟，让我们跑起来看看效果。（下图 22.1 M）

这还原度，谁看了不迷糊呢？🤩从此开启上班摸鱼之路...

打包发布

发布正式版的 macOS 应用较为复杂，但我们可以打包给自己使用，只需要一行命令即可：flutter build macos。

成功后，产物将会输出在 build/macos/Build/Products/Release/touch_fish_on_macos.app，双击即可使用。

结语

至此，一个简单的能在 macOS 上运行的摸鱼 Flutter App 就这么开发完成了。完整的 demo 可以访问我的仓库：github.com/AlexV525/fl… 。你可以给它提一些需求，我觉得这样一款软件还是挺有意思的。

可能大多数人都没有想到，编写一个 Flutter 应用，跑在 macOS 上，能有这么简单。当然，看似短暂的 10 分钟并没有包括安装环境、搜索素材、提交到 git 的时间，但在这个时间范围内，完成相关的事情也是绰绰有余。

希望这篇文章能激起你学习 Flutter 的兴趣，或是在桌面端尝试 Flutter 的兴趣，又或是挑战自己编程速度的兴趣（别说 10 分钟不可能，实际上我用的时间还要更少）。

前言

前段时间写了一些介绍MVI架构的文章，不过软件开发上没有最好的架构，只有最合适的架构，同时众所周知，Google推荐的是MVVM架构。相信很多人都会有疑问，我为什么不使用官方推荐的MVVM，而要用你说的这个什么MVI架构呢？

不过我这几天查看Android的应用架构指南，发现谷歌推荐的最佳实践已经变成了单向数据流动 + 状态集中管理，这不就是MVI架构吗？
看起来Google已经开始推荐使用MVI架构了，大家也有必要开始了解一下Android应用架构指南的最新版本了~

本文主要基于Android应用架构指南，感兴趣的也可以直接查看原文

总体架构

两个架构原则

Android的架构设计原则主要有两个

分离关注点

要遵循的最重要的原则是分离关注点。一种常见的错误是在一个 Activity 或 Fragment 中编写所有代码。这些基于界面的类应仅包含处理界面和操作系统交互的逻辑。
总得来说，Activity或Fragment中的代码应该尽量精简，尽量将业务逻辑迁移到其它层

通过数据驱动界面

另一个重要原则是您应该通过数据驱动界面（最好是持久性模型）。数据模型独立于应用中的界面元素和其他组件。

这意味着它们与界面和应用组件的生命周期没有关联，但仍会在操作系统决定从内存中移除应用的进程时被销毁。

数据模型与界面元素，生命周期解耦，因此方便复用，同时便于测试，更加稳定可靠。

推荐的应用架构

基于上一部分提到的常见架构原则，每个应用应至少有两个层：

• 界面层 - 在屏幕上显示应用数据。


• 数据层 - 提供所需要的应用数据。

您可以额外添加一个名为“网域层”的架构层，以简化和复用使用界面层与数据层之间的交互

如上所示，各层之间的依赖关系是单向依赖的，网域层，数据层不依赖于界面层

界面层

界面的作用是在屏幕上显示应用数据，并响应用户的点击。每当数据发生变化时，无论是因为用户互动（例如按了某个按钮），还是因为外部输入（例如网络响应），界面都应随之更新，以反映这些变化。

不过，从数据层获取的应用数据的格式通常不同于UI需要展示的数据的格式，因此我们需要将数据层数据转化为页面的状态

因此界面层一般分为两部分，即UI层与State Holder，State Holder的角色一般由ViewModel承担

数据层的作用是存储和管理应用数据，以及提供对应用数据的访问权限，因此界面层必须执行以下步骤：

1. 获取应用数据，并将其转换为UI可以轻松呈现的UI State。


2. 订阅UI State，当页面状态发生改变时刷新UI


3. 接收用户的输入事件，并根据相应的事件进行处理，从而刷新UI State


4. 根据需要重复第 1-3 步。

主要是一个单向数据流动，如下图所示：

因此界面层主要需要做以下工作：

1. 如何定义UI State。


2. 如何使用单向数据流 (UDF)，作为提供和管理UI State的方式。


3. 如何暴露与更新UI State


4. 如何订阅UI State

如何定义UI State

如果我们要实现一个新闻列表界面，我们该怎么定义UI State呢?我们将界面需要的所有状态都封装在一个data class中。

与之前的MVVM模式的主要区别之一也在这里，即之前通常是一个State对应一个LiveData，而MVI架构则强调对UI State的集中管理

data class NewsUiState(

    val isSignedIn: Boolean = false,

    val isPremium: Boolean = false,

    val newsItems: List<NewsItemUiState> = listOf(),

    val userMessages: List<Message> = listOf()

)



data class NewsItemUiState(

    val title: String,

    val body: String,

    val bookmarked: Boolean = false,

    ...

)

以上示例中的UI State定义是不可变的。这样的主要好处是，不可变对象可保证即时提供应用的状态。这样一来，UI便可专注于发挥单一作用：读取UI State并相应地更新其UI元素。因此，切勿直接在UI中修改UI State。违反这个原则会导致同一条信息有多个可信来源，从而导致数据不一致的问题。

例如，如上中来自UI State的NewsItemUiState对象中的bookmarked标记在Activity类中已更新，那么该标记会与数据层展开竞争，从而产生多数据源的问题。

UI State集中管理的优缺点

在MVVM中我们通常是多个数据流，即一个State对应一个LiveData，而MVI中则是单个数据流。两者各有什么优缺点？

单个数据流的优点主要在于方便，减少模板代码，添加一个状态只需要给data class添加一个属性即可，可以有效地降低ViewModel与View的通信成本

同时UI State集中管理可以轻松地实现类似MediatorLiveData的效果，比如可能只有在用户已登录并且是付费新闻服务订阅者时，您才需要显示书签按钮。您可以按如下方式定义UI State：

data class NewsUiState(

    val isSignedIn: Boolean = false,

    val isPremium: Boolean = false,

    val newsItems: List<NewsItemUiState> = listOf()

){

	val canBookmarkNews: Boolean get() = isSignedIn && isPremium

}

如上所示，书签的可见性是其它两个属性的派生属性，其它两个属性发生变化时，canBookmarkNews也会自动变化，当我们需要实现书签的可见与隐藏逻辑，只需要订阅canBookmarkNews即可，这样可以轻松实现类似MediatorLiveData的效果，但是远比MediatorLiveData要简单

当然，UI State集中管理也会有一些问题：

• 不相关的数据类型：UI所需的某些状态可能是完全相互独立的。在此类情况下，将这些不同的状态捆绑在一起的代价可能会超过其优势，尤其是当其中某个状态的更新频率高于其他状态的更新频率时。


• UiState diffing：UiState 对象中的字段越多，数据流就越有可能因为其中一个字段被更新而发出。由于视图没有 diffing 机制来了解连续发出的数据流是否相同，因此每次发出都会导致视图更新。当然，我们可以对 LiveData 或Flow使用 distinctUntilChanged() 等方法来实现局部刷新，从而解决这个问题