公司内部打包平台可以根据不同分支不同渠道信息进行自动化打包。昨天发版打包时竟然发现了一个特别诡异的问题导致生成的 apk 安装包直接崩溃。
先选择含有听云sdk 代码的分支进行自动化打包,打包完毕验证 apk 没有问题; 然后选择不含有听云 sdk 代码的分支进行自动化打包,打包完成,验证 apk,直接启动崩溃。查看 log
java.lang.NoClassDefFoundError: Failed resolution of: Lcom/networkbench/agent/impl/instrumentation/NBSSQLiteInstrumentation;
看到上述 log,第一反应有点懵逼,怎么会包听云 sdk 中的类呢。明明代码中没有引入听云 sdk。 难道 代码 checkout 出错了?难道 build脚本我忘记 clean Task 了? 难道 clean 代码没有 clean 干净?……
两年之前android hot fix技术炒的非常热,各大厂商也是花样百出,各自献计,一时间出现了百家齐鸣的现象。但是各家都有各家的问题。当然网易其实也不甘落后,公司不同部门也研发了自己的热更新热补丁方案。网易新闻也是不断的探索未知,先后实践过一些方案, 目前使用的还是基于AOP的方案。
到目前为止,新闻android客户端上线热补丁技术也已经将近两年的时间了。也曾经为部门立下赫赫战功。一直想给这套方案起一个优雅的名字,但是始终没有想到满意的。直到今天早上,偶然间看到了一个单词Vulcan([‘vʌlkən]伏尔加,罗马神话中的火神与金工神),对这个词非常有感觉,那我就暂时已Vulcan对我们这套热补丁方案命名吧。
其实,很早之前就想写一下这套实践方案的思路,一直手懒没有写,今天看到了Vulcan这个词,一时兴起,提笔书之。
最近使用CoordinatorLayout和AppBarLayout,总结一下AppBarLayout的scrollFlags属性;
scrollFlags共有五中取值提供给AppBarLayout的ChildView使用, 在布局中直接使用app:layout_scroolFlags设置, 对应的职位scroll, enterAlways, enterAlwaysCollapsed, snap, exitUntilCollapsed; 代码中通过’setScrollFlags(int)’来进行设置。
git仓库从一台服务器迁移到另外一台服务器:
1) 从原有仓库克隆一份裸版库,sample
1 | git clone --bare git://github.com/username/project.git |
项目中网络底层库使用的okhttp,但是上层使用的Volley和glide;于是就设计的到了通用的请求header设置。于是通过Interceptor给设置的统一的header,但是okhttp的api确实有点坑啊。上线后发现图片的请求有两个UA,而且两个UA一个是我们设置的一个是glide默认的。
排查发现我们调用的Request.Builder.addHeader(k, v) 这个api是添加header,不会移除调之前有的header信息,比如设置UA,glide库设置了一个默认值,而我们又调用了这个api,这就产生了两个重复的UA。
正确的api是调用Request.Builder.header(k, v)来设置header,这个api会覆盖之前已有的header。
也可以先通过Request.Builder.removeHeader(K)先移除,然后再调用addHeader(K, V)