tn

3种比较合理的方式： 1.原生实现：在原生用一个链表来维护栈，每个viewcontroller入栈出栈，都会更新链表。当你需要pop多个页面，在链表里遍历搜索，你想要popTo（“[{name,path,targetIncluded}]”）的那个viewcontroller，再此viewcontroller之后的所有页面，加入到一个popList，遍历结束后原生直接finish掉popList里所有viewcontroller。（weex每个页面有个自定义的path，viewcontroller可以通过getUri获取path，原理就是对path进行匹配） 2.原生eventbus 3.Js实现：在Js里加2个自定义api： $push(url, ()=>{} ) $pop（v） $push到下个页面时，带上一个callback，将callback挂载在weex的跨页面的全局对象Q上，并在Q加一个$puuid属性，每次自增，以形式存储在全局对象Q上。 并加puuid加入到url的param中。 当在下一个页面$pop(v)时，可以获取param.puuid， 搜索全局对象Q上对应puuid的callback，触发之。 这样就可以实现下一页面的pop事件，会触发前一页面push事件所传递的回调函数。只要把回调函数写成pop自身，就可以实现你的需求 PS：weex的全局对象Q不一定好找，在0.28的sandbox模型中，weex页面很可能没有一个全局对象可供使用了。第三种方法会失效。（0.18版本我是挂载在Date ）

5.0以下需要倒入jar，然后在Application的attch方法中进行初始化。或者 应用application 继承 MultiDexApplication 也行

最常见的，框架类的sdk，就是 copy进项目文件夹，有能力的自己改。但是后续sdk升级，维护成本随着时间会提高。后续其他人接手 && 自己修改点和官方修改点重复 && 当初交接文档不全的话，接手的人会比较头疼。 另外像银行公家的这种sdk还是提工单让他们自己去改

synchronized关键字的两个线程1和线程2，如果当前线程1获得锁，线程2线程等待。如果线程1阻塞，线程2则会一直等待下去，而Lock锁就不一定会等待下去，如果尝试获取不到锁，线程可以不用一直等待就结束。 synchronized的锁可重入、不可中断、非公平，而Lock锁可重入、可判断、可公平（两者皆可）

1.8jdk的HashMap优化为红黑树，又会考你什么时候红黑树会退化为链表...doge～

多线程下，不加volatile的双检锁是没有意义的。 在给单例对象初始化的过程中,jvm做了下面3件事: 1.给单例对象分配内存 2.调用构造函数 3.将单例对象指向分配的内存空间 由于jvm的"优化",指令2和指令3的执行顺序是不一定的,当执行完指定3后,此时的单例对象就已经不在是null的了,但此时指令2不一定已经被执行。 假设线程1和线程2同时调用单例对象的方法,此时线程1执行完指令1和指令3,线程2抢到了执行权,此时单例对象是非空的。 所以线程2拿到了一个尚未初始化的单例对象,此时线程2调用这个单例就会抛出异常。 所以需要volatile 禁止指令重排序

同问，在segmentfault吐槽这个plugin的开发集成文档差，直接封杀提问，暴露出的问题不解决，直接堵嘴，好厉害