注册
环信即时通讯云

环信即时通讯云

单聊、群聊、聊天室...
环信开发文档

环信开发文档

元宇宙讨论

元宇宙讨论

元宇宙到底是什么?来畅所欲言
RTE开发者社区

RTE开发者社区

汇聚音视频领域技术干货,分享行业资讯
技术讨论区

技术讨论区

技术交流、答疑
资源下载

资源下载

收集了海量宝藏开发资源
iOS Library

iOS Library

不需要辛辛苦苦的去找轮子, 这里都有
Android Library

Android Library

不需要辛辛苦苦的去找轮子, 这里都有

又一款知名APP宣布停运:上线12年,全国2亿人在用

日前,#百度糯米APP停运#的话题突然引发热议。近日,百度糯米官网发布公告称,因公司业务调整,百度糯米APP将停止服务与运营,预计将于2022年12月正式停止相关服务。目前在苹果应用商店和大部分安卓应用商店均已搜索不到百度糯米APP。据联商网报道,百度客服人员...
继续阅读 »

日前,#百度糯米APP停运#的话题突然引发热议。

近日,百度糯米官网发布公告称,因公司业务调整,百度糯米APP将停止服务与运营,预计将于2022年12月正式停止相关服务。

目前在苹果应用商店和大部分安卓应用商店均已搜索不到百度糯米APP。

据联商网报道,百度客服人员表示:“百度糯米已经没有商家了,已下线并停止服务。”


对于年轻一代来说,百度糯米是一个陌生的名字,有不少“00后”网友表示:“听都没听说过”。

但对于不少经历过团购网大战的网友而言,百度糯米承载着他们不少记忆。


作为多年前“千团大战”中的一大巨头,百度糯米曾一度与美团网、大众点评形成三足鼎立的格局。

有网友评论称:“那时候每周六有6.6的电影票,都是在糯米买的”。


时间回到2010年,那时候是团购业务发展最巅峰的时期,全网至少有5000家网站在做团购服务。

百度糯米,前身为人人旗下的糯米网。糯米网是国内最早的一批团购网站,比现在的“巨无霸”美团,也就晚上线3个月而已。

2011年,人人公司纽交所上市后,糯米网甚至还成了国内首家“上市”的团购网站。

2014年,百度全资收购糯米网,并在2014年3月6日将其更名为百度糯米。

服务覆盖美食、电影、酒店、旅游、充值、外卖等,合作本地商户超过200万家。


这时候的千团大战也愈演愈烈,百度、美团、大众点评三家公司占据九成左右的市场份额。

多家团购平台轮番进行补贴轰炸,市场价格越来越卷。

以至于经历过当年千团大战的小伙伴们,可能对天天吃霸王餐的日子都记忆犹新。


2015年,百度集团宣布将200亿投入百度糯米,李彦宏曾放下豪言:“砸200亿也得把糯米做好”。

当年还有报道称,百度糯米单日流水冲破3.5亿大关,一时间风光无两。

然而令人没想到的是,就在同一年,美团和大众点评宣布合并,合并之后的美团与大众点评一举占领了超过八成的市场份额。

千团大战就此逐渐落幕。

直到2016年,人工智能技术迎来大爆发,国内外的巨头们纷纷入场。

2017年,百度战略转向“All in AI”,百度糯米等也陷入沉寂。


七年后的今天,本地生活服务领域已然被美团和饿了么占据了几乎全部市场,后起之秀如抖音和快手也在虎视眈眈。

不过,百度糯米最终关停,并不代表百度放弃布局本地生活服务。

目前在百度app页面,“惠生活”入口已经汇集了大量本地生活服务,包括美团外卖、电影票、机票酒店等。

业内相关人士表示,对百度糯米关停并不意外,“百度现在的重心是人工智能,百度APP、百度地图都在承接本地生活服务,没有再单独运营一个APP的必要了”。

来源:扩展迷Extfans

收起阅读 »

情绪宣泄App:十年前IT男编程撩妹纪实

阅读本文,你将收获以下内容:1、通过观察11年前的Android代码,了解安卓开发生态近十年间的演进。2、通过了解这款创意App的功能,对IT男该如何运用技术做出反思。3、不幸看到作者大学时期的照片,形象极其猥琐、狼狈、不堪……够了,谁在动键盘?!前言因为在掘...
继续阅读 »

阅读本文,你将收获以下内容:

1、通过观察11年前的Android代码,了解安卓开发生态近十年间的演进。

2、通过了解这款创意App的功能,对IT男该如何运用技术做出反思。

3、不幸看到作者大学时期的照片,形象极其猥琐、狼狈、不堪……够了,谁在动键盘?!

前言

因为在掘金的创作者群里比嘻哈,有人觉得我经常信口开河,尤其我写了那篇《我裁完兄弟们辞职了,转行做了一名小职员》后,有掘友评论:“这篇文章艺术成分很高”、“感觉是编故事”等等。


其中,我文章里提到过一句:我大学期间搞过Android的APP去运作。


今天,就说说这件事,一来展现下创意作品,二来给自己挽回一些微信……违心……维新……不要了。

女朋友

回到2010年,那时我上大二,谈了一个女朋友,她现在是我孩子的妈妈。

女朋友哪里都好,漂亮、温柔、大方,唯一一点就是脾气太大。

因为我不会制造浪漫,所以女朋友经常对我发脾气,一发脾气就不理我。

我一想,如果她不理我的时间设为N,如果N值无限大,那就相当于分手了,这感情不就黄了吗?

情侣在吵架冷战期间,如何才能不见面也能如同见面一般宣泄情绪,从而刷存在感呢?

可以做一款App来解决这个问题。

冷战红娘App

这款App我取名叫“冷战红娘”,意思是情侣在冷战期间调和关系的红娘媒介,并且我还亲自设计了LOGO和启动页。


一个安卓小机器人,手里拿着玫瑰花,表示示好,头顶两个触角间发出电波,表示科技和智能。

那一年,我才19岁。不行了,我膨胀得快要爆掉了。

功能简介

本软件主要有三大功能:涂鸦对方照片、写情绪日记、告知情绪结果。

下面是首页的效果:


下面是实现代码的目录结构:


女朋友名字中带“冰”,我名字中带“磊”,因此项目名是LoveBing,包名是com.lei.lovebing01

有安卓小伙伴看到目录结构可能会发现少文件,说我在糊弄你,起码你的build.gradle得有吧。

朋友,这是2010年的安卓项目,那时的版本号是SdkVersion="8",也就是Android 2.2,现在最新版本已经到了API 32, Android 12了。从互联网时代来看,就好像是现在和清朝的区别。

那时还没有动态权限请求,存取文件也不用FileProvider,你可以随意读取其他程序的内部数据,应用层就可以静默发送短信和获取定位,开发者可以更好地实现自己的想法,不必受到很多限制。当然,这在现在看来是不安全的。所以,任何事物的成熟都是有周期的。

那时候也没有现在这么多的第三方框架,基本都是调用Android原生的API,操作数据库需要直接使用android.database.sqlite.SQLiteDatabase,SQL语句要自己写,操作异常要自己处理。

下面,就让我们跟随功能,结合代码,一起去剖析一下这款App吧。

涂鸦

女朋友生气不理我了,短信不回,电话不接,女生宿舍我又进不去。但是,她又有怨气没地方宣泄。这时,她就会打开这个功能,可以把我的头像摆出来,然后进行各种攻击,支持花色涂抹,支持往我的照片上放小虫子、扔臭鸡蛋、使用炸弹爆破效果等等。天啊,我这是怎么了……不但有这种想法,而且还开发出了功能。


其实,要实现这个功能,非常简单。

首先,整个页面的数据,是通过配置完成的,各种颜色,工具,以及图标,需要事先声明好。

//信手涂鸦里的数据=====================================================
//工具的名字
public final static String[] colortext={"红色", "黄色","绿色",
"粉色", "黑色", "紫色", "蓝色", "浅绿", "棕色"};
//工具的图片
public final static int[] colorpic = {
R.drawable.color1, R.drawable.color2,
R.drawable.color3, R.drawable.color4,
R.drawable.color5, R.drawable.color6,
R.drawable.color7, R.drawable.color8,
R.drawable.color9 };

//信手涂鸦颜色选择
public  static final int red = 0;
public  static final int yellow = 1;
public  static final int green = 2;
public  static final int pink = 3;
public  static final int black = 4;
public  static final int purple = 5;
public  static final int blackblue = 6;
public  static final int lightgreen = 7;
public  static final int orange = 8;

//使用工具里的数据=====================================================
public final static String[] toolstext={"鸡蛋", "炸弹","生物","喷溅"};//工具的名字
public final static int[] toolspic = {//工具的图片
R.drawable.dao, R.drawable.zhadan01,R.drawable.tool,R.drawable.penjian
};

public final static int[][] toolspic_01 = {//工具的图片使用后
{R.drawable.dao_01, R.drawable.dao_02, R.drawable.dao_03,R.drawable.dao_01}
,{ R.drawable.baozha01, R.drawable.baozha02, R.drawable.baozha03, R.drawable.baozha04}
,{R.drawable.tools_01, R.drawable.tools_02, R.drawable.tools_03, R.drawable.tools_04}
,{R.drawable.penjian01, R.drawable.penjian02, R.drawable.penjian03, R.drawable.penjian04}
};

通过配置的方式,有一个极大的好处,那就是以后你增加新的工具,不用修改代码,直接修改配置文件即可。

下面一步就是使用一个Canvas画板,把上面的配置画到画布上,并响应用户的交互,为此我新建了一个CanvasView,它继承了View

public class CanvasView extends View{

   public Bitmap[][] bitmapArray;
   private Canvas  mCanvas;

   public CanvasView(Context context) {
       super(context);
       bitmapArray=new Bitmap[MyData.toolspic.length][4];//实例化工具数组
       //载入工具需要的图像
       InputStream bitmapis;
       for(int i=0; i<MyData.toolspic_01.length; i++){
           for(int j=0; j<MyData.toolspic_01[i].length; j++){
               bitmapis = getResources().openRawResource(MyData.toolspic_01[i][j]);
               bitmapArray[i][j] = BitmapFactory.decodeStream(bitmapis);
          }
      }
       // 使用mBitmap创建一个画布
       mCanvas = new Canvas(mBitmap);
       mCanvas.drawColor(0xFFFFFFFF);//背景为白色
  }
     
   //在用户点击的地方画使用的工具
   public void drawTools(int bitmapID){
       Random rand = new Random();
       int myrand = rand.nextInt(bitmapArray[bitmapID].length);
       mCanvas.drawBitmap(bitmapArray[bitmapID][myrand], mX-bitmapArray[bitmapID]
          [myrand].getWidth()/2, mY-juli-bitmapArray[bitmapID][myrand].getHeight()/2, null);
  }
   ……
}

上面只是部分关键代码,主要展示了如何加载图片,以及如何响应用户的操作,基本无难点。

女朋友毕竟花费了一番功夫,作品肯定要给她保留,因为她可能要展示给我看:你看,昨天你惹我多严重,我把你画成这样!


涂鸦完成之后,文件保存到SD卡目录即可。权限管理方面,在AndroidManifest.xml中注册一下就行,除此之外,再无其他操作。

<!--  向SD卡写入数据的权限  -->
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

当然,现在不可以了,Android 6.0以后,你得动态申请权限了。

值得一说的是,上面的图片浏览控件叫ImageSwitcher,这是个老控件了,很简单就可以实现幻灯片浏览的效果。

日记

如果涂鸦无法完全解气,为了能让女朋友把生气的原因表述明白,我特意增加了这个生气日记的功能。效果等同于她面对面骂我,期望她写完了气也就消了。


你觉得数据应该保存到哪里?我首选的是Android内嵌的Sqlite3数据库。

Android中最原始的sqlite数据库操作是这样的,先利用官方的SQLiteOpenHelper创建数据库和数据表。

import android.content.Context;
import android.database.sqlite.SQLiteDatabase;
import android.database.sqlite.SQLiteOpenHelper;

public class DBOpenHelper extends SQLiteOpenHelper {

private static final String DATABASENAME = "angrydiary.db"; //数据库名称
private static final int DATABASEVERSION = 1;//数据库版本

public DBOpenHelper(Context context) {
super(context, DATABASENAME, null, DATABASEVERSION);
}

public void onCreate(SQLiteDatabase db) {
//建数据表 message 日记
db.execSQL("CREATE TABLE message (message_id integer primary key autoincrement,
                   message_title varchar(50), message_text varchar(500), message_state integer)");
}

public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
db.execSQL("DROP TABLE IF EXISTS message");
onCreate(db);
}
}

然后再写上操作数据表数据的方法。就拿生气日记信息的数据处理举例子。

import android.content.ContentValues;
import android.content.Context;
import android.database.Cursor;
import android.database.sqlite.SQLiteDatabase;

public class MessageServiceDB {

private DBOpenHelper dbOpenHelper;
//构造函数
public MessageServiceDb(Context context) {
this.dbOpenHelper = new DBOpenHelper(context);
}
//保存数据
public void save(Message message){
SQLiteDatabase db = dbOpenHelper.getWritableDatabase();
ContentValues values = new ContentValues();
values.put("message_title", message.getTitle());
values.put("message_text", message.getText());
db.insert("message", null, values);
db.close();
}
//获得数据
public List<Message> getScrollData(Integer offset, Integer maxResult){
List<Message> messageList = new ArrayList<Message>();
SQLiteDatabase db = dbOpenHelper.getReadableDatabase();
Cursor cursor = db.query("message", null, null, null, null, null, "message_id desc", offset+","+ maxResult);
while(cursor.moveToNext()){
Integer message_id = cursor.getInt(cursor.getColumnIndex("message_id"));
String message_title = cursor.getString(cursor.getColumnIndex("message_title"));
String message_text = cursor.getString(cursor.getColumnIndex("message_text"));
Message message = new TvMessage(message_id,message_title, message_text);
messageList.add(message);
}
cursor.close();
db.close();
return messageList;
}
//删除一项数据
public void delete(Integer id){
SQLiteDatabase db = dbOpenHelper.getWritableDatabase();
db.delete("message", "message_id=?", new String[]{id.toString()});
db.close();
}  
}

利用之前构造好的数据库帮助类dbOpenHelper,然后调用增删改查进行数据处理。这里面的增删改查,有两种方式实现,一种直接写Sql语句,另一种支持对象操作。我基本上都是用的对象操作,比如删除直接就是db.delete(xx)

日志列表我也是煞费苦心,为了便于了解女朋友还对哪些事情生气,我特意开发了生气事件黑白名单功能。一个事件可以反复标记是否原谅我了。这样可以了解女朋友心中还有哪些心结,可以让我逐个攻破。


此处调用一个修改方法就可以了,其实就是取出message对象后重新setState一个新值就可以了。

//修改信息状态
public void update(Message message){
   SQLiteDatabase db = dbOpenHelper.getWritableDatabase();
   ContentValues values = new ContentValues();
   values.put("message_state", message.getState());
   db.update("message", values, "message_id=?", new String[]{message.getId().toString()});
   db.close();
}

需要注意的是,对于每次打开数据库或者Cursor,都要记得关闭,不关闭不会影响功能,但是会带来风险。现在你使用各种框架的话,完全不用考虑这些操作,因为他们都帮你做了。

安卓开发,以前和现在,用SDK和用第三方框架,就像是汽车的手动挡和自动挡,其中的优劣,自己体会。虽然我是从老手动挡过来的,但是我站自动挡这边,因为我不会傻到逆着发展趋势去行走。

反馈

女朋友也涂鸦了,也写了生气日记,最后应该也累了。为了缓解她的疲劳,我特意开发了一个看图发愣的功能。只需要点开看图发愣,就会随机出现一个唯美的动态图,并且伴随着唰唰的雨声,可以让她看上几个小时,仔细思考人生,思考我这个男朋友值不值得交往。


对于如何展示gif动态图,前端可能要骂人了,因为gif还需要动代码吗?浏览器不全给解释了。但是,当时我需要自己去解析,安卓原生的图片控件是无法展示动图的。所以,你看老一辈的程序员面临多少困难,新一代的程序员完全不用考虑这些。所以,你们应该把更多精力放在更高级的研究上,因为我相信你们也有你们的困难点。

这个图很美,我单独拿出来了,朋友们可以保存下来,自己看。或者,你试试自己去解析一下。


好了,现在总该不生气了吧。针对于此时的场景,我又开发了一个快捷短信功能,女朋友可以选择短信模板,快速给我发送短信息,给我一个台阶,让我及时去哄她。她可以说不是她发的,是我开发的软件发的,这样可以避免“她先联系的我”这类不利立场的产生。


我一贯执行配置策略,短信模板也是写到value文件夹下的xml文件中的。

<string-array name="message_ex"> 
   <item>不要生气了,我错了!</item>  
   <item>我不生气了,你快点陪我逛街!</item>  
   <item>讨厌,还不给我打电话!</item>  
   <item>我错了,我不该对你发火的!</item>  
   <item>三个小时内给我打电话!</item>  
   <item>快给我给我买爆米花!</item>    
</string-array>

关于发送短信,这里面有两点细节。

SmsManager smsManager = SmsManager.getDefault();
PendingIntent sentIntent = PendingIntent.getBroadcast(DuanxinActivity.this, 0, new Intent(), 0);
//如果字数超过70,需拆分成多条短信发送
if (text.length() > 70) {
   List<String> msgs = smsManager.divideMessage(text);
   for (String msg : msgs) {
   smsManager.sendTextMessage(phone, null, msg, sentIntent, null);                        
  }
} else {
   smsManager.sendTextMessage(phone, null, text, sentIntent, null);
}

第一,为什么不调用Intent(Intent.ACTION_SEND)让系统去发送短信?一开始确实是这样的。但是,后来改良为调用代码应用内发送了。因为我不想让女朋友离开我的软件,跳到第三方系统应用,避免用户跳出场景,因为有时候女朋友会夺命连环发短信(告知对方问题很严重,提高优先级),需要来回切程序,这样用着不爽,就更生气了。而且自己发送我还能捕获到发送结果,给出“发送成功”的温馨提示,但是交给第三方应用发送你是获取不到的。

第二,关于字数超过70,需要拆成多条短信,这也是经过实践得来的。满满的都是痛。

有同学不明白为什么要发短信,因为那时候还没有微信,微信是2011年才出来的。

后记

后来,经过不断反馈和改良,这款App越来越完善。

最后,女朋友看我这么用心地对待这份感情,尤其对于她反馈的软件问题,我询问地非常仔细(复现场景、发生时间、前后操作流程),修改地也非常及时(改完了就让她再试试看),她感觉我是一个靠谱和细心的人,于是她也慢慢地不再那么容易生气了。

再后来,有一个全国高校的大学生IT技能比赛,我的老师就让我拿这个作品参赛了,最后去了北京大学进行了决赛。

虽然这款App技术含量不高,但它是一款身经百战的App,它经过了多次迭代,因为用户体验和创意比较好,我最终获得全国第七名的成绩,荣获二等奖。

下面是证书,教育部的证书我是不敢造假的,我用Photoshop(是的,我也会做UI设计)做了简单的遮挡和放大,主要想让大家看一下日期确实是2011年,和我文章里描述的一样(我没有编故事)。


这款App真的没有任何技术含量,无外乎控件的罗列、画板的绘制、数据的存储。我想现在的每一个大学生都能做的到。但是不夸张地讲,它看起来却是很强大的样子。而究其根源,我想应该就是它运用技术手段尝试去解决生活中的问题,让效果得到了放大,使它具备了生命力。

直至今天,我依然在做类似(用技术解决生活中的问题)的事情。

最后,我想借助掘金App的标语结束本文,这也是我每天都会看到的一句话:

相信技术,传递价值。

作者:TF男孩
来源:juejin.cn/post/7123985353878274056

收起阅读 »

《羊了个羊》创始人被母校制成展牌

就连他的母校长治学院也开始整花活儿了——可以说是very very的显眼,引发了无数学生的围观。△图源:网络“活广告”再引争议从图片中的信息来看,张佳旭此前就读于长治学院计算机系网络工程1101班。2021年,张佳旭创业成立了北京简游科技有限公司,并于2022...
继续阅读 »

《羊了个羊》全网爆火,创始人张佳旭顺带着也大火了一把。

就连他的母校长治学院也开始整花活儿了——

在最近的迎新日上,把张佳旭的履历制成2米 x 1.5米的大型展牌。

可以说是very very的显眼,引发了无数学生的围观。


图源:网络

然后随着这事的曝光,相关话题又双叒叕成了热议焦点


母校如此花活儿,被网友直呼“招生的活广告啊”!

“活广告”再引争议

在这张大型展牌中,张佳旭的头像和个人简历格外醒目。

从图片中的信息来看,张佳旭此前就读于长治学院计算机系网络工程1101班。

在2017年至2021年期间,他在北京豪腾嘉科科技有限公司担任游戏制作人。

2021年,张佳旭创业成立了北京简游科技有限公司,并于2022年推出游戏《羊了个羊》。

而占据展牌另一半的内容,便都是与《羊了个羊》相关的了。

但也正是张佳旭母校这一波“活广告”的操作,让相关话题再次被热议了起来。

虽然从流露出来的视频中,长治学院的学生有表示“为学长感到骄傲”的,但话题之下舆论风向却并非如此:


网友们如此评论,直接原因便是认为校方在蹭张佳旭的热度。

但根本上是认为“《羊了个羊》这款游戏‘德不配位’,不适合当做‘校园榜样’”。

甚至还有网友直言道:这算是招生“减”章了吧!


除了被吐槽得最厉害的“就是为了赚广告费”之外,大家普遍觉得这个游戏有抄袭的嫌疑。

其一,不少人指出:“羊”的画风和模式都很像3Tiles,不过3Tiles有多重关卡,难度是层层递进的那种。


左为《羊了个羊“截图,右为《3 Tiles》截图

不过张佳旭否认了这种说法,并表示他们采用的就是最基础的“三消”玩法,类似的游戏非常多。

其二,不光是游戏模式和界面,“羊”的背景音乐也颇受争议——

很多人在玩这个游戏的时候觉得这个BGM怎么这么耳熟,结果一搜才发现:这不就是洛天依和言和的《普通Disco》吗?(没有人声罢了)

除了批评这个游戏本身,有人甚至从《羊了个羊》上升到我国的游戏产业,觉得这种粗糙的换皮游戏屡屡出现居然还屡屡成功,打击了不少精细做游戏者的雄心。

在网友们纷纷表达不满的同时,一位长治校友却指出,其实在“羊”蹿红之前,学校每年迎新都会为张佳旭做版面,因为他自己创业做公司。

所以,这次张佳旭登上迎新牌子其实是学校的常规操作而已,并不是有意炒作

这位校友还提到同样毕业于长治学院的“七一勋章”获得者、“时代楷模”黄文秀。


黄文秀本科就读于长治学院,后以北京师范大学哲学学院读研究生的身份毕业,并到广西壮族自治区百色市乐业县新化镇百坭村担任驻村第一书记。可惜黄在2019年遭遇山洪因公殉职,年仅30岁。

对于这所二本院校而言,他们的优秀校友本来就比不上985、211那般灿若繁星。所以从某种角度来看,张佳旭和黄文秀都算学校的“名人”了,这些可能确实有助于学校宣传。

当然话说回来,《羊了个羊》,似乎从爆火的当天开始,就没有摆脱过舆论的压力。

而面对种种质疑,张佳旭也给出了他的说法。

走红的背后:3个人3个月

最初,《羊了个羊》的研发团队仅有3人,总共开发的时长也只有3个月之久;其它组的人员构成也是颇有意思。

例如有从行政转到游戏策划的;有从Android、IOS转的creator开发;甚至还有自学服务器搭建的。


但在此之前,成立于2021年1月的简游科技并不是说没经历过大日活(DAU)的产品。

像《海盗来了》的DAU最高达到了2500万,《成语小秀才》也有过900万的DAU。

但《羊了个羊》能火成这样,用张佳旭在与北青报交流时的话说就是“(DAU)数据已经完全超出我的认知了”。

至于走红的原因,张佳旭表示前期并没有在社交平台上进行宣发。

主要还是因为其第二关难以突破,还有诸如“有任何一个人不玩《羊了个羊》我都会伤心的”等话题的出现,“口口相传”效应就开始了。

于是乎大批玩家便陆陆续续涌入并发起挑战。

而正所谓树大招风,随着《羊了个羊》的走红,一张“营收数据”首当其冲地在网络上也传了起来。


对此,张佳旭表示:

那些都是假的。我们在这个项目上没有开放banner窗口。正常来说banner收入可以占到运营收入的很大一部分。

这一点上,网上众多消息称马化腾也出来辟谣——“是PS伪造的”。


除了营收之外,“招聘技术人员”也成了相关热议话题。

但张佳旭对此是这么解释的:

我们一直在招人,只是出名之前没有人看得上。

“游戏寒冬”嘛,小公司随时可能关门。

甚至张佳旭还自嘲回忆说,之前有人来面试发出感慨“啊!这么小的公司啊!”

而在《羊了个羊》火了之后,通宵工作成了团队技术人员的常态。

他们的主要工作内容现在就是抵御攻击

这几天我们一直被攻击,因为有很多盗版游戏已经上线了,它们想把我们攻击掉,自己蹭这波热度。

除此之外,张佳旭表示现在最希望看到的结果,就是“热度能降下来”

One More Thing

就在最近,《羊了个羊》通关截图在朋友圈刷屏。

不仅是卡片的堆叠方式发生了改变,相同卡片的出现率也大幅提高。


而在体验过后,不少玩家纷纷表示“难度降低了”;从各省“羊群”通关人数上来看,也是比此前要高出不少。

但除此之外,还有个比较有意思的现象。

在一款名叫《三国哈哈哈》的游戏里,第48关内嵌了一个叫《马了个马》的小游戏。

虽然玩法和《羊了个羊》一模一样,都是三消游戏,但它却提供了一个硬核消除大法——

选个炸弹,洗一次牌,再依次选木桩、2个轮子和一个炮筒,然后就会升级成一个大炮。

“轰的一下”,过关……


然后在“羊”、“马”之后,这不“牛了个牛”又来了……


据这位博主表示,他是被《羊了个羊》气到了,所以“亲手花了8小时开发了自己的小游戏”……

啊这……打不赢就自己造的节奏啊

参考链接:

[1]http://weibo.com/7575030448/M7m0yECN4?type=comment
[2]http://www.zhihu.com/question/555490265
[3]http://baijiahao.baidu.com/s?id=1744942269985078514&wfr=spider&for=pc
[4]http://mp.weixin.qq.com/s/lu2xN3IjGY_zKzlfWje2pg
[5]http://mp.weixin.qq.com/s/y_oMa4WJRsythUNtweQa4Q

来源:来源:量子位 | 公众号 QbitAI

收起阅读 »

什么时候要用到本地缓存,比Redis还要快?怎么用?

导言试想一下这么一个场景,一用户想要把他看了好长时间的极速版视频积攒的余额提现,于是他点击了提现按钮,哗啦声一响,他的钱就到银行卡了。这样一个对于用户很简单的动作但是对于后台往往牵扯到十几个服务(公司规模越大、规范性要求越高,整个调用链路的服务就越多),而你负...
继续阅读 »

导言

试想一下这么一个场景,一用户想要把他看了好长时间的极速版视频积攒的余额提现,于是他点击了提现按钮,哗啦声一响,他的钱就到银行卡了。这样一个对于用户很简单的动作但是对于后台往往牵扯到十几个服务(公司规模越大、规范性要求越高,整个调用链路的服务就越多),而你负责了一个交叉验证的服务,主要负责校验上游传递给你的记账标识、资金流标识、付款方账号、收款方账号是否和最初申请配置的一样。

为了产品的良好体验,大老板要求请求耗时最多1s要让用户看到结果,于是各个服务的负责人battle了一圈,给你的这个服务只预留了50ms的时间。你一想,这还不简单,直接Redis缓存走起来。Redis那一套霹雳啪撒一顿输出,测试环境也没有一点问题,结果上线后傻眼了,由于网络波动等原因你的服务经常超时,组长责令你尽快解决,再因为你的服务超时导致他被大老板骂,你的绩效就别想了。这种时候,你该怎么优化呢?

理论

要想做到比Redis还要快,首先要知道Redis为什么快,最直接的原因就是Redis所有的数据都在内存中,从内存中取数据库比从硬盘中取数据要快几个数量级。

那么想比Redis还要快,只能在数据传输上下功夫,把不同服务器之间、甚至不同进程之间的数据传输都省略掉,直接把数据放在JVM中,写个ConcurrentMap用于保存数据,但是既然是缓存,肯定还要整一套删除策略、最大空间限制、刷新策略等等。自己手撸一套代价太大了,肯定有大公司有类似的场景把这样的工作已经给做了,而且他还想赚个好名声,github里搜一搜,肯定有现成的解决方案。于是今天我们的主角就出场了,Guava Cache.

实践

首先用一段代码整体介绍一下Guava Cache的使用方式,Cache整体分为CacheBuilder和CacheLoader两个部分,CacheBuilder负责创建缓存对象,再创建的时候配置最大容量、过期方式、移除监听器,CacheLoader负责根据key来加载value。

LoadingCache<Key, Config> configs = CacheBuilder.newBuilder()
.maximumSize(5000)
.expireAfterWrite(30, TimeUnit.MINUTES)
.removalListener(MY_LISTENER)
.build(
new CacheLoader<Key, Config>() {
@Override
public Graph load(Key key) throws AnyException {
return loadFromRedis(key);
}
});

适用场景

  1. 凡事都是有代价的,你愿意接受占用内存空间的代价来提升速度
  2. 存储占据的数据量不至于太大,太大会导致Out of Memory异常
  3. 同一个Key会被访问很多次。

CacheLoader

CacheLoader并不是一定要在build的指定,如果你的数据有多种加载方式,可以使用callable的方式。

  cache.get(key, new Callable<Value>() {
@Override
public Value call() throws AnyException {
return doThingsTheHardWay(key);
}
});

过期策略

过期策略分为大小基准和时间基准,大小基准可以通过CacheBuilder.maximumSize(long)CacheBuilder.maximumWeight(long).指定,maximumSize(long)适用于每个值占用的空间基本上相等或者差异可以忽略不计,只看key的数量,而maximumWeight(long)则会计算出每个值所占据的权重,并保证总权重不大于设置值,其中每个值的计算方式可以通过weigher(Weigher)进行设置。

时间基础就很好理解,分为expireAfterAccess(long, TimeUnit)expireAfterWrite(long, TimeUnit),分别是读多久后失效和写入缓存后多久失效,读失效事每次读缓存都会为该值续命。

刷新策略

CacheBuilder.refreshAfterWrite(long, TimeUnit) 方法提供了自动刷新的能力,需要注意的是,如果没有重写reload方法,那么只有当重新查到该key的时候,才会进行刷新操作。

总结

抛出了问题总要给出答案,不然就太监了,那么导言中的问题我是如何做的呢,我通过guava cache和redis整了一套二级缓存,并且在服务启动时进行了扫表操作,将所有的配置内容都预先放到guava cache中。guava的刷新时间设置为五分钟,并重写了刷新操作强制进行刷新,redis的过期时间设置为一天,并且在数据库内容更新后,删除对应Redis缓存中的值。如此便可以保证,绝大多数情况下都能命中本地中的guava 缓存,且最多有5分钟的数据不一致(业务可以接受)。 凡事必有代价,作为一名后端开发就是要在各种选择之间进行选择,选出一条代价可接受、业务能接受的方案。


作者:日暮与星辰之间
链接:https://juejin.cn/post/7146946847465013278
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »

连你家电器的算力都不放过,新发现Linux恶意软件用IoT设备挖矿,大小仅376字节

继电脑和手机后,挖矿病毒也盯上了IoT设备。无论是智能冰箱、彩电还是洗衣机,但凡有点算力的(物联网和端侧)设备都可能被这种病毒感染,用于挖掘加密货币等。AT&T Alien Labs新发现的Linux恶意软件Shikitega就是一例。相比之前的一些I...
继续阅读 »

继电脑和手机后,挖矿病毒也盯上了IoT设备。

无论是智能冰箱、彩电还是洗衣机,但凡有点算力的(物联网和端侧)设备都可能被这种病毒感染,用于挖掘加密货币等。


AT&T Alien Labs新发现的Linux恶意软件Shikitega就是一例。

相比之前的一些IoT设备,Shikitega更加隐蔽,总共只有376字节,其中代码占了300字节。

那么,这个新型恶意软件究竟是如何感染设备的?

利用加壳技术“隐身”

具体来说,Shikitega核心是一个很小的ELF文件(Linux系统可执行文件格式)。


这个ELF文件加了动态壳,以规避一些安全防护软件的查杀。

加壳,指利用特殊算法压缩可执行文件中的资源,但压缩后的文件可以独立运行,且解压过程完全隐蔽,全部在内存中完成。

动态壳则是加壳里面更加强力的一种手段。

从整体过程来看,Shikitega会对端侧和IoT设备实施多阶段感染,控制系统并执行其他恶意活动,包括加密货币的挖掘(这里Shikitega的目标是门罗币):


通过漏洞利用框架Metasploit中最流行的编码器Shikata Ga Nai(SGN),Shikitega会运行多个解码循环,每一个循环解码下一层。


最终,Shikitega中的有效载荷(恶意软件的核心部分,如执行恶意行为的蠕虫或病毒、删除数据、发送垃圾邮件等的代码)会被完全解码并执行。

这个恶意软件利用的是CVE-2021-4034和CVE-2021-3493两个Linux漏洞,虽然目前已经有修复补丁,但如果IoT设备上的旧版Linux系统没更新,就可能被感染。

事实上,像Shikitega这样感染IoT设备的恶意软件已经很常见了。

例如在今年三月,AT&T Alien Labs同样发现了一个用Go编写的恶意软件BotenaGo,用于创建在各种设备上运行的僵尸网络(Botnets)。

对此有不少网友吐槽,IoT设备的安全性堪忧:


也有网友认为,IoT设备应该搞WiFi隔离,不然就会给病毒“可乘之机”:


而除了IoT设备,更多人的关注点则放在了Linux系统的安全上。

Linux恶意软件数量飙升650%

这几年来,Linux恶意软件的多样性和数量都上升了。

根据AV-ATLAS团队提供的数据,新的Linux恶意软件的数量在2022年上半年达到了历史新高,发现了近170万个。

与去年同期(226324个恶意软件)相比,新的Linux恶意软件数量飙升了近650%

除了Shikitega,近来发现的流行Linux恶意软件也变得更加多样,已知的包括BPFDoor、Symbiote、Syslogk、OrBit和Lightning Framework等。


图源AV-ATLAS

对此有网友提出疑惑,正因为Linux开源,它似乎无论如何都会面临病毒和恶意软件的泛滥?


有网友回应称,一方面,虽然旧的Linux系统可能充满漏洞、成为病毒的“温床”,但它在经过升级、打了补丁之后就会变好。

另一方面,开发恶意软件本身也不是“有手就能做”的事情。

毕竟安全研究人员会不断修复并堵上所有漏洞,而恶意软件开发者必须在他们修复前找到漏洞、开发出恶意软件,还得让它们“大流行”,最终实现自己的目的。


要是你家还有在用老旧Linux系统的设备,要注意及时升级or做好网络隔离等安全措施~

参考链接:
[1]https://cybersecurity.att.com/blogs/labs-research/shikitega-new-stealthy-malware-targeting-linux
[2]https://arstechnica.com/information-technology/2022/09/new-linux-malware-combines-unusual-stealth-with-a-full-suite-of-capabilities/
[3]https://www.reddit.com/r/technews/comments/xc6nrn/new_linux_malware_combines_unusual_stealth_with_a/

来源:萧箫 发自 凹非寺

收起阅读 »

Android实现定时任务的几种方案汇总

前言 相比Android倒计时的常用场景,定时任务相对来说使用的场景相对没那么多,除非一些特殊的设备或者一些特殊的场景我们会用到。 关于定时任务其实是分为2中作用范围,App内部范围和App外部范围,也就是说你是否需要App杀死了还能执行定时任务,需求不同实现...
继续阅读 »

前言


相比Android倒计时的常用场景,定时任务相对来说使用的场景相对没那么多,除非一些特殊的设备或者一些特殊的场景我们会用到。


关于定时任务其实是分为2中作用范围,App内部范围和App外部范围,也就是说你是否需要App杀死了还能执行定时任务,需求不同实现的方式也不同,我们来看看都如何实现。


一、App内部范围


其实App内部范围的定时任务,我们可以使用倒计时的方案,Handler天然就支持。其实我们并不是需要每一次都使用一些系统服务让App外部范围生效。


比如场景如下,机器放在公司前台常亮并且一直运行在前台的,我需要没间隔60秒去查询当前设备是否在线,顺便更新一下当前的时间,显示早上好,中午好,下午好。


这样的场景我不需要使用一些系统服务,使用App内部范围的一些定时任务即可,因为就算App崩溃了,就算有系统级别的定时任务,我App不在了也没有用了,所以使用内部范围的定时任务即可,杀鸡焉用牛刀。


之前的倒计时方案改造一番几乎都能实现这样的定时任务,例如:


    private var mThread: Thread = Thread(this)
private var mflag = false
private var mThreadNum = 60

override fun run() {
while (mflag && mThreadNum >= 0) {
try {
Thread.sleep(1000 * 60)
} catch (e: InterruptedException) {
e.printStackTrace()
}

val message = Message.obtain()
message.what = 1
message.arg1 = mThreadNum
handler.sendMessage(message)

mThreadNum--
}
}

private val handler = Handler(Looper.getMainLooper()) { msg ->

if (msg.what == 1) {
val num = msg.arg1
//由于需要主线程显示UI,这里使用Handler通信
YYLogUtils.w("当时计数:" + num)
}

true
}

//定时任务
fun backgroundTask() {

if (!mThread.isAlive) {

mflag = true

if (mThread.state == Thread.State.TERMINATED) {
mThread = Thread(this@DemoCountDwonActivity)
if (mThreadNum == -1) mThreadNum = 60
mThread.start()
} else {
mThread.start()
}
} else {

mflag = false

}

}


这样每60秒就能执行一次任务,并且不受到系统的限制,简单明了。(只能在App范围内使用)


倒计时的一些的一些方案我们都能改造为定时任务的逻辑,比如上面的Handler,还有Timer的方式,Thread的方式等。


除了倒计时的一些方案,我们额外的还能使用Java的线程池Api也能快速的实现定时任务,周期性的执行逻辑,例如:



val executorService: ScheduledExecutorService = Executors.newScheduledThreadPool(3)
val command = Runnable {
//dosth
}
executorService.scheduleAtFixedRate(command, 0, 3, TimeUnit.SECONDS)

// executorService.shutdown() //如果想取消可以随时停止线程池

定时执行任务在平常的开发中相对不是那么多,比如特殊场景下,我们需要轮询请求。


比如我做过一款应用放在公司前台,我就需要轮询请求每180秒调用服务器接口,告诉服务器当前设备是否在线。便于后台统计,这个是当前App内部生命周期执行的,用在这里刚刚好。


又比如我们使用DownloadManager来下载文件,因为不能直接回调进度,需要我们手动的调用Query去查询当前下载的消息,和文件的总大小,计算当前的下载进度,我们就可以使用轮询的方案,每一秒钟调用一次Query获取进度,模拟了下载进度的展示。


二、App外部范围


有内部范围的定时任务了,那么哪一种情况下我们需要使用外部范围的定时任务呢?又如何使用外部范围的定时任务呢?


还是上面的场景,机器放在公司前台常亮并且一直运行在前台的,这个App我们需要自动更新,并且检查是否崩溃了或者在前台,不管App是否存在我们都需要自行的定时任务,超过App的生命周期了,我们需要使用系统服务的定时任务来做这些事情。


都有哪些系统服务可以完成这样的功能呢?


2.1 系统服务的简单对比与原理

AlarmManager JobSchedule WorkManager !三者又有哪些不同呢?


AlarmManager 和 JobSchedule 虽然都是系统服务,但是方向又不同,AlarmManager 是通过 AlarmManagerService 控制RTC芯片。


说起Alar就需要说到RTC,说到RTC就需要讲到WakeLock机制。


都是一些比较底层的原理,我不会具体展开,大家有兴趣可以自行搜索,或者参考


Android对RTC时间的操作流程


话说回来,AlarmManage有一个 AlarmManagerService ,该服务程序主要维护 app 注册下来的各类Alarm, 并且一直监听 Alarm 设备, 一旦有 Alarm 触发,或者是 Alarm 事件发生,AlarmManagerService 就会遍历 Alarm 列表,找到相应的注册 Alarm 并发出广播. 首先, Alarm 是基于 RTC 实时时钟计时, 而不是CPU计时; 其次, Alarm 会维持一个 CPU 的 wake lock, 确保 Alarm 广播能被处理。


JobSchedule则是完全Android系统级别的定时任务,如有感兴趣的可以参考文章


Android之JobScheduler运行机制源码分析


他们之间的区别是,AlarmManager 最终是操作硬件,设备开机通电和关机就会丢失Alarm任务,而 JobSchedule 是系统级别的任务,就算重启设备也会继续执行。并且相较来说 AlarmManager 可以做到精准度可以比 JobSchedule 更加好点。


而 WorkManager 则是对JobSchedule的封装与兼容处理,6.0以上版本内部实现JobSchedule,一下的版本提供 AlarmManager 。提供的统一的Api实现相同的功能。


所以在2022年的今天,系统级别的定时任务就只推荐用 AlarmManager(短时间) 或者 WorkManager(长时间)了。


2.2 AlarmManager实现定时任务

由于不是基础教程,如果要这里要讲一下基本使用,我估计这一篇文章都讲不完,如果想看AlarmManager的使用教程,可以看这里


Android中的AlarmManager的使用


由于各版本的不同使用的方式不同
API > 19的时候不能设置为循环 需要设置为单次的发送 然后在广播中再次设置单次的发送。


当API >23 当前手机版本为6.0的时候有待机模式的省点优化 需要重新设置。


当设备为Android 12,如果使用到了AlarmManager来设置定时任务,并且设置的是精准的闹钟(使用了setAlarmClock()、setExact()、setExactAndAllowWhileIdle()这几种方法),则需要确保SCHEDULE_EXACT_ALARM权限声明且打开,否则App将崩溃。


需要在AndroidManifest.xml清单文件中声明 SCHEDULE_EXACT_ALARM 权限


最终我们兼容所有的做法是,只开启一个定时任务,然后触发到广播,然后再广播中再次启动一个定时任务,依次循环,嗯,很有Handler的味道。


例如我们设置一个 AlarmManager ,每180秒检查一下 App 是否存活,如果 App 不在了就拉起 App 跳转MainActivity。(需求是当App杀死了也能启动首页,所以不适用于App内的定时执行方案)


    //定时任务
fun backgroundTask() {

//开启3分钟的闹钟广播服务,检测是否运行了首页,如果退出了应用,那么重启应用
val alarmManager = applicationContext.getSystemService(ALARM_SERVICE) as AlarmManager

val intent1 = Intent(CommUtils.getContext(), AlarmReceiver::class.java)
val pendingIntent = PendingIntent.getBroadcast(CommUtils.getContext(), 0, intent1, PendingIntent.FLAG_UPDATE_CURRENT)

//先取消一次
alarmManager.cancel(pendingIntent)

//再次启动,这里不延时,直接发送
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
alarmManager.setExactAndAllowWhileIdle(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime(), pendingIntent)
} else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
alarmManager.setExact(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime(), pendingIntent)
} else {
alarmManager.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime(), 18000, pendingIntent)
}

YYLogUtils.w("点击按钮-开启 alarmManager 定时任务啦")

}

点击按钮就发送一个立即生效的闹钟,逻辑走到广播中,然后再广播中再次开启闹钟。


class AlarmReceiver : BroadcastReceiver() {

override fun onReceive(context: Context, intent: Intent?) {

val alarmManager = context.getSystemService(ALARM_SERVICE) as AlarmManager

//执行的任务
val intent1 = Intent(CommUtils.getContext(), AlarmReceiver::class.java)
val pendingIntent: PendingIntent = PendingIntent.getBroadcast(context, 0, intent1, PendingIntent.FLAG_UPDATE_CURRENT)

// 重复定时任务,延时180秒发送
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
alarmManager.setExactAndAllowWhileIdle(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + 180000, pendingIntent)
} else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
alarmManager.setExact(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + 180000, pendingIntent)
} else {
alarmManager.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime(), 180000, pendingIntent);
}

YYLogUtils.w("AlarmReceiver接受广播事件 ====> 开启循环动作")

//检测Activity栈里面是否有MainActivity
if (ActivityManage.getActivityStack() == null || ActivityManage.getActivityStack().size == 0) {
//重启首页
// context.gotoActivity<DemoMainActivity>()
} else {
YYLogUtils.w("不需要重启,已经有栈在运行了 Size:" + ActivityManage.getActivityStack().size)
}
}

}

打印日志,由于间隔时间太长,我手机放者,直接把Log保持到Log文件,导出出来,截图如下:



最后是杀死App之后收到的广播。


杀死App手机放了一会,我去个洗手间回来,看看打印日志情况。



2.3 WorkManager实现定时任务

同样的如果不清楚WorkManager的基础使用,推荐大家看看教程


Android架构组件WorkManager详解


WorkManager的使用相对来说也比较简单, WorkManager组件库里面提供了一个专门做周期性任务的类PeriodicWorkRequest。但是PeriodicWorkRequest类有一个限制条件最小的周期时间是15分钟。


WorkManager 比较适合一些比较长时间的任务。还能设置一些约束条件,比如我们每24小时,在设备充电的时候我们就上传这一整天的Log文件到服务器,比如我们每隔12小时就检查应用是否需要更新,如果需要更新则自动下载安装(需要指定Root设备)。


场景如下,还是那个放在公司前台常亮并且一直运行在前台的平板,我们每12小时就检查自动更新,并自动安装,由于之前写了 AlarmManager 所以安装成功之后App会自动打开。


伪代码如下:


        Data inputData2 = new Data.Builder().putString("version", "1.0.0").build();
PeriodicWorkRequest checkVersionRequest =
new PeriodicWorkRequest.Builder(CheckVersionWork.class, 12, TimeUnit.HOURS)
.setInputData(inputData2).build();

WorkManager.getInstance().enqueue(checkVersionRequest);
WorkManager.getInstance().getWorkInfoByIdLiveData(checkVersionRequest.getId()).observe(this, workInfo -> {
assert workInfo != null;
WorkInfo.State state = workInfo.getState();

Data data = workInfo.getOutputData();
String url = data.getString("download_url", "");
//去下载并静默安装Apk
downLoadingApkInstall(url)
});

/**
* 间隔12个小时的定时任务,检测版本的更新
*/
public class CheckVersionWork extends Worker {

public CheckVersionWork(@NonNull Context context, @NonNull WorkerParameters workerParams) {
super(context, workerParams);
}

@Override
public void onStopped() {
super.onStopped();
}

@NonNull
@Override
public Result doWork() {
Data inputData = getInputData();
String version = inputData.getString("version");

//接口获取当前最新的信息

//对比当前版本与服务器版本,是否需要更新

//如果需要更新,返回更新下载的url

Data outputData = new Data.Builder().putString("key_name", inputData.getString("download_url", "xxxxxx")).build();
//设置输出数据
setOutputData(outputData);

return Result.success();
}
}

这个时间太长了不好测试,不过是我之前自用的代码,没什么问题,哪天有时间做个Demo把日志文件导出来看看才能看出效果。


那除此之外我们一些Log的上传,图片的更新,资源或插件的下载等,我们都可以通过WorkManager来实现一些后台的操作,使用起来也是很简单。


总结


这里我直接给出了一些特定的场景应该使用哪一种定时任务,如果大家的应用场景适合App内部的定时任务,应该优先选择内部的定时任务。


App外的定时任务,都是系统服务的定时任务,不一定保险,毕竟是和厂商(特别是国内的厂商)作对,厂商会想方设法杀死我们的定时任务,毕竟有风险。


关于系统服务的定时任务我感觉自己讲的不是很好,好在给出了一些方案和一些文章,大家如果对一些基础的使用或者底层原理感兴趣,可以自行了解一下。


关于系统服务的周期任务的使用如果有错误,或者版本兼容的问题,又或者有更多或更好的方法,也可以在评论区交流讨论。


如果感觉本文对你有一点点点的启发,还望你能点赞支持一下,你的支持是我最大的动力。


Ok,这一期就此完结。



作者:newki
链接:https://juejin.cn/post/7130793502933254180
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

给你的 Android App 添加自定义表情

原理 添加自定义表情的原理其实很简单,就是使用 ImageSpan 对文字进行替换。代码如下: ImageSpan imageSpan = new ImageSpan(this, R.drawable.emoji_kelian); SpannableStrin...
继续阅读 »

原理


添加自定义表情的原理其实很简单,就是使用 ImageSpan 对文字进行替换。代码如下:


ImageSpan imageSpan = new ImageSpan(this, R.drawable.emoji_kelian);
SpannableStringBuilder spannableStringBuilder = new SpannableStringBuilder("哈哈哈哈[可怜]");
spannableStringBuilder.setSpan(imageSpan, 4, spannableStringBuilder.length(), Spannable.SPAN_EXCLUSIVE_EXCLUSIVE);
textView.setText(spannableStringBuilder);

上面的代码把 [可怜] 文字替换成了对应的表情图片。效果如下图,可以看到图片的大小不符合预期,这是因为 ImageSpan 会显示成图片原来的大小。


image.png


ImageSpan 的继承关系图如下,出现了 ReplacementSpanDynamicDrawableSpan 两个新的类,先来看一下它们。MetricAffectingSpanCharacterStyle 接口在 Android Span 原理解析 介绍了,这里就不赘述了。


image.png


ReplacementSpan 接口


ReplacementSpan 是一个接口,看名字是用来替换文字的。它里面定义了两个方法,如下所示。



public abstract int getSize(@NonNull Paint paint,
CharSequence text,
@IntRange(from = 0) int start,
@IntRange(from = 0) int end,
@Nullable Paint.FontMetricsInt fm);

返回替换后 Span 的宽,上面的例子中就是返回图片的宽度,参数作用如下:



  • paint: Paint 的实例

  • text: 当前文本,上面的例子中它的值是是 哈哈哈哈[可怜]

  • start: Span 的开始位置,这里是 4

  • end: Span 的结束位置,这里是 8

  • fm: FontMetricsInt 的实例


FontMetricsInt 是描述给定文本大小的字体的各种度量的类。内部属性代表的含义如下图:



  • Top:图中紫线的位置

  • Ascent: 图中绿线的位置

  • Descent: 图中蓝线的位置

  • Bottom: 图中黄线的位置

  • Leading: 未在图中标出,是指上一行的 Bottom 与下一行的 Top 之间的距离。


图片来源 Meaning of top, ascent, baseline, descent, bottom, and leading in Android's FontMetrics


image.png


Baseline 是文字绘制的基准线。它不定义在 FontMetricsInt 中,但可以通过 FontMetricsInt 的属性获取。


上面讲到 getSize 方法只返回宽度,那高度是怎么确定的呢?其实它是通过 FontMetricsInt 来控制,不过这里有个坑,后面会说到。



public abstract void draw(@NonNull Canvas canvas,
CharSequence text,
@IntRange(from = 0) int start,
@IntRange(from = 0) int end,
float x,
int top,
int y,
int bottom,
@NonNull Paint paint);

在 Canvas 中绘制 Span。参数如下:



  • canvas:Canvas 实例

  • text:当前文本

  • start:Span 的开始位置

  • end:Span 的结束位置

  • x:[可怜] 的 x 坐标位置

  • top:当前行的 “Top“ 属性值

  • y:当前行的 Baseline

  • bottom: 当前行的 ”Bottom“ 属性值

  • paint:Paint 实例,可能为 null


这里需要特殊注意 TopBottom,跟上面说的有点不同这里先记住,后面会一起介绍。


DynamicDrawableSpan


DynamicDrawableSpan 实现了 ReplacementSpan 接口的方法。同时它是一个抽象类,定义了 getDrawable 抽象方法,由 ImageSpan 实现来获取 Drawable 实例。源码如下:


@Override

public int getSize(@NonNull Paint paint, CharSequence text,
@IntRange(from = 0) int start, @IntRange(from = 0) int end,
@Nullable Paint.FontMetricsInt fm) {

Drawable d = getCachedDrawable();
Rect rect = d.getBounds();

//设置图片的高
if (fm != null) {
fm.ascent = -rect.bottom;
fm.descent = 0;
fm.top = fm.ascent;
fm.bottom = 0;
}
return rect.right;
}

@Override

public void draw(@NonNull Canvas canvas, CharSequence text,
@IntRange(from = 0) int start, @IntRange(from = 0) int end, float x,
int top, int y, int bottom, @NonNull Paint paint) {

Drawable b = getCachedDrawable();
canvas.save();

int transY = bottom - b.getBounds().bottom;
//设置对齐方式,有三种分别是
//ALIGN_BOTTOM 底部对齐,默认
//ALIGN_BASELINE 基线对齐
//ALIGN_CENTER 居中对齐
if (mVerticalAlignment == ALIGN_BASELINE) {
transY -= paint.getFontMetricsInt().descent;
} else if (mVerticalAlignment == ALIGN_CENTER) {
transY = top + (bottom - top) / 2 - b.getBounds().height() / 2;
}

canvas.translate(x, transY);
b.draw(canvas);
canvas.restore();
}

public abstract Drawable getDrawable();

DynamicDrawableSpan 有两个坑需要特别注意。


第一个坑就是在 getSize 中的 Paint.FontMetricsInt 对象和 draw 方法中通过 paint.getFontMetricsInt() 获取的不是一个对象。也就是说,无论我们在 getSizePaint.FontMetricsInt 中设置什么值,都不会影响到 paint.getFontMetricsInt() 获取对象中的值。它影响的是 topbottom 的值,这也是刚才介绍参数时给 Top 和 Bottom 打引号的原因。


第二个坑是 ALIGN_CENTER图片大小超过文字大小时“不起作用”。如下图所示,为了方便显示我加了辅助线,白线是代表参数 top,bottom,但是 bottom 被其它颜色覆盖了。可以看到,图片是居中的,是文字没有居中让我们看上去 ALIGN_CENTER 没有效果一样。


image.png


去掉辅助线后,看上去更明显一些。


image.png


ImageSpan


ImageSpan 就简单多了,它只实现了 getDrawable() 方法来获取 Drawable 实例,代码如下:


@Override
public Drawable getDrawable() {

Drawable drawable = null;
if (mDrawable != null) {

drawable = mDrawable;

} else if (mContentUri != null) {

Bitmap bitmap = null;
try {
InputStream is = mContext.getContentResolver().openInputStream(
mContentUri);
bitmap = BitmapFactory.decodeStream(is);
drawable = new BitmapDrawable(mContext.getResources(), bitmap);
drawable.setBounds(0, 0, drawable.getIntrinsicWidth(),
drawable.getIntrinsicHeight());
is.close();
} catch (Exception e) {
Log.e("ImageSpan", "Failed to loaded content " + mContentUri, e);
}

} else {
try {
drawable = mContext.getDrawable(mResourceId);
drawable.setBounds(0, 0, drawable.getIntrinsicWidth(),
drawable.getIntrinsicHeight());
} catch (Exception e) {
Log.e("ImageSpan", "Unable to find resource: " + mResourceId);
}
}
return drawable;
}

这里代码很简单,我们唯一需要关注的就是获取 Drawable 时,需要设置它的宽高,让它别超过文字的大小。


实现


说完前面的原理后,实现起来就非常简单了。我们只需要继承 DynamicDrawableSpan,实现 getDrawable() 方法,让图片的宽高别超过文字的大小就行了。效果如下图所示:



public class EmojiSpan extends DynamicDrawableSpan {

@DrawableRes
private int mResourceId;

private Context mContext;

private Drawable mDrawable;

public EmojiSpan(@NonNull Context context, int resourceId) {
this.mResourceId = resourceId;
this.mContext = context;
}

@Override

public Drawable getDrawable() {

Drawable drawable = null;

if (mDrawable != null) {

drawable = mDrawable;

} else {
try {
drawable = mContext.getDrawable(mResourceId);
drawable.setBounds(0, 0, 48, 48);
} catch (Exception e) {
e.printStackTrace();
}
}
return drawable;
}
}

image.png


上面看上去很完美,但是事情没有那么简单。因为我们只是写死了图片的大小,并没有改变图片位置绘制的算法。如果其他地方使用了 EmojiSpan ,但是文字的大小小于图片大小时还是会出问题。如下图,当文字的 textsize 为 10sp 时的情况。


image.png


实际上,文字大于图片大小时也有问题。如下图所示,多行的情况下,只有表情的行间距明显小于其他行的间距。


image.png


如果大家对这个的解决办法感兴趣的话,点赞+收藏数 >= 40,我就复刻一下B站的自定义表情,加上会动的自定义表情(实际上是 Gif 图)。


作者:新一代螺丝工
链接:https://juejin.cn/post/7144527505394368525
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

如何解决Flutter在Android的适配错乱问题

前言大家好,我是未央歌,一个默默无闻的移动开发搬砖者~先给大家说说项目背景,项目原为 Android 原生开发,所用语言为 Java/Kotlin ;后面引入了 Flutter 混编,如果大家有兴趣,评论区留言,后面再单独开一篇文章为大家讲解一下如何实现 An...
继续阅读 »

前言

大家好,我是未央歌,一个默默无闻的移动开发搬砖者~

先给大家说说项目背景,项目原为 Android 原生开发,所用语言为 Java/Kotlin ;后面引入了 Flutter 混编,如果大家有兴趣,评论区留言,后面再单独开一篇文章为大家讲解一下如何实现 Android 和 Flutter 混编。

Android 适配

说到适配,Android 原生端大家通常采用今日头条适配方案:AndroidAutoSize 。而 AndroidAutoSize的使用也非常简单,按照以下步骤填写全局设计图尺寸 (单位 dp),无需另外操作。

step1

dependencies {
implementation 'com.github.JessYanCoding:AndroidAutoSize:v1.2.1'
}

step2

<manifest>
<application>
<meta-data
android:name="design_width_in_dp"
android:value="375"/>
<meta-data
android:name="design_height_in_dp"
android:value="667"/>
</application>
</manifest>

Flutter 适配

而 Flutter 大家常采用的适配方案则是 flutter_screenutil 。传入设计稿的宽度和高度,进行初始化(只需设置一次)即可。

step1

dependencies:
flutter:
sdk: flutter
# add flutter_screenutil
flutter_screenutil: ^{latest version}

step2

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
@override
Widget build(BuildContext context) {
//填入设计稿中设备的屏幕尺寸,单位dp
return ScreenUtilInit(
designSize: const Size(375, 667),
minTextAdapt: true,
splitScreenMode: true,
builder: (context , child) {
return MaterialApp(
debugShowCheckedModeBanner: false,
title: 'First Method',
// You can use the library anywhere in the app even in theme
theme: ThemeData(
primarySwatch: Colors.blue,
textTheme: Typography.englishLike2018.apply(fontSizeFactor: 1.sp),
),
home: child,
);
},
child: const HomePage(title: 'First Method'),
);
}
}

遇到问题

在做项目需求的时候会遇到如下布局错乱情况,如下图:高空环景、VR、封面图都给距离右边有很大一片空白。每次打开第一次进来都会出现这样的布局错乱问题,第二次进来就恢复正常。

解决问题

当时一度以为是 flutter_screenutil 库在 Android 上的 bug ,后来单独写了一个混编的 demo ,发现不会出现布局错乱情况,于是把矛头对准了原生端的适配 AndroidAutoSize。只要是 Flutter 页面,取消今日头条适配方案(有提供 interface 接口),就不会出现布局错乱问题了。以上问题是两个适配方案相互影响导致!

import me.jessyan.autosize.internal.CancelAdapt

open class BaseFlutterActivity : FlutterActivity(), CancelAdapt {
...
}

实现 CancelAdapt 接口就可解决,如下图:布局错乱问题已解决,恢复正常。

总结

大家遇到疑难杂症问题,先思考可能导致这个问题的原因,然后逐个排查试错。 有时候项目太庞大,可以写一个 demo 来快速验证对错,从而得出原因,对症下药解决。


作者:未央歌
链接:https://juejin.cn/post/7147616629164081188
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »

“雪糕刺客”你听说过,Bitmap这个“内存刺客”你也要小心(上)~

写在前面 雪糕刺客是最近被网友们玩坏了的梗,指的是那些以平平无奇的外表混迹于众多平价雪糕之中的贵价雪糕。由于没有明确标明价格,通常要等到结账的时候才会发现,犹如一个潜藏于普通人群中的刺客般,伺机对那些大意的顾客们的钱包刺上一剑,因此得名。 而在Android中...
继续阅读 »

写在前面


雪糕刺客是最近被网友们玩坏了的梗,指的是那些以平平无奇的外表混迹于众多平价雪糕之中的贵价雪糕。由于没有明确标明价格,通常要等到结账的时候才会发现,犹如一个潜藏于普通人群中的刺客般,伺机对那些大意的顾客们的钱包刺上一剑,因此得名。


而在Android中,也有这么一个内存刺客,其作为我们日常开发中经常接触的对象之一,却常常因为使用方式的不当,时不时地就会给我们有限的内存来上一个背刺,甚至毫不留情地就给我们抛出一个OOM,它,就是Bitmap


为了讲好Bitmap这个话题,本系列文章将分为上下两篇,上篇从图像基础知识出发,结合源码讲解Bitmap内存的计算方式;下篇则基于Android系统提供的API,讲解在实际开发中如何管理好Bitmap的内存,包括缩放、缓存、内存复用等,敬请期待。


本文为上篇,开始之前,先奉上的思维导图一张,方便后续复习:


Bitmap内存计算.png


从一个问题出发


假设有这么一张PNG格式的图片,其大小为15.3KB,尺寸为96x96,色深为32 bit,放到xhdpi目录下,并加载到一台dpi为480的Android设备上显示,那么请问,该图片实际会占用多大的内存?


实际会占用多大的内存.png


如果你回答不了这个问题,那你就有必要深入往下读了。


压缩格式大小≠占用内存大小


首先我们要明确的是,无论是JPEG还是PNG,它们本质上都是一种压缩格式,压缩的目的是为了降低存储和传输的成本


区别就在于:


JPEG是一种有损压缩格式,压缩比大,压缩后的体积比较小,但其高压缩率是通过去除冗余的图像数据进行的,因此解压后无法还原出完整的原始图像数据。


PNG则是一种无损压缩格式,不会损失图片质量,解压后能还原出完整的原始图像数据,但也因此压缩比小,压缩后的体积仍然很大。


开篇问题中所特意强调的图片大小,实际指的就是压缩格式文件的大小。而问题最后所问的图片实际占用的内存,指的则是解压缩后显示在设备屏幕上的原始图像数据所占用的内存


在实际的Android开发中,我们经常直接接触到的原始图像数据,就是通过各种decode方法解码出的Bitmap对象


Bitmap即位图,它还有另外一个名称叫做点阵图,相对来说,点阵图这个名称更能表述Bitmap的特征。


指的是像素点指的是阵列。点阵图,就是以像素为最小单位构成的图,缩放会失真。每个像素实则都是一个非常小的正方形,并被分配不同的颜色,然后通过不同的排列来构成像素阵列,最终呈现出完整的图像


放大12倍显示独立像素


那么每个像素是如何存储自己的颜色信息的呢?这涉及到图片的色深。


色深是什么?


色深,又叫色彩深度(Color Depth)。假设色深的数值为n,代表每个像素会采用n个二进制位来存储颜色信息**,也即2的n次方,表示的是每个像素能显示2^n种颜色


常见的色深有:




  • 1 bit:只能显示黑与白两个中的一个。因为在色深为1的情况下,每个像素只能存储2^1=2种颜色。




  • 8 bit:可以存储2^8=256种的颜色,典型的如GIF图像的色深就为8 bit。




  • 24 bit:可以存储2^24=16,777,216种的颜色。每个像素的颜色由红(Red)、绿(Green)、蓝(Blue)3个颜色通道合成,每个颜色通道用8bit来表示,其取值范围是:



    • 二进制:00000000~11111111

    • 十进制:0~255

    • 十六进制:00~FF


    这里很自然地就让人联想起Android中常用于表示颜色两种形式,即:



    • Color.rgb(float red, float green, float blue),对应十进制

    • Color.parceColor(String colorString),对应十六进制




  • 32 bit:在24位的基础上,增加多8个位的透明通道。




色深会影响图片的整体质量,我们可以来看同一张图片在不同色深下的表现:


24-bit color: 224 = 16,777,216 colors, 45 KB


8-bit color: 28 = 256 colors, 17 KB


4-bit color: 24 = 16 colors, 6 KB


2-bit color: 22 = 4 colors, 4 KB


1-bit color: 21 = 2 colors, 3 KB


可以看出,色深越大,能表示的颜色越丰富,图片也就越鲜艳,颜色过渡就越平滑。但相对的,图片的体积也会增加,因为每个像素必须存储更多的颜色信息


Android中与色深配置相关的类是Bitmap.Config,其取值会直接影响位图的质量(色彩深度)以及显示透明/半透明颜色的能力。在Android 2.3(API 级别 9)及更高版本中的默认配置是ARGB_8888,也即32 bit的色深,1 byte = 8 bit,因此该配置下每个像素的大小为4 byte。


位图内存 = 像素数量(分辨率) * 每个像素的大小,想要进一步计算加载位图所需要的内存,我们还需要得知像素的总数量,而描述像素数量的说法就是分辨率。


分辨率是什么?


如果说,色深决定了位图颜色的丰富程度,那么分辨率决定的则是位图图像细节的精细程度图像的分辨率越高,所包含的像素就越多,图像也就越清晰,同样的,它也会相应增加图片的体积


通常,我们用每一个方向上的像素数量来表示分辨率,也即水平像素数×垂直像素数,比如320×240,640×480,1280×1024等。


一张分辨率为640x480的图片,其像素数量就达到了307200,也就是我们常说的30万像素。


现在,我们明白了公式中2个变量的含义,就可以代入开篇问题中的例子来计算位图内存:


96 * 96 * 4 byte = 36864 bytes = 36KB


Bitmap提供了两个方法用于获取系统为该Bitmap存储像素所分配的内存大小,分别为:


public int getByteCount ()

public int getAllocationByteCount ()

一般情况下,两个方法返回的值是相同的。但如果我们手动重新配置了Bitmap的属性(宽、高、Bitmap.Config等),或者将BitmapFactory.Options.inBitmap属性设为true以支持其他更小的Bitmap复用其内存时,那么getAllocationByteCount ()返回的值就有可能会大于getByteCount()。


我们暂时不考虑以上两种场景,所以直接选择调用getByteCount方法 ()来获取为Bitmap分配的字节数,得到的结果是:82944 bytes = 81KB。


可以看到,getByteCount方法返回的值与我们的计算结果有差异,是我们的计算公式有问题吗?


探究getByteCount()的计算公式


为了验证我们的计算公式是否准确,我们需要深入getByteCount()方法的源码进行探究。


public final int getByteCount() {
if (mRecycled) {
Log.w(TAG, "Called getByteCount() on a recycle()'d bitmap! "
+ "This is undefined behavior!");
return 0;
}
// int result permits bitmaps up to 46,340 x 46,340
return getRowBytes() * getHeight();
}

可以看到,getByteCount()方法的返回值是每一行的字节数 * 高度,那么每一行的字节数又是怎么计算的呢?


public final int getRowBytes() {
if (mRecycled) {
Log.w(TAG, "Called getRowBytes() on a recycle()'d bitmap! This is undefined behavior!");
}
return nativeRowBytes(mFinalizer.mNativeBitmap);
}

正如你所见,getRowBytes()方法的实现是在Native层。先别灰心,接下来坐好扶稳了,我们省去一些不重要的步骤,乘坐飞船一路跨越Bitmap.cpp、SkBitmap.h,途径SkBitmap.cpp时稍微停下:


size_t SkBitmap::ComputeRowBytes(Config c, int width) {
return SkColorTypeMinRowBytes(SkBitmapConfigToColorType(c), width);
}

并最终到达SkImageInfo.h:


static int SkColorTypeBytesPerPixel(SkColorType ct) {
static const uint8_t gSize[] = {
0, // Unknown
1, // Alpha_8
2, // RGB_565
2, // ARGB_4444
4, // RGBA_8888
4, // BGRA_8888
1, // kIndex_8
};
SK_COMPILE_ASSERT(SK_ARRAY_COUNT(gSize) == (size_t)(kLastEnum_SkColorType + 1),
size_mismatch_with_SkColorType_enum);

SkASSERT((size_t)ct < SK_ARRAY_COUNT(gSize));
return gSize[ct];
}

static inline size_t SkColorTypeMinRowBytes(SkColorType ct, int width) {
return width * SkColorTypeBytesPerPixel(ct);
}

都说正确清晰的函数名有替代注释的作用,这就是优秀的典范。


让我们把目光停留在width * SkColorTypeBytesPerPixel(ct)这一行,不难看出,其计算方式是先根据颜色类型获取每个像素对应的字节数,再去乘以其宽度


那么,结合Bitmap.java的getByteCount()方法的实现,我们最终得出,系统为Bitmap存储像素所分配的内存大小 = 宽度 * 每个像素的大小 * 高度,与我们上面的计算公式一致。


公式没错,那问题究竟出在哪里呢?


其实,如果我们的图片是从磁盘、网络等地方获取的,理论上确实是按照上面的公式那样计算没错。但你还记得吗?我们在开篇的问题中,还特意强调了图片是放在xhdpi目录下的。在Android设备上,这种情况下计算位图内存,还有一个维度要考虑进来,那就是像素密度


像素密度是什么?


像素密度指的是屏幕单位面积内的像素数,称为dpi(dots per inch,每英寸点数)。当两个设备的尺寸相同而像素密度不同时,图像的效果呈现如下:


在尺寸相同但像素密度不同的两个设备上放大图像


是不是感觉跟分辨率的概念有点像?区别就在于,前者是屏幕单位面积内的像素数,后者是屏幕上的总像素数


由于Android是开源的,任何硬件制造商都可以制造搭载Android系统的设备,因此从手表、手机到平板电脑再到电视,各种屏幕尺寸和屏幕像素密度的设备层出不穷。


Android碎片化


为了优化不同屏幕配置下的用户体验,确保图像能在所有屏幕上显示最佳效果,Android建议应针对常见的不同的屏幕尺寸和屏幕像素密度,提供对应的图片资源。于是就有了Android工程res目录下,加上各种配置限定符的drawable/mipmap文件夹。


为了简化不同的配置,Android针对不同像素密度范围进行了归纳分组,如下:


适用于不同像素密度的配置限定符.png


我们通常选取中密度 (mdpi) 作为基准密度(1倍图),并保持ldpi~xxxhdpi这六种主要密度之间 3:4:6:8:12:16 的缩放比,来放置相应尺寸的图片资源。


例如,在创建Android工程时IDE默认为我们添加的ic_launcher图标,就遵循了这个规则。该图标在中密度 (mdpi)目录下的大小为48x48,在其他各种密度的目录下的大小则分别为:



  • 36x36 (0.75x) - 低密度 (ldpi)

  • 48x48(1.0x 基准)- 中密度 (mdpi)

  • 72x72 (1.5x) - 高密度 (hdpi)

  • 96x96 (2.0x) - 超高密度 (xhdpi)

  • 144x144 (3.0x) - 超超高密度 (xxhdpi)

  • 192x192 (4.0x) - 超超超高密度 (xxxhdpi)


当我们引用该图标时,系统就会根据所运行设备屏幕的dpi,与不同密度目录名称中的限定符进行比较,来选取最符合当前设备的图片资源。如果在该密度目录下没有找到合适的图片资源,系统会有对应的规则查找另外一个可能的匹配资源,并对其进行相应的缩放,以适配屏幕,由此可能造成图片有明显的模糊失真


不同密度大小的ic_launcher图标


那么,具体的查找规则是怎样的呢?


Android查找最佳匹配资源的规则


一般来说,Android会更倾向于缩小较大的原始图像,而非放大较小的原始图像。在此前提下:



  • 假设最接近设备屏幕密度的目录选项为xhdpi,如果图片资源存在,则匹配成功;

  • 如果不存在,系统就会从更高密度的资源目录下查找,依次为xxhdpi、xxxhdpi;

  • 如果还不存在,系统就会从像素密度无关的资源目录nodpi下查找;

  • 如果还不存在,系统就会向更低密度的资源目录下查找,依次为hdpi、mdpi、ldpi。


那么,当匹配到其他密度目录下的图片资源后,对于原始图像的放大或缩小,Android是怎么实现的呢?又会对加载位图所需要的内存有什么影响呢?


想解决这些疑惑,我们还是得从源码中找寻答案。


decode*方法的猫腻


众所周知,在Android中要读取drawable/mipmap目录下的图片资源,需要用到的是BitmapFactory类下的decodeResource方法:


    public static Bitmap decodeResource(Resources res, int id, Options opts) {
...
final TypedValue value = new TypedValue();
is = res.openRawResource(id, value);

bm = decodeResourceStream(res, value, is, null, opts);
...
}

decodeResource方法的主要工作,就只是调用Resource#openRawResource方法读取原始图片资源,同时传递一个TypedValue对象用于持有图片资源的相关信息,并返回一个输入流作为内部继续调用decodeResourceStream方法的参数。


    public static Bitmap decodeResourceStream(Resources res, TypedValue value,InputStream is, Rect pad, Options opts) {
if (opts == null) {
opts = new Options();
}

if (opts.inDensity == 0 && value != null) {
final int density = value.density;
if (density == TypedValue.DENSITY_DEFAULT) {
opts.inDensity = DisplayMetrics.DENSITY_DEFAULT;
} else if (density != TypedValue.DENSITY_NONE) {
opts.inDensity = density;
}
}

if (opts.inTargetDensity == 0 && res != null) {
opts.inTargetDensity = res.getDisplayMetrics().densityDpi;
}

return decodeStream(is, pad, opts);
}

decodeResourceStream方法的主要工作,则是负责Options(解码选项)类2个重要参数inDensity和inTargetDensity的初始化,其中:



  • inDensity代表的是Bitmap的像素密度,取决于原始图片资源所存放的密度目录。

  • inTargetDensity代表的是Bitmap将绘制到的目标的像素密度,通常就是指屏幕的像素密度。


这两个参数起什么作用呢,让我们继续往下看:


public static Bitmap decodeStream(InputStream is, Rect outPadding, Options opts) {
···
if (is instanceof AssetManager.AssetInputStream) {
final long asset = ((AssetManager.AssetInputStream) is).getNativeAsset();
bm = nativeDecodeAsset(asset, outPadding, opts);
} else {
bm = decodeStreamInternal(is, outPadding, opts);
}
···
}

private static Bitmap decodeStreamInternal(InputStream is, Rect outPadding, Options opts) {
byte [] tempStorage = null;
if (tempStorage == null) tempStorage = new byte[DECODE_BUFFER_SIZE];
return nativeDecodeStream(is, tempStorage, outPadding, opts);
}

又见到熟悉的Native层方法了,让我们重新开动星际飞船再次跨越到BitmapFactory.cpp下查看:


static jobject nativeDecodeStream(JNIEnv* env, jobject clazz, jobject is, jbyteArray storage, jobject padding, jobject options) {
···
bitmap = doDecode(env, bufferedStream, padding, options);
···
}

static jobject doDecode(JNIEnv* env, SkStreamRewindable* stream, jobject padding, jobject options) {
····
float scale = 1.0f;
···
if (env->GetBooleanField(options, gOptions_scaledFieldID)) {
const int density = env->GetIntField(options, gOptions_densityFieldID);
const int targetDensity = env->GetIntField(options, gOptions_targetDensityFieldID);
const int screenDensity = env->GetIntField(options, gOptions_screenDensityFieldID);
if (density != 0 && targetDensity != 0 && density != screenDensity) {
scale = (float) targetDensity / density;
}
}
···
const bool willScale = scale != 1.0f;
···
int scaledWidth = decodingBitmap.width();
int scaledHeight = decodingBitmap.height();

if (willScale && decodeMode != SkImageDecoder::kDecodeBounds_Mode) {
scaledWidth = int(scaledWidth * scale + 0.5f);
scaledHeight = int(scaledHeight * scale + 0.5f);
}

if (options != NULL) {
env->SetIntField(options, gOptions_widthFieldID, scaledWidth);
env->SetIntField(options, gOptions_heightFieldID, scaledHeight);
env->SetObjectField(options, gOptions_mimeFieldID,
getMimeTypeString(env, decoder->getFormat()));
}
...
}

以上节选的doDecode方法的部分源码,就是Android系统如何对其他密度目录下的原始图像进行缩放的具体实现,我们来梳理一下它的执行逻辑:



  1. 首先,设置scale值也即初始的缩放比为1。

  2. 取出关键的density值以及targetDensity值,以目标像素密度/位图像素密度重新计算缩放比。

  3. 如果缩放比不再为1,则说明原始图像需要进行缩放。

  4. 取出待解码的位图的宽度,按int(scaledWidth * scale + 0.5f)计算缩放后的宽度,高度同理。

  5. 重新填充缩放后的宽高回Options。


基于以上内容,我们重新调整下我们的计算公式:


位图内存 = (位图宽度 * 缩放比) * 每个像素的大小 * (位图高度 * 缩放比)
= (96 * 1.5) * 4 * (96 * 1.5)
= 82944 bytes = 81KB


可以看到,这样计算得出来的结果则与Bitmap#getByteCount()返回的值一致。


总结


汇总上述的所有内容后,我们可以得出结论,即:


Android系统为Bitmap存储像素所分配的内存大小,取决于以下几个因素:



  • 色深,也即每个像素的大小,对应的是Bitmap.Config的配置。

  • 分辨率,也即像素的总数量,对应的是Bitmap的高度和宽度

  • 像素密度,对应的是图片资源所在的密度目录,以及设备的屏幕像素密度


由此我们还衍生出其他的结论,即:



  • 图片资源放到正确的密度目录很重要,否则可能对会较大尺寸的图片进行不合理的缩放,从而加大不必要的内存占用。

  • 如果是为了减少包体积而不想提供所有密度目录下不同尺寸的图片,应优先提供更高密度目录下的图片资源,可以避免图片失真。

  • ...

作者:椎锋陷陈
链接:https://juejin.cn/post/7123872753463066637
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

带着需求看源码《如何判断 Activity 上是否有弹窗》

今天来看个需求,如何判断 Activity 上面是否有弹窗,当然,简单的方式肯定有,例如在 Dialog show 的时候记录一下,但这种方式不够优雅,我们需要一款更通用的判断方式。 Android 目前的弹窗有如下几种: 普通的应用窗口,如 Dialog...
继续阅读 »

今天来看个需求,如何判断 Activity 上面是否有弹窗,当然,简单的方式肯定有,例如在 Dialog show 的时候记录一下,但这种方式不够优雅,我们需要一款更通用的判断方式。


Android 目前的弹窗有如下几种:



  1. 普通的应用窗口,如 Dialog

  2. 附加与普通窗口的子窗口,如 PopWindow

  3. 系统窗口,如 WindowManager type 在 FIRST_SYSTEM_WINDOW 与 LAST_SYSTEM_WINDOW 之间


通过图来简单来了解下 Window 和 View 的关系:




  • Activity 在 attach 阶段创建了 PhoneWindow,并将 AppToken 存储到 PhoneWindow 中,然后通过 createLocalWindowManager 创建了一个本地的 WindowManager,该实例是 WindowManagerImpl,构造传入的 parentWindow 为 PhoneWindow。在 onResume 阶段时,从 PhoneWindow 中获取 WindowManager 来 addView

  • Dialog 有自己的 PhoneWindow,但 Dialog 并没有从 PhoneWindow 中去 get WindowManager,而是直接使用 getSystemService 拿到 Activity 的 WindowManager 来 addView

  • PopWindow 内部是通过 getSystemService 来拿到 Activity WindowManager + 内置子窗口 type 来实现的弹框


方案 1、通过 mView 集合中的 Activity 区间来判断


从上面我们可以简单了解到,当前进程所有窗口 View,最终都会被存储到 WindowManagerGlobal 单例的 mViews 集合中,那我们是不是可以从 mView 这个集合入手?我们来简单画个 mView 的存储图:



WindowManager addView 时,都会往 mView 这个集合中进行添加。所以,我们只需要判断在 mView 集合中,两个 activity 之间是否有存在其他的 View,如果有,那就是有弹窗,开发步骤为:



  1. registerActivityLifecycleCallbacks 获取所有 Activity 的实例

  2. 传入想判断是否有弹窗的目标 Activity 实例,并获取该实例的 DecorView

  3. 拿到所有 Activity 实例的 DecorView 集合

  4. 遍历 mView 集合,并判断 mView 中的 View 是否与目标 Activity 的 DecorView 一致,是的话,说明找到了activity 的 index 位置

  5. 接下来从 index +1 的位置开始继续遍历 mView,判断 mView 中的 View 是否是 DecorView 集合中的实例,如果没有,则说明不是 Activity 的 View,继续遍历,直到 View 为 DecorView 集合中的实例为止


部分代码实现如下:


fun hasFloatingWindowByView(activity: Activity): Boolean {
return getFloatWindowView(activity).isNotEmpty()
}

fun getFloatWindowByView(activity: Activity): List<View> {
// 对应步骤 2
val targetDecorView = activity.window.decorView
// 对应步骤 3
val acDecorViews = lifecycle.getActivities().map { it.window.decorView }.toList()
// 对应步骤 4
val mView = Window.getViews().map { it }.toList()
val targetIndex = mView.first { it == targetDecorView }
// 对应步骤 5
val index = mView.indexOf(targetIndex)
val floatView = arrayListOf<View>()
for (i in index + 1 until mView.size) {
if (acDecorViews.contains(mView[i])) {
break
}
floatView.add(mView[i])
}
return floatView
}

具体演示可以参考 Demo,这里说个该方案的缺点,由于 mView 是个 List 集合,每次有新的 View add 进来,都是按 ArrayList.add 来添加 View 的,如果我们在启动第二个 Activity 的时候,触发第一个 Activity 来展示 Dialog,这时候的展示效果如下:



这时候如果拿第一个 Activity 来判断是否有弹窗的话,是存在误判的,因为这时候的两个 Activity 之间没有其他 View。


所以,通过区间来判断还是有缺点的。那有没有一种方法,可以直接遍历 mView 集合就能找到目标 Activity 是否有弹窗呢?还真有,那就是 AppToken。


方案二:通过 AppToken 来判断


在文章开头的概念中,我们了解到,PopWindow、Dialog 使用的都是 Activity 的 WindowManager,并且,该WindowManager 在初次创建时,构造函数传入的 parentWindow 为 PhoneWindow,这个 parentWindow 很重要,因为在 WindowManagerGlobal 的 addView 方法中,他会通过 parentWindow 来拿到 AppToken,然后设置到 WindowManager.LayoutParams 中,并参与最终的界面展示。
我们来看下设置 AppToken 的代码:


image.png


parentWindow 为 PhoneWindow,不为空,所以会进入到 PhoneWindow 父类 Window 的adjustLayoutParamsForSubWindow 方法:


image.png



  1. 子窗口判断:取 DecorView 里面的 WindowToken 设置到 wp 参数中。该 DecorView 为 Activity PhoneWindow 里的 DecorView,所以,该 windowToken 可以通过 Activity 的 DecorView 中拿到

  2. 系统弹窗判断:不设置 token,wp 中的 token 参数为 null

  3. 普通弹窗判断:将 AppToken 直接设置到 wp 参数中。该 AppToken 为 Activity PhoneWindow 里的 AppToken


通过这个三个判断我们了解到,子窗口的 windowToken 与普通弹窗的 AppToken 都可以与 Activity 挂钩了,这下,通过目标 Activity 就可以找到他们。至于系统弹窗,我们只需要 token 为 null 时即可。


wp 最终会被添加到 mParams 集合中,他与 mView 和 mRoot 的索引是一一对应的:


image.png


画个简单的图来概括下:



然后再结合 adjustLayoutParamsForSubWindow 对 token 的设置来描述下开发步骤:



  1. 传入想判断是否有弹窗的目标 Activity 实例,并获取该实例的 DecorView 与 windowToken

  2. 拿到 mView 集合,根据目标 Activity 的 DecorView 找到 index 位置

  3. 由于 mView 与mParams 集合是一一对应的,所以,可以根据该 index 位置去 mParams 集合里面找到目标 Activity 的 AppToken

  4. 遍历 mParams 集合中的所有 token,判断该 token 是否为目标 windowToken,目标 AppToken 或者是 null,只要能命中,则说明有弹窗


部分代码实现如下:


fun hasFloatWindowByToken(activity: Activity): Boolean {
// 获取目标 Activity 的 decorView
val targetDecorView = activity.window.decorView
// 获取目标 Activity 的 windowToken
val targetSubToken = targetDecorView.windowToken

// 拿到 mView 集合,找到目标 Activity 所在的 index 位置
val mView = Window.getViews().map { it }.toList()
val targetIndex = mView.indexOfFirst { it == targetDecorView }

// 获取 mParams 集合
val mParams = Window.getParams()
// 根据目标 index 从 mParams 集合中找到目标 token
val targetToken = mParams[targetIndex].token

// 遍历判断时,目标 Activity 自己不能包括,所以 size 需要大于 1
return mParams
.map { it.token }
.filter { it == targetSubToken || it == null || it == targetToken }
.size > 1
}

演示步骤:



  • 在第一个 Activity 打开系统弹窗,然后进入第二个 Activity,调用两种方式来获取当前是否有弹窗的结果如下


image.png



  • 第一种方案会判断失败,因为这时候的弹窗 View 在第一个 Activity 与 第二个 Activity 之间,所以,第二个 Activity 无法通过区间的方式判断到是否有弹窗

  • 第二种方案判断成功,因为这时候的弹窗 token 为 null,并通过 getFloatWindowViewByToken 方法,拿到了弹窗 View 对象


总结


本期通过提出需求的方式来探索方案的可行性,对于枯燥的源码来说,针对性的去看确实是个不错的主意


附上 demo 源码:github.com/MRwangqi/Fl…


作者:codelang
链接:https://juejin.cn/post/7136537294005075976
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

最近很火的反调试,你知道它是什么吗?

前言我们日常开发中,永远离不开debug调试,断点技术一直是我们排查bug的有力手段之一!随着网络安全意识的逐步提高,对app安全的要求就越来越高,反调试 (有朋友不太了解这个概念,这里我解释一下,就是通过调试技术,比如我们可以反编译某个apk,即使apk是r...
继续阅读 »

前言

我们日常开发中,永远离不开debug调试,断点技术一直是我们排查bug的有力手段之一!随着网络安全意识的逐步提高,对app安全的要求就越来越高,反调试 (有朋友不太了解这个概念,这里我解释一下,就是通过调试技术,比如我们可以反编译某个apk,即使apk是release包,同样也可以进行反编译后调试,比如最新版本的jadx)的技术也渐渐深入我们开发者的眼帘,那么我们来具体看看,android中,同时也是linux内核中,是怎么处理调试程序的!

执行跟踪

无论是断点还是其他debug手段,其实都可以总结为一个技术手段,就是执行跟踪,含义就是一个程序监视另一个程序的技术,被跟踪的程序通过一步步执行,知道收到一个信号或者系统调用停止!

在linux内核中,就是通过ptrace系统调用进行的执行跟踪

#include  
long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data);

随着我们对linux的了解,那么就离不开对权限的讨论!一个程序跟踪另一个程序这种东西,按照linux风格,肯定是具有某种权限才可以执行!这个权限就是设置了CAP_SYS_PTRACE 权限的进程,就可以跟踪系统中除了init进程(linux第一个进程)外的任何进程!当然!就算一个进程没有CAP_SYS_PTRACE权限,也可以跟踪一个与被监视进程有相同属组的进程,比如父进程可以通过ptrace跟踪子进程!执行跟踪还有一个非常重要的特点,就是两个进程不能同时跟踪一个进程

我们再回到ptrace函数调用,可以看到第一个参数是一个枚举值,其实就是发出ptrace的当前行为,它有以下可选命令(仅部分举例):

其他的参数含义如下: pid参数标识目标进程,addr参数表明执行peek(读操作)和poke(写操作)操作的地址,data参数则对于poke操作,指明存放数据的地址,对于peek操作,指明获取数据的地址。

ptrace设计探讨

我们了解了linux提供的系统api,那么我们还是从设计者角度出发,我们想要跟踪一个进程的话,我们需要干点什么?来来来,我们来想一下,可能就会有以下几个问题吧

  1. 被跟踪进程与跟踪进程怎么建立联系

  2. 如果使程序停止在我们想要停止的点(比如断点)

  3. 跟踪进程与被跟踪进程怎么进行数据交换,又或者我们怎么样看到被跟踪进程中当前的数据

下面我们逐步去探讨一下这几个问题吧!(以PTRACE_ATTACH 作为例子)首先对于问题1,我们怎么建立起被跟踪进程与跟踪进程之间的联系呢?linux中进程存在父子关系,兄弟关系对吧!这些进程就可以通过相对便捷的方式进行通信,同时linux也有定义了特殊的信号提供给父子进程的通信。看到这里,相信大家能够猜到ptrace究竟干了啥!就是通过调用ptrace系统调用,把被跟踪进程(第二个参数pid)的进程描述符号中的p_pptr字段指向了跟踪进程!毕竟linux判断进程的描述,就靠着进程描述符,想要建立父子关系,修改进程描述符即可,就这么简单!这里补充一下部分描述符号:


那么好!我们建立进程之间的联系了,那么当执行跟踪终止的时候,我们就可以调用ptrace 第一个参数为PTRACE_DETACH 命令,把p_pptr恢复到原来的数据即可!(那么有人会问,原来的父进程描述符保存在哪里了,嘿嘿,在p_opptr中,也就是他的祖先中,这里我们不深入讨论)

接下来我们来讨论一下问题2和问题3,怎么使程序停止呢?(这里我们讨论常用的做法,以linux内核2.4版本为准,请注意细微的区别)其实就是被监控进程在读取指令前,就会执行被嵌入的监控代码,如果我想要停止在代码的某一行,这个时候cpu会执行一条“陷阱指令”也称为Debug指令(这里可以采用架构相关的指令或者架构无关的指令实现,比如SIGTRAP或者其他规定信号),一般来说,这条指令作用只是为了使程序停止,然后发出一个SIGCHLD信号给父进程(不了解信号的知识可以看看这篇),嘿嘿,那么这个父进程是谁呢?没错,就是我们刚刚改写的监控进程,这样一来,我们的监控进程就能够收到被监控进程的消息,此时就可以继续调用其他的ptrace调用(第一个参数指定为其他需要的枚举值),查看当前寄存器或者其他的数据


这么说下来可能会有人还是不太懂,我们举个例子,我们的单步调试是怎么样做的: 还是上面的步骤,子进程发送一个SIGCHLD给父进程,此时身为父进程的监控线程就可以再调用ptrace(PTRACE_SINGLESTEP, *, *, * )方法给子进程的下一条指令设置陷阱指令,进行单步调试,此时控制权又会给到子进程,子进程执行完一个指令,就会又发出SIGCHLD给父进程,如此循环下去!

反调试

最近隐私合规与app安全性能被各大app所重视,对于app安全性能来说,反调试肯定是最重要的一环!看到上面的这些介绍,我们应该也明白了ptrace的作用,下面我们介绍一下几种常见的反调试方案:

  1. ptrace占位:利用ptrace的机制,我们知道一个进程只能被一个监控进程所监控,所以我们可以提前初始化一个进程,用这个进程对我们自身app的进程调用一次ptrace即可

  2. 轮询进程状态:可以通过轮训的手段,查看进程当前的进程信息:proc/pid/status

Name: test\
Umask: 0022\
State: D (disk sleep)-----------------------表示此时线程处于sleeping,并且是uninterruptible状态的wait。

Tgid: 157-----------------------------------线程组的主pid\
Ngid: 0\
Pid: 159------------------------------------线程自身的pid\
PPid: 1-------------------------------------线程组是由init进程创建的。\
TracerPid: 0\                             **这里是关键**
Uid: 0 0 0 0\
Gid: 0 0 0 0\
FDSize: 256---------------------------------表示到目前为止进程使用过的描述符总数。\
Groups: 0 10 \
VmPeak: 1393220 kB--------------------------虚拟内存峰值大小。\
VmSize: 1390372 kB--------------------------当前使用中的虚拟内存,小于VmPeak。\
VmLck: 0 kB\
VmPin: 0 kB\
VmHWM: 47940 kB-----------------------------RSS峰值。\
VmRSS: 47940 kB-----------------------------RSS实际使用量=RSSAnon+RssFile+RssShmem。\
RssAnon: 38700 kB\
RssFile: 9240 kB\
RssShmem: 0 kB\
VmData: 366648 kB--------------------------进程数据段共366648KB。\
VmStk: 132 kB------------------------------进程栈一共132KB。\
VmExe: 84 kB-------------------------------进程text段大小84KB。\
VmLib: 11488 kB----------------------------进程lib占用11488KB内存。\
VmPTE: 1220 kB\
VmPMD: 0 kB\
VmSwap: 0 kB\
Threads: 40-------------------------------进程中一个40个线程。\
SigQ: 0/3142------------------------------进程信号队列最大3142,当前没有pending

如果TracerPid不为0,那么就存在被监控的进程,此时如果该进程不是我们所信任的进程,就调用我们指定好的程序重启即可!读取这个proc/pid/status文件涉及到的相关处理可以自行google,这里就不再重复列举啦!

总结

看到这里,我们也能够明白debug在linux内核中的处理流程啦!最后,点个赞再走呗!


作者:Pika
来源:juejin.cn/post/7132438417970823176

收起阅读 »

Android 三行代码实现高斯模糊

设计:有了毛玻璃效果,产品的逼格直接拉满了呀我:啊,对对对。我去 GayHub 上找找有没有好的解决方案吧设计:GayHub ???寻找可行的方案要实现高斯模糊的方式有很多,StackBlur、RenderScript、Glide 等等都是不错的方式,但最简单...
继续阅读 »

设计:有了毛玻璃效果,产品的逼格直接拉满了呀

我:啊,对对对。我去 GayHub 上找找有没有好的解决方案吧

设计:GayHub ???

寻找可行的方案

要实现高斯模糊的方式有很多,StackBlur、RenderScript、Glide 等等都是不错的方式,但最简单直接效率最高的方式,还得是上 Github。

搜索的关键词为 android blur,可以看到有两个库是比较合适的, BlurryBlurView。 这两个库 Star 数比较高,并且也还在维护着。

于是,便尝试了一番,发现 BlurView 比 Blurry 更好用,十分推荐上手 BlurView


Blurry

  • 优点:API 使用非常简洁,效果也不错,提供同步和异步加载的解决方案

  • 缺点:奇奇怪怪的 Bug 非常多,并且只能作用于 ImageView

    • 使用时,基本会遇到这两个 Bug:issue1issue2

    • issue1(NullPointerException) 已经有现成的解决方案

    • issue2(Canvas: trying to use a recycled bitmap) 则从 17 年至今毫无进展,并且复现概率还比较高

BlurView(推荐)

  • 优点:使用的过程中几乎没有遇到 bug,实现时调用的代码较少。并且,可以实现复杂的模糊 View

  • 缺点:需要在 xml 中配置,并且需要花几秒钟的时间理解一下 rootView 的概念

  • 使用方式:

    XML:

    <androidx.constraintlayout.widget.ConstraintLayout
    ...
    android:id="@+id/rootView"
    android:background="@color/purple_200" >
     
    <ImageView
      ...
      android:id="@+id/imageView" />
     
    <eightbitlab.com.blurview.BlurView
      ...
      android:id="@+id/blurView" />

    </androidx.constraintlayout.widget.ConstraintLayout>

    MainActivity#onCreate:

    // 这里的 rootView,只要是 blurView 的任意一个父 View 即可
    val rootView = findViewById<ConstraintLayout>(R.id.rootView)
    val blurView = findViewById<BlurView>(R.id.blurView)
    blurView.setupWith(rootView, RenderScriptBlur(this))
  • 实现的效果

    使用前:

    使用后:

  • Tips :

    • 在 BlurView 以下的 View 都会有高斯模糊的效果

    • rootView 可以选择离 BlurView 最近的 ViewGroup

    • .setBlurRadius() 可以用来设置卷积核的大小,默认是 16F

    • .setOverlayColor() 可以用来设置高斯模糊覆盖的颜色值

    • 例如如下参数配置时可以达到这样的效果:

      blurView.setupWith(rootView, RenderScriptBlur(this))
                .setBlurRadius(5F)
                .setOverlayColor(Color.parseColor("#77000000"))

    • 最后,再补充一下滑动时的效果:



作者:很好奇
来源:juejin.cn/post/7144663860027326494

收起阅读 »

Android壁纸还是B站玩得花

设置系统壁纸这个功能,对于应用层App来说,场景其实并不多,但在一些场景的周边活动中,确也是一种提升品牌粘性的方式,就好比某个活动中创建的角色的壁纸美图,这些就可以新增一个设置壁纸的功能。 从原始的Android开始,系统就支持设置两种方式的壁纸,一种是静态壁...
继续阅读 »

设置系统壁纸这个功能,对于应用层App来说,场景其实并不多,但在一些场景的周边活动中,确也是一种提升品牌粘性的方式,就好比某个活动中创建的角色的壁纸美图,这些就可以新增一个设置壁纸的功能。


从原始的Android开始,系统就支持设置两种方式的壁纸,一种是静态壁纸,另一种是动态壁纸。


静态壁纸


静态壁纸没什么好说的,通过系统提供的API一行代码就完事了。


最简单代码如下所示。


val wallpaperManager = WallpaperManager.getInstance(this)
try {
val bitmap = ContextCompat.getDrawable(this, R.drawable.ic_launcher_background)?.toBitmap()
wallpaperManager.setBitmap(bitmap)
} catch (e: Exception) {
e.printStackTrace()
}

除了setBitmap之外,系统还提供了setResource、setStream,一共三种方式来设置静态壁纸。


三种方式殊途同归,都是设置一个Bitmap给系统API。


动态壁纸


动态壁纸就有点意思了,很多手机ROM也内置了一些动态壁纸,别以为这些是什么新功能,从Android 1.5开始,就已经支持这种方式了。只不过做的人比较少,为啥呢,主要是没有什么特别合适的场景,而且动态壁纸,会比静态壁纸更加耗电,所以大部分时候,我们都没用这种方式。


壁纸作为一个系统服务,在系统启动时,不管是动态壁纸还是静态壁纸,都会以一个Service的形式运行在后台——WallpaperService,它的Window类型为TYPE_WALLPAPER,WallpaperService提供了一个SurfaceHolder来暴露给外界来对画面进行渲染,这就是设置壁纸的基本原理。


创建一个动态壁纸,需要继承系统的WallpaperService,并提供一个WallpaperService.Engin来进行渲染,下面这个就是一个模板代码。


class MyWallpaperService : WallpaperService() {
override fun onCreateEngine(): Engine = WallpaperEngine()

inner class WallpaperEngine : WallpaperService.Engine() {
lateinit var mediaPlayer: MediaPlayer

override fun onSurfaceCreated(holder: SurfaceHolder?) {
super.onSurfaceCreated(holder)
}

override fun onCommand(action: String?, x: Int, y: Int, z: Int, extras: Bundle?, resultRequested: Boolean): Bundle {
try {
Log.d("xys", "onCommand: $action----$x---$y---$z")
if ("android.wallpaper.tap" == action) {
}
} catch (e: Exception) {
e.printStackTrace()
}
return super.onCommand(action, x, y, z, extras, resultRequested)
}

override fun onVisibilityChanged(visible: Boolean) {
if (visible) {
} else {
}
}

override fun onDestroy() {
super.onDestroy()
}
}
}

然后在manifest中注册这个Service。


<service
android:name=".MyWallpaperService"
android:exported="true"
android:label="Wallpaper"
android:permission="android.permission.BIND_WALLPAPER">
<intent-filter>
<action android:name="android.service.wallpaper.WallpaperService" />
</intent-filter>

<meta-data
android:name="android.service.wallpaper"
android:resource="@xml/my_wallpaper" />
</service>

另外,还需要申请相应的权限。


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

最后,在xml文件夹中新增一个描述文件,对应上面resource标签的文件。


<?xml version="1.0" encoding="utf-8"?>
<wallpaper xmlns:android="http://schemas.android.com/apk/res/android"
android:description="@string/app_name"
android:thumbnail="@mipmap/ic_launcher" />

动态壁纸只能通过系统的壁纸预览界面来进行设置。


val localIntent = Intent()
localIntent.action = WallpaperManager.ACTION_CHANGE_LIVE_WALLPAPER
localIntent.putExtra(
WallpaperManager.EXTRA_LIVE_WALLPAPER_COMPONENT,
ComponentName(applicationContext.packageName, MyWallpaperService::class.java.name))
startActivity(localIntent)

这样我们就可以设置一个动态壁纸了。


玩点花


既然是使用提供的SurfaceHolder来进行渲染,那么我们所有能够使用到SurfaceHolder的场景,都可以来进行动态壁纸的创建了。


一般来说,有三种比较常见的使用场景。



  • MediaPlayer

  • Camera

  • SurfaceView


这三种也是SurfaceHolder的常用使用场景。


首先来看下MediaPlayer,这是最简单的方式,可以设置一个视频,在桌面上循环播放。


inner class WallpaperEngine : WallpaperService.Engine() {
lateinit var mediaPlayer: MediaPlayer

override fun onSurfaceCreated(holder: SurfaceHolder?) {
super.onSurfaceCreated(holder)
mediaPlayer = MediaPlayer.create(applicationContext, R.raw.testwallpaper).also {
it.setSurface(holder!!.surface)
it.isLooping = true
}
}

override fun onVisibilityChanged(visible: Boolean) {
if (visible) {
mediaPlayer.start()
} else {
mediaPlayer.pause()
}
}

override fun onDestroy() {
super.onDestroy()
if (mediaPlayer.isPlaying) {
mediaPlayer.stop()
}
mediaPlayer.release()
}
}

接下来,再来看下使用Camera来刷新Surface的。


inner class WallpaperEngine : WallpaperService.Engine() {
lateinit var camera: Camera

override fun onVisibilityChanged(visible: Boolean) {
if (visible) {
startPreview()
} else {
stopPreview()
}
}

override fun onDestroy() {
super.onDestroy()
stopPreview()
}

private fun startPreview() {
camera = Camera.open()
camera.setDisplayOrientation(90)
try {
camera.setPreviewDisplay(surfaceHolder)
camera.startPreview()
} catch (e: IOException) {
e.printStackTrace()
}
}

private fun stopPreview() {
try {
camera.stopPreview()
camera.release()
} catch (e: Exception) {
e.printStackTrace()
}
}
}

同时需要添加下Camera的权限。


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

<uses-feature android:name="android.hardware.camera" />
<uses-feature android:name="android.hardware.camera.autofocus" />

由于这里偷懒,没有使用最新的CameraAPI,也没有动态申请权限,所以你需要自己手动去授权。


最后一种,通过Surface来进行自绘渲染。


val holder = surfaceHolder
var canvas: Canvas? = null
try {
canvas = holder.lockCanvas()
if (canvas != null) {
canvas.save()
// Draw Something
}
} finally {
if (canvas != null) holder.unlockCanvasAndPost(canvas)
}

这里就可以完全使用Canvas的API来进行绘制了。


这里有一个比较复杂的绘制Demo,可以给大家参考。


http://www.developer.com/design/buil…


有意思的方法


虽然WallpaperService是一个系统服务,但它也提供了一些比较有用的回调函数来帮助我们做一些有意思的东西。


onOffsetsChanged


当用户在手机桌面滑动时,有的壁纸图片会跟着左右移动,这个功能就是通过这个回调来实现的,在手势滑动的每一帧都会回调这个方法。


xOffset:x轴滑动的百分比


yOffset:y轴滑动百分比


xOffsetStep:x轴桌面Page数进度


yOffsetStep:y轴桌面Page数进度


xPixelOffset:x轴像素偏移量


通过这个函数,就可以拿到手势的移动惯量,从而对图片做出一些修改。


onTouchEvent、onCommand


这两个方法,都可以获取用户的点击行为,通过判断点击类型,就可以针对用户的特殊点击行为来做一些逻辑处理,例如点击某些特定的地方时,唤起App,或者打开某个界面等等。


class MyWallpaperService : WallpaperService() {
override fun onCreateEngine(): Engine = WallpaperEngine()

private inner class WallpaperEngine : WallpaperService.Engine() {

override fun onTouchEvent(event: MotionEvent?) {
// on finder press events
if (event?.action == MotionEvent.ACTION_DOWN) {
// get the canvas from the Engine or leave
val canvas = surfaceHolder?.lockCanvas() ?: return
// TODO
// update the surface
surfaceHolder.unlockCanvasAndPost(canvas)
}
}
}
}

B站怎么玩的呢


不得不说,B站在这方面玩的是真的花,最近B站里面新加了一个异想少女系列,你可以设置一个动态壁纸,同时还带交互,有点意思。



其实类似这样的交互,基本上都是通过OpenGL或者是RenderScript来实现的,通过GLSurfaceView来进行渲染,从而实现了一些复杂的交互,下面这些例子,就是一些实践。


github.com/PavelDoGrea…


github.com/jinkg/live-…


http://www.cnblogs.com/YFEYI/categ…


code.tutsplus.com/tutorials/c…


但是B站的这个效果,显然比上面的方案更加成熟和完整,所以,通过调研可以发现,它们使用的是Live2D的方案。


http://www.live2d.com/


动态壁纸的Demo如下。


github.com/Live2D/Cubi…


这个东西是小日子的一个SDK,专业做2D可交互纸片人,这个东西已经出来很久了,前端之前用它来做网页的看板娘,现在客户端又拿来做动态壁纸,风水轮流换啊,想要使用的,可以参考它们官方的Demo。



但是官方的动态壁纸Demo在客户端是有Bug的,会存在各种闪的问题,由于我本身不懂OpenGL,所以也无法解决,通过回退Commit,发现可以直接使用这个CommitID : Merge pull request #2 from Live2D/create-new-function ,就没有闪的问题。


a9040ddbf99d9a130495e4a6190592068f2f7a77



好了,B站YYDS,但我觉得这东西的使用场景太有限了,而且特别卡,极端影响功耗,所以,要不要这么卷呢,你看着办吧。


作者:xuyisheng
链接:https://juejin.cn/post/7135998448720936968
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

Flutter性能优化实践

前言 Flutter是谷歌的移动UI框架,可以快速在iOS和Android上构建高质量的原生用户界面。 Flutter可以与现有的代码一起工作。在全世界,Flutter正在被越来越多的开发者和组织使用,并且Flutter是完全免费、开源的,可以用一套代码同时构...
继续阅读 »

前言


Flutter是谷歌的移动UI框架,可以快速在iOS和Android上构建高质量的原生用户界面。 Flutter可以与现有的代码一起工作。在全世界,Flutter正在被越来越多的开发者和组织使用,并且Flutter是完全免费、开源的,可以用一套代码同时构建Android和iOS应用,性能可以达到原生应用一样的性能。但是,在较为复杂的 App 中,使用 Flutter 开发也很难避免产生各种各样的性能问题。在这篇文章中,我将介绍一些 Flutter 性能优化方面的应用实践。另外Flutter动态化框架已开源:


Github地址:github.com/wuba/fair


一、优化检测工具


Flutter编译模式


Flutter支持Release、Profile、Debug编译模式。




  1. Release模式,使用AOT预编译模式,预编译为机器码,通过编译生成对应架构的代码,在用户设备上直接运行对应的机器码,运行速度快,执行性能好;此模式关闭了所有调试工具,只支持真机。




  2. Profile模式,和Release模式类似,使用AOT预编译模式,此模式最重要的作用是可以用DevTools来检测应用的性能,做性能调试分析。




  3. Debug模式,使用JIT(Just in time)即时编译技术,支持常用的开发调试功能hot reload,在开发调试时使用,包括支持的调试信息、服务扩展、Observatory、DevTools等调试工具,支持模拟器和真机。




通过以上介绍我们可以知道,flutter为我们提供 profile模式启动应用,进行性能分析,profile模式在Release模式的基础之上,为分析工具提供了少量必要的应用追踪信息。


如何开启profile模式?


如果是独立flutter工程可以使用flutter run --profile启动。如果是混合 Flutter 应用,在 flutter/packages/flutter_tools/gradle/flutter.gradle 的 buildModeFor 方法中将 debug 模式改为 profile即可。


检测工具


1、Flutter Inspector (debug模式下)


Flutter Inspector有很多功能,其中有两个功能更值得我们去关注,例如:“Select Widget Mode” 和 “Highlight Repaints”。


Select Widget Mode点击 “Select Widget Mode” 图标,可以在手机上查看当前页面的布局框架与容器类型。



通过“Select Widget Mode”我们可以快速查看陌生页面的布局实现方式。



Select Widget Mode模式下,也可以在app里点击相应的布局控件查看


Highlight Repaints


点击 “Highlight Repaints” 图标,它会 为所有 RenderBox 绘制一层外框,并在它们重绘时会改变颜色。



这样做帮你找到 App 中频繁重绘导致性能消耗过大的部分。


例如:一个小动画可能会导致整个页面重绘,这个时候使用 RepaintBoundary Widget 包裹它,可以将重绘范围缩小至本身所占用的区域,这样就可以减少绘制消耗。



2、Performance Overlay(性能图层)


在完成了应用启动之后,接下来我们就可以利用 Flutter 提供的渲染问题分析工具,即性能图层(Performance Overlay),来分析渲染问题了。


我们可以通过以下方式开启性能图层



性能图层会在当前应用的最上层,以 Flutter 引擎自绘的方式展示 GPU 与 UI 线程的执行图表,而其中每一张图表都代表当前线程最近 300 帧的表现,如果 UI 产生了卡顿,这些图表可以帮助我们分析并找到原因。
下图演示了性能图层的展现样式。其中,GPU 线程的性能情况在上面,UI 线程的情况显示在下面,蓝色垂直的线条表示已执行的正常帧,绿色的线条代表的是当前帧:



如果有一帧处理时间过长,就会导致界面卡顿,图表中就会展示出一个红色竖条。下图演示了应用出现渲染和绘制耗时的情况下,性能图层的展示样式:



如果红色竖条出现在 GPU 线程图表,意味着渲染的图形太复杂,导致无法快速渲染;而如果是出现在了 UI 线程图表,则表示 Dart 代码消耗了大量资源,需要优化代码执行时间。


3、CPU Profiler(UI 线程问题定位)


在视图构建时,在 build 方法中使用了一些复杂的运算,或是在主 Isolate 中进行了同步的 I/O 操作。
我们可以使用 CPU Profiler 进行检测:



你需要手动点击 “Record” 按钮去主动触发,在完成信息的抽样采集后,点击 “Stop” 按钮结束录制。这时,你就可以得到在这期间应用的执行情况了。



其中:


x 轴:表示单位时间,一个函数在 x 轴占据的宽度越宽,就表示它被采样到的次数越多,即执行时间越长。


y 轴:表示调用栈,其每一层都是一个函数。调用栈越深,火焰就越高,底部就是正在执行的函数,上方都是它的父函数。


通过上述CPU帧图我们可以大概分析出哪些方法存在耗时操作,针对性的进行优化


一般的耗时问题,我们通常可以 使用 Isolate(或 compute)将这些耗时的操作挪到并发主 Isolate 之外去完成。


例如:复杂JSON解析子线程化


Flutter的isolate默认是单线程模型,而所有的UI操作又都是在UI线程进行的,想应用多线程的并发优势需新开isolate 或compute。无论如何await,scheduleTask 都只是延后任务的调用时机,仍然会占用“UI线程”, 所以在大Json解析或大量的channel调用时,一定要观测对UI线程的消耗情况。



二、Flutter布局优化


Flutter 使用了声明式的 UI 编写方式,而不是 Android 和 iOS 中的命令式编写方式。




  1. 声明式:简单的说,你只需要告诉计算机,你要得到什么样的结果,计算机则会完成你想要的结果,声明式更注重结果。




  2. 命令式:用详细的命令机器怎么去处理一件事情以达到你想要的结果,命令式更注重执行过程。




flutter声明式的布局方式通过三棵树去构建布局,如图:





  • Widget Tree: 控件的配置信息,不涉及渲染,更新代价极低。




  • Element Tree : Widget树和RenderObject树之间的粘合剂,负责将Widget树的变更以最低的代价映射到RenderObject树上。




  • RenderObject Tree : 真正的UI渲染树,负责渲染UI,更新代价极大。




1、常规优化


常规优化即针对 build() 进行优化,build() 方法中的性能问题一般有两种:耗时操作和 Widget 层叠。


1)、在 build() 方法中执行了耗时操作


我们应该尽量避免在 build() 中执行耗时操作,因为 build() 会被频繁地调用,尤其是当 Widget 重建的时候。
此外,我们不要在代码中进行阻塞式操作,可以将一般耗时操作等通过 Future 来转换成异步方式来完成。
对于 CPU 计算频繁的操作,例如图片压缩,可以使用 isolate 来充分利用多核心 CPU。


2)、build() 方法中堆叠了大量的 Widget


这将会导致三个问题:


1、代码可读性差:画界面时需要一个 Widget 嵌套一个 Widget,但如果 Widget 嵌套太深,就会导致代码的可读性变差,也不利于后期的维护和扩展。


2、复用难:由于所有的代码都在一个 build(),会导致无法将公共的 UI 代码复用到其它的页面或模块。


3、影响性能:我们在 State 上调用 setState() 时,所有 build() 中的 Widget 都将被重建,因此 build() 中返回的 Widget 树越大,那么需要重建的 Widget 就越多,也就会对性能越不利。


所以,你需要 控制 build 方法耗时,将 Widget 拆小,避免直接返回一个巨大的 Widget,这样 Widget 会享有更细粒度的重建和复用。


3)、尽可能地使用 const 构造器


当构建你自己的 Widget 或者使用 Flutter 的 Widget 时,这将会帮助 Flutter 仅仅去 rebuild 那些应当被更新的 Widget。
因此,你应该尽量多用 const 组件,这样即使父组件更新了,子组件也不会重新进行 rebuild 操作。特别是针对一些长期不修改的组件,例如通用报错组件和通用 loading 组件等。


4)、列表优化




  • 尽量避免使用 ListView默认构造方法


    不管列表内容是否可见,会导致列表中所有的数据都会被一次性绘制出来




  • 建议使用 ListView 和 GridView 的 builder 方法


    它们只会绘制可见的列表内容,类似于 Android 的 RecyclerView。





其实,本质上,就是对列表采用了懒加载而不是直接一次性创建所有的子 Widget,这样视图的初始化时间就减少了。


2、深入光栅化优化


优化光栅线程


屏幕显示器一般以60Hz的固定频率刷新,每一帧图像绘制完成后,会继续绘制下一帧,这时显示器就会发出一个Vsync信号,按60Hz计算,屏幕每秒会发出60次这样的信号。CPU计算好显示内容提交给GPU,GPU渲染好传递给显示器显示。
Flutter遵循了这种模式,渲染流程如图:



flutter通过native获取屏幕刷新信号通过engine层传递给flutter framework



所有的 Flutter 应用至少都会运行在两个并行的线程上:UI 线程和 Raster 线程。




  • UI 线程


    构建 Widgets 和运行应用逻辑的地方。




  • Raster 线程


    用来光栅化应用。它从 UI 线程获取指令将其转换成为GPU命令并发送到GPU。




我们通常可以使用Flutter DevTools-Performance 进行检测,步骤如下:




  • 在 Performance Overlay 中,查看光栅线程和 UI 线程哪个负载过重。




  • 在 Timeline Events 中,找到那些耗费时间最长的事件,例如常见的 SkCanvas::Flush,它负责解决所有待处理的 GPU 操作。




  • 找到对应的代码区域,通过删除 Widgets 或方法的方式来看对性能的影响。





三、Flutter内存优化


1、const 实例化


const 对象只会创建一个编译时的常量值。在代码被加载进 Dart Vm 时,在编译时会存储在一个特殊的查询表里,仅仅只分配一次内存给当前实例。


我们可以使用 flutter_lints 库对我们的代码进行检测提示


2、检测消耗多余内存的图片


Flutter Inspector:点击 “Highlight Oversizeded Images”,它会识别出那些解码大小超过展示大小的图片,并且系统会将其倒置,这些你就能更容易在 App 页面中找到它。


通过下面两张图可以清晰的看出使用“Highlight Oversizeded Images”的检测效果















12

针对这些图片,你可以指定 cacheWidth 和 cacheHeight 为展示大小,这样可以让 flutter 引擎以指定大小解析图片,减少内存消耗。



3、针对 ListView item 中有 image 的情况来优化内存


ListView 不会销毁那些在屏幕可视范围之外的那些 item,如果 item 使用了高分辨率的图片,那么它将会消耗非常多的内存。


ListView 在默认情况下会在整个滑动/不滑动的过程中让子 Widget 保持活动状态,这一点是通过 AutomaticKeepAlive 来保证,在默认情况下,每个子 Widget 都会被这个 Widget 包裹,以使被包裹的子 Widget 保持活跃。
其次,如果用户向后滚动,则不会再次重新绘制子 Widget,这一点是通过 RepaintBoundaries 来保证,在默认情况下,每个子 Widget 都会被这个 Widget 包裹,它会让被包裹的子 Widget 仅仅绘制一次,以此获得更高的性能。
但,这样的问题在于,如果加载大量的图片,则会消耗大量的内存,最终可能使 App 崩溃。



通过将这两个选项置为 false 来禁用它们,这样不可见的子元素就会被自动处理和 GC。


4、多变图层与不变图层分离


在日常开发中,会经常遇到页面中大部分元素不变,某个元素实时变化。如Gif,动画。这时我们就需要RepaintBoundary,不过独立图层合成也是有消耗,这块需实测把握。


这会导致页面同一图层重新Paint。此时可以用RepaintBoundary包裹该多变的Gif组件,让其处在单独的图层,待最终再一块图层合成上屏。



5、降级CustomScrollView,ListView等预渲染区域为合理值


默认情况下,CustomScrollView除了渲染屏幕内的内容,还会渲染上下各250区域的组件内容,例如当前屏幕可显示4个组件,实际仍有上下共4个组件在显示状态,如果setState(),则会进行8个组件重绘。实际用户只看到4个,其实应该也只需渲染4个, 且上下滑动也会触发屏幕外的Widget创建销毁,造成滚动卡顿。高性能的手机可预渲染,在低端机降级该区域距离为0或较小值。


四、总结


Flutter为什么会卡顿、帧率低?总的来说均为以下2个原因:




  • UI线程慢了-->渲染指令出的慢




  • GPU线程慢了-->光栅化慢、图层合成慢、像素上屏慢




所以我们一般使用flutter布局尽量按照以下原则


Flutter优化基本原则:




  • 尽量不要为 Widget 设置半透明效果,而是考虑用图片的形式代替,这样被遮挡的 Widget 部分区域就不需要绘制了;




  • 控制 build 方法耗时,将 Widget 拆小,避免直接返回一个巨大的 Widget,这样 Widget 会享有更细粒度的重建和复用;




  • 对列表采用懒加载而不是直接一次性创建所有的子 Widget,这样视图的初始化时间就减少了。




五、其他


如果大家对flutter动态化感兴趣,我们也为大家准备了flutter动态化平台-Fair


欢迎大家使用 Fair,也欢迎大家为我们点亮star



Github地址:github.com/wuba/fair

Fair官网:fair.58.com


作者:王猛猛
链接:https://juejin.cn/post/7146460160699924488
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

关于 MVI,我想聊的更明白些

MVI
前言 谈到 MVI,相信大家略有耳闻,由于该架构有一定门槛,导致开发者要么完全理解,要么完全不理解。 且由于存在门槛,理解的开发者往往受 “知识的诅咒”,很难体会不理解的人困惑之所在,也即容易在分享时遗漏关键点,这也使得该技术点的普及和传播更加困难。 故这期专...
继续阅读 »

前言


谈到 MVI,相信大家略有耳闻,由于该架构有一定门槛,导致开发者要么完全理解,要么完全不理解。


且由于存在门槛,理解的开发者往往受 “知识的诅咒”,很难体会不理解的人困惑之所在,也即容易在分享时遗漏关键点,这也使得该技术点的普及和传播更加困难。


故这期专为 MVI 打磨一篇 “通俗易懂、看完便理解来龙去脉、并能自行判断什么时候适用、是否非用不可”,相信阅读后你会耳目一新。


文章目录一览



  • 前言

  • 响应式编程

    • 响应式编程的好处

    • 响应式编程的漏洞

    • 响应式编程的困境



  • MVI 的存在意义

  • MVI 的实现

    • 函数式编程思想

    • MVI 怎样实现纯函数效果

    • 存在哪些副作用

    • 整体流程



  • 当下开发现状的反思

    • 从源头把问题消灭

    • 什么是过度设计,如何避免

    • 平替方案的探索



  • 综上


响应式编程


谈到 MVI,首先要提的是 “响应式编程”,响应式是 Reactive 翻译成中文叫法,对应 Java 语言实现是 RxJava,


ReactiveX 官方对 Rx 框架描述是:使用 “可观察流” 进行异步编程的 API,


翻译成人话即,响应式编程暗示人们 应当总是向数据源请求数据,然后在指定的观察者中响应数据的变化


常见的 “响应式编程” 流程用伪代码表示如下:



响应式编程的好处


通过上述代码易得,在响应式编程下,业务逻辑在 ViewModel / Presenter 处集中管理,过程中向 UI 回推状态,且 UI 控件在指定的 “粘性观察者” 中响应,该模式下很容易做单元测试,有输入必有回响


反之如像往常一样,将控件渲染代码分散在观察者以外的各个方法中,便很难做到这一点。


响应式编程的漏洞


随着业务发展,人们开始往 “粘性观察者” 回调中添加各种控件渲染,


如果同一控件实例(比如 textView)出现在不同粘性观察者回调中:


livedata_A.observe(this, dataA ->
textView.setText(dataA.b)
...
}

livedata_B.observe(this, dataB ->
textView.setText(dataB.b)
...
}

假设用户操作使得 textView 先接收到 liveData_B 消息,再接收到 liveData_A 消息,


那么旋屏重建后,由于 liveData_B 的注册晚于 liveData_A,textView 被回推的最后一次数据反而是来自 liveData_B,


给用户的感觉是,旋屏后展示老数据,不符预期。


响应式编程的困境


由此可得,响应式编程存在 1 个不显眼的关键细节:


一个控件应当只在同一个观察者中响应,也即同一控件实例不该出现在多个观察者中。


但如果这么做,又会产生新的问题。由于页面控件往往多达十数个,如此观察者也需配上十数个。


是否存在某种方式,既能杜绝 “一个控件在多个观察者中响应”,又能消除与日俱增的观察者?答案是有 —— 即接下来我们介绍的 MVI。


MVI 的存在意义


MVI 是 在响应式编程的前提下,通过 “将页面状态聚合” 来统一消除上述 2 个问题,


也即原先分散在各个 LiveData 中的 String、Boolean 等状态,现全部聚合到一个 JavaBean / data class 中,由唯一的粘性观察者回推,所有控件都在该观察者中响应数据的变化。


具体该如何实现?业界有个简单粗暴的解法 —— 遵循 “函数式编程思想”。


MVI 的实现


函数式编程思想


函数式编程的核心主要是纯函数,这种函数只有 “参数列表” 这唯一入口来传入初值,只有 “返回值” 这唯一出口来返回结果,且 “运算过程中” 不调用和影响函数作用域外的变量(也即 “无副作用”),


int a

public int calculate(int b){ //纯函数
return b + b
}

public int changeA(){ //非纯函数,因运算过程中调用和影响到外界变量 a
 int c = a = calculate(b)
 return c
}

public int changeB() { //纯函数
 int b = calculate(2)
 return b + 1
}

显而易见,纯函数的好处是 “可以闭着眼使用”,有怎样的输入,必有怎样的输出,且过程中不会有预料外的影响发生。



这里贴一张网上盛传的图来说明 Model、View、Intent 三者关系,


笔者认为,MVI 并非真的 “纯函数实现”,而只是 “纯函数思想” 的实现,


也即我们实际上都是以 “面向对象” 方式在编程,从效果上达到 “纯函数” 即可,


反之如钻牛角尖,看什么都 “有副作用、不纯”,则易陷入悲观,忽视本可改善的环节,有点得不偿失。


MVI 怎样实现纯函数效果


Model 通常是继承 Jetpack ViewModel 来实现,负责处理业务逻辑;


Intent 是指发起本次请求的意图,告诉 Model 本次执行哪个业务。它可以携带或不带参数;


View 通常对应 Activity/Fragment,根据 Model 返回的 UiStates 进行渲染。


也即我们让 Model 只暴露一个入口,用于输入 intent;只暴露一个出口,用于回调 UiStates;业务执行过程中不影响 UiStates 以外的结果;且 UiStates 的字段都设置为不可变(final / val)确保线程安全,即可达成 Model 的 “纯”,


Intent 达成 “纯” 比较简单,由于它只是个入参,字段都设置为不可变即可。


View 同样不难,只要确保 View 的入口就是 Model 的出口,也即 View 的控件都集中放置在 Model 的回调中渲染,即可达成 “纯”。


存在哪些副作用


存在争议的副作用


那有人可能会说,“不对啊,View 在入口中调用了控件实例,也即函数作用域外的成员变量,是副作用呀” …… 笔者认为这是误解,


因为 MVI 的 View 事实上就不是一个函数,而是一个类。如上文所述,MVI 实际上是 通过面向对象编程的方式实现 “纯函数” 效果,而非真的纯函数,


故我们可以站在类的角度重新审视 —— 控件是类成员,对应的是纯函数的自动变量,


换言之,控件渲染并没有调用和影响到 View 作用域外的元素,故不算副作用。


公认的副作用


与此同时,UiEvents 属于副作用,也即那些弹窗、页面跳转等 “一次性消费” 的情况,


为什么?笔者认为 “弹窗、页面跳转” 时,在当前 MVI-View 页面之外创建了新的 Window、或是在返回栈添加了新的页面,如此等于调用和影响了外界环境,所以这必是副作用,


不过这是符合预期的副作用,对此官方 Guide 也有介绍 “将 UiEvents 整合到 UiStates” 的方式来改善该副作用:界面事件 | Android 开发者 | Android Developers


与之相对的即 “不符预期的副作用” —— 例如控件实例被分散在观察者外的各个方法中,并在某个方法中被篡改和置空,其他方法并不知情,调用该实例即发生 NullPointException。


整体流程


至此 MVI 的代码实现已呼之欲出:


1.创建一个 UiStates,反映当前页面的所有状态。


data class UiStates {
val weather : Weather,
 val isLoading : Boolean,
 val error : List<UiEvent>,
}

2.创建一个 Intent,用于发送请求时携带参数,和指明当前想执行的业务。


sealed class MainPageIntent {
data class GetWeather(val cityCode) : MainPageIntent()
}

3.执行业务的过程,总是先从数据层获取数据,然后根据情况分流和回推结果,例如请求成功,便执行 Success 来回推结果,请求失败,则 Error,对此业内普遍的做法是,增设一个 Actions,


并且由于 UiStates 的字段不可变,且控件集中响应 UiStates,也即务必确保 UiStates 的延续,由此每个业务带来局部改变时(partialChange),需通过 copy 等方式,将上一次的 UiStates 拷贝一份,并为对应字段注入 partialChange。这个过程业内称为 reduce。


sealed class MainPageActions {
 fun reduce(oldStates : UiStates) : UiStates {
   return when(this){
     Loading -> oldStates.copy(isLoading = true)
     is Success -> oldStates.copy(isLoading = false, weather = this.weather)
     is Error -> oldStates.copy(isLoading = false, error = listOf(UiEvent(msg)))
  }
}
 
object Loading : MainPageActions()
data class Success(val weather : Weather) : MainPageActions()
data class Error(val msg : String) : MainPageActions()
}

4.创建当前页面使用的 MVI-Model。


class MainPageModel : MVI_Model<UiStates>() {
 private val _stateFlow = MutableStateFlow(UiStates())
 val stateFlow = _stateFlow.asStateFlow
 
 private fun sendResult(uiStates: S) = _stateFlow.emit(uiStates)
 
 fun input(intent: Intent) = viewModelScope.launch{ onHandle() }
 
 private suspend fun onHandle(intent: Intent) {
   when(intent){
  is GetWeather -> {
       sendResult(MainPageActions.Loading.reduce(oldStates)
  val response = api.post()
  if(response.isSuccess) sendResult(
        MainPageActions.Success(response.data).reduce(oldStates)
  else sendResult(
        MainPageActions.Error(response.message).reduce(oldStates)
  }
  }
}
}

5.创建 MVI-View,并在 stateFlow 中响应 MVI-Model 数据。


控件集中响应,带来不必要的性能开销,需要做个 diff,只响应发生变化的字段。


笔者通常是通过 DataBinding ObservableField 做防抖。后续如 Jetpack Compose 普及,建议是使用 Jetpack Compose,无需开发者手动 diff,其内部类似前端 DOM ,根据本次注入的声明树自行在内部差分合并渲染新内容。


class MainPageActivity : Android_Activity(){
private val model : MainPageModel
 private val views : MainPageViews
fun onCreate(){
   lifecycleScope.launch {
   repeatOnLifecycle(Lifecycle.State.STARTED) {
     model.stateFlow.collect {uiStates ->
 views.progress.set(uiStates.isLoading)
 views.weatherInfo.set(uiStates.weather.info)
      ...
    }
   }
   model.input(Intent.GetWeather(BEI_JING))
}
 class MainPageViews : Jetpack_ViewModel() {
val progress = ObservableBoolean(false)
   val weatherInfo = ObservableField<String>("")
  ...
}
}

整个流程用一张图表示即:



当下开发现状的反思


上文我们追溯了 MVI 来龙去脉,不难发现,MVI 是给 “响应式编程” 填坑的存在,通过状态聚合来消除 “不符预期回推、观察者爆炸” 等问题,


然而 MVI 也有其不便之处,由于它本就是要通过聚合 UiStates 来规避上述问题,故 UiStates 很容易爆炸,特别是字段极多情况下,每次回推都要做数十个 diff ,在高实时场景下,难免有性能影响,


MVI 许多页面和业务都需手写定制,难通过自动生成代码等方式半自动开发,故我们我们不如退一步,反思下为什么要用响应式编程?是否非用不可?


穷举所有可能,笔者觉得最合理的解释是,响应式编程十分便于单元测试 —— 由于控件只在观察者中响应,有输入必有回响,


也是因为这原因,官方出于完备性考虑,以响应式编程作为架构示例。


从源头把问题消灭


现实情况往往复杂。


Android 最初为了站稳脚跟,选择复用已有的 Java 生态和开发者,乃至使用 Java 作为官方语言,后来 Java 越来越难支持现代化移动开发,故而转向 Kotlin,


Kotlin 开发者更容易跟着官方文档走,一开始就是接受 Flow 那一套,且 Kotlin 抹平了语法复杂度,天然适合 “响应式编程” 开发,如此便有机会踩坑,乃至有动力通过 MVI 来改善。


然而 10 个 Android 7 个纯 Java ,其中 6 个从不用 RxJava ,剩下一个还是偶尔用用 RxJava 的线程调度切换,所以响应式编程在 Android Java 开发者中的推行不太理想,领导甚至可能为了照顾多数同事,而要求撤回响应式代码,如此便很难有机会踩坑,更谈不上使用 MVI,


也因此,实际开发中更多考虑的是,如何从根源上避免各种不可预期问题。


对此从软件工程角度出发,笔者在设计模式原则中找到答案 —— 任何框架,只要遵循单一职责原则,便能有效避免各种不可预期问题,反之过度设计则易引发不可预期问题。


什么是过度设计,如何避免


上文提到的 “粘性观察者”,对应的是 BehaviorSubject 实现,强调 “总是有一个状态”,比如门要么是开着,要么是关着,门在订阅 BehaviorSubject 时,会被自动回推最后一次 State 来反映状态。


常见 BehaviorSubject 实现有 ObservableField、LiveData、StateFlow 等。


反之是 PublishSubject 实现,对应的是一次性事件,常见 PublishSubject 实现有 SharedFlow 等。


笔者认为,LiveData/StateFlow 存在过度设计,因为它的观察者是开放式,一旦开了这口子,后续便不可控,一个良好的设计是,不暴露不该暴露的口子,不给用户犯错的机会


一个正面的案例是 DataBinding observableField,不向开发者暴露观察者,且一个控件只能在 xml 中绑定一个,从根源上杜绝该问题。


平替方案的探索


至此平替方案便也呼之欲出 —— 使用 ObservableField 来承担 BehaviorSubject,


也即直接在 ViewModel 中调用 ObservableField 通知所绑定的控件响应,且每个 ObservableField 都携带原子数据类型(例如 String、Boolean 等类型),


如此便无需声明 UiStates 数据类。由于无 UiStates、无聚合、也无线程安全问题,也就无需再 reduce 和 diff,简单做个 Actions 为结果分流即可。



综上


响应式编程便于单元测试,但其自身存在漏洞,MVI 即是来消除漏洞,


MVI 有一定门槛,实现较繁琐,且存在性能等问题,难免同事撂挑子不干,一夜回到解放前,


综合来说,MVI 适合与 Jetpack Compose 搭配实现 “现代化的开发模式”,


反之如追求 “低成本、复用、稳定”,可通过遵循 “单一职责原则” 从源头把问题消除。


作者:KunMinX
链接:https://juejin.cn/post/7145317979708735496
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

Android 十六进制状态管理实战

背景最近需要实现一个状态管理类:在多种场景下,控制一系列的按钮是否可操作。不同场景下,在按钮不可操作的时候,点击弹出对应的Toast。随着场景数量的增加,这个管理类的实现,就可能会越来越复杂。刚好看到大佬的文章,顺便学习和实践一下。参考学习:就算不去火星种土豆...
继续阅读 »

背景

最近需要实现一个状态管理类:

  1. 在多种场景下,控制一系列的按钮是否可操作。
  2. 不同场景下,在按钮不可操作的时候,点击弹出对应的Toast。
  3. 随着场景数量的增加,这个管理类的实现,就可能会越来越复杂。

刚好看到大佬的文章,顺便学习和实践一下。
参考学习:就算不去火星种土豆,也请务必掌握的 Android 状态管理最佳实践

示例

13c85a24-3607-4d61-8bd2-6311d7200c84.png

还是用大佬那个例子。
例如,存在 3 种模式,和 3个按钮,按钮不可用的时候弹出对应的 Toast。
模式 A 下,要求 按钮1、按钮2 可用,按钮3不可用。点击按钮3,Toast 提示“A3”。
模式 B 下,要求 按钮2 可用,按钮1和按钮3不可用。点击按钮1,Toast 提示“B1”。点击按钮3,Toast 提示“B3”。
模式 C 下,要求 按钮1 可用,按钮2和按钮3不可用。点击按钮2,Toast 提示“C2”。点击按钮3,Toast 提示“C3”。

实现思路

  • Kotlin中的位操作
shl(bits) – 左移位 
shr(bits) – 右移位
and(bits) – 与
or(bits) – 或
  • 定义多个十六进制的状态常量,代表不同的状态。
    private const val STATE_IDIE = 1
private const val STATUS_A = 1 shl 1
private const val STATUS_B = 1 shl 2
private const val STATUS_C = 1 shl 3
  • 定义一个变量,用于存放当前的状态。
    当状态发生变化,需要切换状态的时候,只需要去修改这个变量就行了。
    private var currentStatus = STATE_IDIE

//测试代码
private fun changeStateToA(){
changeStateToA = STATUS_A
}
  • 定义多个十六进制的标志常量,代表对应的禁用操作。
    比如 DISABLE_BTN_1,代表禁用按钮1。
    //定义不可操作的一些行为
private const val DISABLE_BTN_1 = 1 shl 4
private const val DISABLE_BTN_2 = 1 shl 5
private const val DISABLE_BTN_3 = 1 shl 6
  • 定义模式状态集,由状态+多个禁用标志位组成。
    比如 MODE_A,就是在状态为 STATUS_A 的时候,按钮3禁用,那就将这两个数值进行或运算,结果就是 STATUS_A or DISABLE_BTN_3。
    private const val MODE_A = STATUS_A or DISABLE_BTN_3
private const val MODE_B = STATUS_B or DISABLE_BTN_1 or DISABLE_BTN_3
private const val MODE_C = STATUS_C or DISABLE_BTN_2 or DISABLE_BTN_3
private val modeList = listOf(MODE_A, MODE_B, MODE_C)
  • 定义按钮不可点击时的Toast文案 ,使用 HashMap 进行存储映射关系。
  1. key 为对应状态+禁用标志位的 或运算 结果。这样的计算结果,是可以保证key是唯一的,不会出现重复的情况。
  2. value 为对应的 Toast 文案。
  3. 只需要一个 HashMap 就可以实现所有的配置关系。
  4. 从代码阅读性来说,使用这样的代码进行配置,看起来也比较通俗易懂。
    比如 Pair(STATUS_A or DISABLE_BTN_3, "A3"),就是代表在状态A的时候,禁用按钮3,点击按钮的时候弹的Toast文案为 “A3”。
    private val toastMap = hashMapOf(
Pair(STATUS_A or DISABLE_BTN_3, "A3"),
Pair(STATUS_B or DISABLE_BTN_1, "B1"),
Pair(STATUS_B or DISABLE_BTN_3, "B3"),
Pair(STATUS_C or DISABLE_BTN_2, "C2"),
Pair(STATUS_C or DISABLE_BTN_3, "C3")
)
  • 核心逻辑:判断在当前模式下,按钮是否可用。
    是否可用的判断:判断当前所处的状态,是否包含对应定义的禁用操作。
currentStatus and action !=0

若可操作,返回 true。
若不可操作,通过 currentStatus or action 的运算结果作为key,通过上面配置的 HashMap 集合,拿到对应的 Toast 文案。

    /**
* 判断当前某个行为是否可操作
*
* @return true 可操作;false,不可操作。
*/
private fun checkEnable(action: Int): Boolean {
val result = modeList.filter {
(it and currentStatus) != 0
&& (it and action) != 0
}
if (result.isNotEmpty()) {
println("result is false, toast:${toastMap[currentStatus or action]}")
return false
}
println("result is true")
return true
}
复制代码
  • 完整代码
object SixTeenTest {
//定义状态常量
private const val STATE_IDIE = 1
private const val STATUS_A = 1 shl 1
private const val STATUS_B = 1 shl 2
private const val STATUS_C = 1 shl 3

//定义不可操作的一些行为
private const val DISABLE_BTN_1 = 1 shl 4
private const val DISABLE_BTN_2 = 1 shl 5
private const val DISABLE_BTN_3 = 1 shl 6

//定义模式状态集
private const val MODE_A = STATUS_A or DISABLE_BTN_3
private const val MODE_B = STATUS_B or DISABLE_BTN_1 or DISABLE_BTN_3
private const val MODE_C = STATUS_C or DISABLE_BTN_2 or DISABLE_BTN_3
private val modeList = listOf(MODE_A, MODE_B, MODE_C)

//定义Toast映射关系
private val toastMap = hashMapOf(
Pair(STATUS_A or DISABLE_BTN_3, "A3"),
Pair(STATUS_B or DISABLE_BTN_1, "B1"),
Pair(STATUS_B or DISABLE_BTN_3, "B3"),
Pair(STATUS_C or DISABLE_BTN_2, "C2"),
Pair(STATUS_C or DISABLE_BTN_3, "C3")
)

//当前状态
private var currentStatus = STATE_IDIE

/**
* 判断当前某个行为是否可操作
*
* @return true 可操作;false,不可操作。
*/
private fun checkEnable(action: Int): Boolean {
val result = modeList.filter {
(it and currentStatus) != 0
&& (it and action) != 0
}
if (result.isNotEmpty()) {
println("result is false, toast:${toastMap[currentStatus or action]}")
return false
}
println("result is true")
return true
}
}

代码测试

    fun main(args: Array<String>) {
//测试代码
currentStatus = STATUS_A
println("STATUS_A")
checkEnable(DISABLE_BTN_1)
checkEnable(DISABLE_BTN_2)
checkEnable(DISABLE_BTN_3)
currentStatus = STATUS_B
println("STATUS_B")
checkEnable(DISABLE_BTN_1)
checkEnable(DISABLE_BTN_2)
checkEnable(DISABLE_BTN_3)
currentStatus = STATUS_C
println("STATUS_C")
checkEnable(DISABLE_BTN_1)
checkEnable(DISABLE_BTN_2)
checkEnable(DISABLE_BTN_3)
}

输出测试结果

STATUS_A
result is true
result is true
result is false, toast:A3
STATUS_B
result is false, toast:B1
result is true
result is false, toast:B3
STATUS_C
result is true
result is false, toast:C2
result is false, toast:C3

十六进制

761a9a41-50f4-4855-9c0e-dc41aa62edad.png

  • 16进制多状态管理本质上是二进制管理,即‘1’所处的位数。
  • 比如上面定义的各种变量,都是通过1左移n位数之后的结果。
  • 这样能够保证,多个不同变量的与运算、或运算结果,可以是唯一的。比如上面,用这个特性,用来做一层 Toast 文案的映射关系。

总结

  • 确实,像类似的场景,随着业务迭代场景数增加,在没有使用十六进制之前,整体的代码可能是会比较复杂的。
  • 使用十六进制之后,可能需要多花一点时间,去理解一下十六进制相关的知识,但是在代码实现上确实简单了很多。


作者:入魔的冬瓜
链接:https://juejin.cn/post/7147860255370641445
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »

乱打日志的男孩运气怎么样我不知道,加班肯定很多!

前言 线上出现问题,你的第一反应是什么? 如果是我的话,第一时间想的应该是查日志: if…else 到底进入了哪个分支? 关键参数是不是有缺失? 入参是不是有问题,没做好校验放进去了? 良好的日志能帮我们快速定位到问题所在,坑你的东西往往最为无形,良好的日...
继续阅读 »

前言


线上出现问题,你的第一反应是什么?


如果是我的话,第一时间想的应该是查日志:



  1. if…else 到底进入了哪个分支?

  2. 关键参数是不是有缺失?

  3. 入参是不是有问题,没做好校验放进去了?


良好的日志能帮我们快速定位到问题所在,坑你的东西往往最为无形,良好的日志就是要让这些玩意无所遁形!


日志级别


Java应用中,日志一般分为以下5个级别:



  • ERROR 错误信息

  • WARN 警告信息

  • INFO 一般信息

  • DEBUG 调试信息

  • TRACE 跟踪信息


1)ERROR


ERROR 级别的日志一般在 catch 块里面出现,用于记录影响当前线程正常运行的错误,出现 Exception 的地方就可以考虑打印 ERROR 日志,但不包括业务异常。


需要注意的是,如果你抛出了异常,就不要记录 ERROR 日志了,应该在最终的地方处理,下面这样做就是不对的:


try {
   int i = 1 / 0;
} catch (Exception e) {
   log.error("出错了,什么错我不知道,啊哈哈哈!", e);
   throw new CloudBaseException();
}

2)WARN


不应该出现,但是不会影响当前线程执行的情况可以考虑打印 WARN 级别的日志,这种情况有很多,比如:



  • 各种池(线程池、连接池、缓存池)的使用超过阈值,达到告警线

  • 记录业务异常

  • 出现了错误,但是设计了容错机制,因此程序能正常运行,但需要记录一下


3)INFO


使用最多的日志级别,使用范围很广,用来记录系统的运行信息,比如:



  • 重要模块中的逻辑步骤呈现

  • 客户端请求参数记录

  • 调用第三方时的参数和返回结构


4)DEBUG


Debug 日志用来记录自己想知道的所有信息,常常是某个功能模块运行的详细信息,已经中间的数据变化,以及性能信息。


Debug 信息在生产环境一般是关闭状态的,需要使用开关管理(比如 SpringBoot Admin 可以做到),一直开启会产生大量的 Debug,而 Debug 日志在程序正常运行时大部分时间都没什么用。


if (log.isDebugEnabled()) {
   log.debug("开始执行,开始时间:[{}],参数:[{}]", startTime, params);
   log.debug("通过计算,得到参数1:[{}],参数2:[{}]", param1, param2);
   log.debug("最后处理结果:[{}]", result);
}

5)TRACE


特别详细的系统运行完成信息,业务代码中一般不使用,除非有特殊的意义,不然一般用 DEBUG 代替,事实上,我编码到现在,也没有用过这个级别的日志。


使用正确的格式


如果你是这样打印日志的:


log.info("根据条件id:{}" + id + "查询用户信息");

不要这样做,会产生大量的字符串对象,占用空间的同时也会影响性能。


正确的做法是使用参数化信息的方式:


log.info("根据条件id:[{}],查询用户信息", id);

这样做除了能避免大量创建字符串之外,还能明确的把参数隔离出去,当你需要把参数复制出来的时候,只需要双击鼠标即可,而不是用鼠标慢慢对准再划拉一下。


这样打出来的日志,可读性强,对排查问题的帮助也很大!


小技巧


1)多线程


遇到多个线程一起执行的日志怎么打?


有些系统,涉及到并发执行,定时调度等等,就会出现多次执行的日志混在一起,出问题不好排查,我们可以把线程名打印进去,或者加一个标识用来表明这条日志属于哪一次执行:


if (log.isDebugEnabled()) {
   log.debug("执行ID=[{}],处理了ID=[{}]的消息,处理结果:[{}]", execId, id, result);
}

2)使用 SpringBoot Admin 灵活开关日志级别


image-20220727155526217


写在最后


一开始写代码的时候,没有规范日志的意识,不管哪里,都打个 INFO,打印出来的东西也没有思考过,有没有意义,其实让自己踩了不少坑,加了不少班,回过头,我想对学习时期的我说一句:”能让你加班的东西,都藏在各种细节里!写代码之前,先好好学习如何打日志!“


作者:你算哪块小蛋糕
链接:https://juejin.cn/post/7124958610123128839
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

Android性能优化 - 包体积杀手之R文件内联原理与实现

前言&背景 包体积也是性能优化的常客之一了,在包体积简化的历史潮流中,已经涌现了很多包体积杀手级别方案,比如动态so方案,R文件内联等等,由于笔者已经在之前的文章中介绍过动态so方案,那么本次专栏就不重复,于是就介绍另一个包体积杀手方案,从R文件内联的...
继续阅读 »

前言&背景


包体积也是性能优化的常客之一了,在包体积简化的历史潮流中,已经涌现了很多包体积杀手级别方案,比如动态so方案,R文件内联等等,由于笔者已经在之前的文章中介绍过动态so方案,那么本次专栏就不重复,于是就介绍另一个包体积杀手方案,从R文件内联的角度出发,看看我们是怎么完成一次华丽的R文件精简


在android 日常开发中,我们对资源的引用都会用到R.xx.xx 去获取,R文件这个贯穿着整个项目周期,从而简化了我们很多工作。R文件带给我们便利的同时,也会带来很多对包体积的负面影响,其中有一个就是R文件过大导致的,一个中型项目的R文件,可能会达到10M,其中资源重复的部分/多余的部分,可能就有4/5M,下面我们从实战角度出发,探索一下R文件的“今生前世”


R文件产生


在Android编译打包的过程中,位于res/目录下的文件,就会通过aapt工具,对里面的资源进行编译压缩,从而生成相应的资源id,且生成R.java文件,用于保存当前的资源信息,同时生成resource.arsc文件,建立id与其对应资源的值,如图


image.png
其中R文件中还有几个static final 修饰的子类,比如anim,attr,layout,分别对应着res/目录下相应的子目录,同时资源id用一个16进制的int数值表示。比如0x7f010000,我们来解释一下具体含义



  1. 第一个字节7f:代表着这个资源属于本应用apk的资源,相应的以01代表开头的话(比如0x01010000)就代表这是一个与应用无关的系统资源。0x7f010000,表明abc_fade_in 属于我们应用的一个资源

  2. 第二个字节01:是指资源的类型,比如01就代表着这个资源属于anim类型

  3. 第三,四个字节0000:指资源的编号,在所属资源类型中,一般从0000开始递增


同时我们可以留意到,这个R文件的内部的属性,都是以static final 修饰的,这就意味着是一个常量类型,常量在编译过程中,可以被“内联化”,即R.anim.abc_fade_in 可以用0x7f010000所代表的数值进行直接替换。


正常情况下,即app目录下的R文件的过程就是如此,那么类似lib(子module),aar包的这种,生成的R文件也是这样吗?不是的!如果说lib/aar 也是这样生成R文件的话,那么最终的资源id也会是常量,比如lib中有个R.anim.other,按照默认模式的话,生成的id也应该是0x7f010000,这样一来就会产生了一个问题,就是资源id冲突的问题!因为app模块下R.anim.abc_fade_in 跟子module/aar中有个R.anim.other产生了同一个id。所以gradle给出了一个解决方法,就是在编译子module或者aar中,编译的时候产生一个R.def.txt(只在module有效,不同AGP版本会有不同实现,低版本是R.txt)文件,该文件记录着当前的资源映射关系,比如我在子module中有一个布局layout文件activity_my_test


image.png


此时生成的这个映射关系就不包含真正的资源id,而是把其当作一个输入传给app模块一起编译,从而得到最终的资源id,并且生成一个全局的R文件(该R文件包含了所有子module/aar的R文件与自身的R文件)与全局R.txt文件(记录所有id映射,这个大有用途,我们下面会讲),并且此时通过gralde中任务generateDebugRFile,生成一个专属于子module的R文件(此时的R文件就是static final的,因为经过了资源id的重新定位)所以此时子module中也就可以用R.xx.xx去引用到自己的资源,比如上述的activity_my_test所属于的子module生成的R文件如下:


image.png
全局的R文件也会包含子R文件的内容


image.png
我们再把大致的过程如图展示


image.png


R文件过大的原因


通过上述R文件生成的分析,我们可以看到R文件占用多余的原因,下层的module/aar生成的id除了自己会生成一个R文件外,同时也会在全局的R文件生成一个一个同样的属性,比如activity_my_test存在了两份,如果module多的话,R文件的数量同样会膨胀上升!在我们组件化过程中,多module肯定是很正常的,前文我们也说过,app module中的R文件会被内联化替代,所以appmodule 中的R文件内容如果没有被直接引用了,是可以通过proGuard去直接删除掉的,所以release环境下我们可以通过proGuard去移除不必要的R文件,但是被引用到的R文件(module/aar中的R文件)就无法这么做了,同时如果项目中存在(反向引用,比如其他模块依赖了app,情况比较少)那么所有的R文件就都无法被proGuard删除了。


R文件内联方案


R.txt


在上面讲解中,我们留下了一个疑问,就是R.txt,它记录了所有的资源映射关系,那么这个R.txt存放在哪里呢?我们以com.android.tools.build:gradle:3.4.1中的源码为例子:生成R.txt是在



TaskManager中

private void createNonNamespacedResourceTasks(
@NonNull VariantScope scope,
@NonNull File symbolDirectory,
InternalArtifactType packageOutputType,
@NonNull MergeType mergeType,
@NonNull String baseName,
boolean useAaptToGenerateLegacyMultidexMainDexProguardRules) {
File symbolTableWithPackageName =
FileUtils.join(
globalScope.getIntermediatesDir(),
FD_RES,
"symbol-table-with-package",
scope.getVariantConfiguration().getDirName(),
"package-aware-r.txt");
final TaskProvider<? extends ProcessAndroidResources> task;
// 重点
File symbolFile = new File(symbolDirectory, FN_RESOURCE_TEXT);

FN_RESOURCE_TEXT是个常量,代表着 R.txt,同时可以看到symbolDirectory就是路径,而这个赋值在createApkProcessResTask 中


private void createApkProcessResTask(@NonNull VariantScope scope,
InternalArtifactType packageOutputType) {
createProcessResTask(
scope,
new File(
globalScope.getIntermediatesDir(),
"symbols/" + scope.getVariantData().getVariantConfiguration().getDirName()),
packageOutputType,
MergeType.MERGE,
scope.getGlobalScope().getProjectBaseName());
}

所以路径我们一目了然了,就是在build/intermediates/symbols之后的子目录下(这个在4.多的版本有变化,4.多在runtime_symbol_list 子目录下,需要注意)这样一来,我们就得到了R.txt,之后解析的时候有用


R文件字节码替换


了解方案之前,我们看一下平常的R文件是怎么被使用的,我们以setContentView这个举例,当我们在app模块中,调用了


setContentView(R.layout.activity_main)

编译后的字节码是这样的:


 LDC 2131427356
INVOKEVIRTUAL com/example/spider/MainActivity.setContentView (I)V

但是当我们在子moudle中


setContentView(R.layout.activity_my_test)

同样看一下字节码


 GETSTATIC com/example/test/R$layout.activity_my_test : I
INVOKEVIRTUAL com/example/test/MyTestActivity.setContentView (I)V

看看我们发现了什么!同样是setContentView,入参是int类型情况下,在app模块中,是通过常量引入的方式 LDC 2131427356放入操作数栈,提供给setContentView消费的,那么这个2131427356是什么呢?其实就是资源id,我们可以在R.txt中找到


image.png
而7f0b001c换算成10进制,就是2131427356。


既然app模块能这样做,我们又知道了R.txt内容,所以我们能不能把子module的GETSTATIC换成跟app模块一样的实现呢?这样我们就不用依赖了R文件,后期就可以通过proGuard删除了!答案是可以的!这个时候只需要我们从R.txt 找到activity_my_test 对应的id(例子是0x7f0b001d),换算成10进制就是2131427357,我们再把GETSTATIC 指令替换成LDC指令就完事了,代码如下:


ASM tree api

if(node.opcode == Opcodes.GETSTATIC && node.desc == "I" && node.owner.substring(node.owner.lastIndexOf('/') + 1).startsWith('R$')&& !(node.owner.startsWith(COM_ANDROID_INTERNAL_R) || node.owner.startsWith(ANDROID_R))){
println("get node ")
def ldc = new LdcInsnNode(2131427357)
method.instructions.insertBefore(node,ldc)
method.instructions.remove(node)
}

LdcInsnNode(2131427357) 通过指令集替换,我们就实现了R文件内联的操作了,同时这里还有很多小玩法,比如LdcInsnNode(特定的id),我们甚至能够实现编译时替换布局,这里就不过多展开


扩展


看到这里,我们就能明白了R文件内联究竟干了什么,但是实际上我们也只是替换了一个R文件罢了,如果我们想要替换更多的R文件怎么办?没事!这里已经有很多成熟的开源库帮我们做啦!比如bytex booster


当然,R文件内联不一定适用所有场景,比如直接用到R文件id的场景就不适合了


public static int getId(String num){ 
try {
String name = "drawable" + num;
Field field = R.drawable.class.getField(name);
return field.getInt(null);
} catch (Exception e) {
e.printStackTrace();
}
return 0;
}

因为涉及到了R文件属性的读写,这种情况我们就不能用内联的方式了!同时常见的还有ConstraintLayout中,会涉及到id的直接使用,这部分就要加入Transform转换的白名单,避免被内联化啦!


总结


通过本文的阅读,相信你已经了解到包体积优化中-R文件内联的实现思路啦!我们在实际项目中也用到了R文件内联,收益大概是5M左右。如果你的项目是agp 4.1.0 的话,可以直接开启R 文件的内联,不需要引入三方库即可实现!!官方都引入了这个特性,这个稳定性是可以保证的啦!详细可查看:
developer.android.com/studio/rele…


作者:Pika
链接:https://juejin.cn/post/7146807432755281927
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

依赖反转原则到底反转了什么

问题SOLID是常用的用来设计类以及类和类之间关系的设计原则,它的主要作用就是告诉我们如何将数据和函数组织为类,以及如何将这些类链接为程序,从而使得软件容易扩展、容易理解以及容易复用。其中D代表的就是依赖反转原则(Dependence Inversion Pr...
继续阅读 »

问题

SOLID是常用的用来设计类以及类和类之间关系的设计原则,它的主要作用就是告诉我们如何将数据和函数组织为类,以及如何将这些类链接为程序,从而使得软件容易扩展、容易理解以及容易复用。其中D代表的就是依赖反转原则(Dependence Inversion Principle),常见的解释就是高层模块和低层模块都应该依赖抽象,而不应该依赖具体实现,这样就能更好的实现模块间的解耦。但是反转又体现在了哪里呢?

面向对象编程

为了解决这种问题,先看一下面向对象编程,面向对象编程是常见的编程范式之一,同时还有结构化编程与函数式编程,这三种编程范式对程序员的编写模式做了限定,与具体的编程语言关系较小。有时候我们会说Java是面向对象的语言,而C是面向结构的语言,我理解这些是在语言设计之初,设计者就对于语言的语法做了相关范式的选择,但是用C能不能进行面向对象的编程呢?我想也是可以的,只要遵守相应的规范。比如说,面向对象编程的三个特点:封装、继承、多态通过C其实也可以实现。

安全稳定的多态

这里主要对比一下C语言的多态和Java的多态方式,C语言通过函数指针实现多态,Java通过接口或者父类的实现类来复写方法来实现多态。这里以实现屏幕的展示功能为例。

//C
//screen.h
struct Screen{
void (*show)();
}

//huaweiscreen.h
#include "screen.h"
void show(){ //具体实现}
struct Screen huaiWeiScreen={show};

//main.c
include "huaweiscreen.h"
int main(){
struct Screen* screen=&huaiWeiScreen;
screen->show();
return 0;
}
//Java
interface Screen{
void show();
}

class HuaWeiScreen implements Screen{
@Override
public void show(){
//具体实现
}
}

public static void main(String[] args){
Screen screen=new HuaiWeiScreen();
screen.show();
}

Java通过接口实现的多态在语义上同C语言通过函数指针实现多态的对比来看,要清晰的多,同时对比函数指针,也更为安全,毕竟如果函数指针如果指错了实现,那么整个程序就会造成难以跟踪和消除的bug。由此可以看出类似Java这种面向对象的语言为我们提供了一种更加容易理解、更加安全的的多态实现方式。

依赖反转

在安全和易于理解的多态支持出现之前,软件的架构是什么样子呢?

依赖注入架构.png

业务逻辑模块依赖数据库模块和UI模块,数据流动的方向和源码依赖的方向是一致的,但是这其实带来一个问题,业务逻辑本身其实并不关心数据库和UI的具体实现,使用MySQL还是SQLite以及是用文字展示UI还是动画展示UI业务逻辑不应该感知,但是因为缺乏一个容易理解、安全的多态方式,导致数据流动的方向和源码依赖方向必需保持一致,也让业务逻辑本身和数据库的具体实现以及UI的具体实现进行了绑定,这是不利于后续功能的扩展和修改的。 看一下使用多态后,架构设计的调整。

依赖注入改.png

业务逻辑模块声明数据库接口类和UI接口类,数据库模块和UI模块通过依赖业务逻辑模块,实现对应的接口,并且在更高层模块注入业务逻辑,这样数据库模块和UI模块成为了业务逻辑的插件,这种插件式的架构方便了插件的替换,业务逻辑模块不再依赖数据库模块以及UI模块,可以进行独立的部署,数据库模块的修改和UI模块的修改也不会对业务逻辑造成影响。可以注意到数据流动的方向和源码依赖的方向不再保持一致了,这就是多态的好处,无论怎样的源代码级别的依赖关系,都可以将其反转。

结论

所谓依赖反转的反转,是指支持多态的语言相对于不支持多态的语言,数据流方向和源码依赖方向不用再保持一致,可以相反,源码依赖的方向完全由开发者控制


作者:滑板上的老砒霜
链接:https://juejin.cn/post/7147285415966277669
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »

Kotlin协程:MutableStateFlow的实现原理

一.MutableStateFlow接口的实现 1.MutableStateFlow方法     在Kotlin协程:StateFlow的设计与使用中,讲到可以通过MutableSharedFlow方法创建一个Mutab...
继续阅读 »

一.MutableStateFlow接口的实现


1.MutableStateFlow方法


    在Kotlin协程:StateFlow的设计与使用中,讲到可以通过MutableSharedFlow方法创建一个MutableSharedFlow接口指向的对象,代码如下:


@Suppress("FunctionName")
public fun <T> MutableStateFlow(value: T): MutableStateFlow<T> =
StateFlowImpl(value ?: NULL)

...

@JvmField
@SharedImmutable
internal val NULL = Symbol("NULL")

    在MutableStateFlow方法中,根据参数value创建并返回一个类型为StateFlowImpl的对象,如果参数value为空,则传入对应的标识NULL。


二.StateFlowImpl类


    StateFlowImpl类是MutableStateFlow接口的核心实现,它的继承关系与SharedFlowImpl类的继承关系类似,如下图所示:
image.png



  • AbstractSharedFlow类:提供了对订阅者进行管理的方法。

  • CancellableFlow接口:用于标记StateFlowImpl类型的Flow对象是可取消的。

  • MutableStateFlow接口:表示StateFlowImpl类型的Flow对象是一个单数据更新的热流。

  • FusibleFlow接口:表示StateFlowImpl类型的Flow对象是可融合的。


1.发射数据的管理


    在StateFlowImpl中,当前的数据被保存在名为_state的全局变量中,_state表示StateFlowImpl类型对象的状态,当前代码如下:


private class StateFlowImpl<T>(
initialState: Any
) : AbstractSharedFlow<StateFlowSlot>(), MutableStateFlow<T>, CancellableFlow<T>, FusibleFlow<T> {
// 当前状态
private val _state = atomic(initialState)

...
}

    除此之外,StateFlowImpl不对其他的数据做缓存。


2.订阅者的管理


    由于StateFlowImpl类与SharedFLowImpl类都继承自AbstractSharedFlow类,因此二者订阅者管理的核心逻辑相同,这里不再赘述,详情可参考Kotlin协程:MutableSharedFlow的实现原理


    唯一不同的地方在,在SharedFlowImpl类中,订阅者数组中存储的对象类型为SharedFlowSlot,而在StateFlowImpl类中,订阅者数组存储的对象类型为StateFlowSlot。


1)StateFlowSlot类


    StateFlowSlot类与SharedFlowSlot类类似,都继承自AbstractSharedFlowSlot类。但相比于SharedFlowImpl类型的对象,StateFlowImpl类型的对象是有状态的。


    在StateFlowSlot类中,有一个名为_state的全局变量,代码如下:


@SharedImmutable
private val NONE = Symbol("NONE") // 状态标识

@SharedImmutable
private val PENDING = Symbol("PENDING") // 状态标识

private class StateFlowSlot : AbstractSharedFlowSlot<StateFlowImpl<*>>() {
// _state中默认值为null
private val _state = atomic<Any?>(null)

...
}

    根据_state保存对象的不同,可以确定StateFlowSlot类型的对象的状态。StateFlowSlot类型的对象共有四种状态:




  • null:如果_state保存的对象为空,表示当前StateFlowSlot类型的对象没有被任何订阅者使用。




  • NONE:如果_state保存的对象为NONE标识,表示当前StateFlowSlot类型的对象已经被对应的订阅者使用,但既没有挂起,也没有在处理当前的数据。




  • PENDING:如果_state保存的对象为PENDING标识,表示当前StateFlowSlot类型的对象已经被对应的订阅者使用,并且将开始处理当前的数据。




  • CancellableContinuationImpl<Unit>:如果_state保存的对象为续体,表示当前StateFlowSlot类型的对象已经被对应的订阅者使用,但是订阅者已处理完当前的数据,所在的协程已被挂起,等待新的数据到来。




a)订阅者状态的管理


    在StateFlowSlot类中,重写了AbstractSharedFlowSlot类的allocateLocked方法与freeLocked方法,顶用两个方法会对订阅者的初始状态和最终状态进行改变,代码如下:


// 新订阅者申请使用当前的StateFlowSlot类型的对象
override fun allocateLocked(flow: StateFlowImpl<*>): Boolean {
// 如果_state保存的对象不为空,
// 说明当前StateFlowSlot类型的对象已经被其他订阅者使用
// 返回false
if (_state.value != null) return false
// 走到这里,说明没有被其他订阅者使用,分配成功
// 修改状态值为NONE
_state.value = NONE
// 返回true
return true
}

// 订阅者释放已经使用的StateFlowSlot类型的对象
override fun freeLocked(flow: StateFlowImpl<*>): Array<Continuation<Unit>?> {
// 修改状态值为null
_state.value = null
// 返回空数组
return EMPTY_RESUMES
}


@JvmField
@SharedImmutable
internal val EMPTY_RESUMES = arrayOfNulls<Continuation<Unit>?>(0)

    为了实现上述对订阅者状态的管理,在StateFlowSlot类中,还额外提供了三个方法用于实现对订阅者的状态的切换,代码如下:


// 当有状态更新成功时,会调用makePending方法,通知订阅者可以开始处理新数据
@Suppress("UNCHECKED_CAST")
fun makePending() {
// 根据当前状态判断
_state.loop { state ->
when {
// 如果未被订阅者使用,则直接返回
state == null -> return
// 如果已经处于PENDING状态,则直接返回
state === PENDING -> return
// 如果当前状态为NONE
state === NONE -> {
// 通过CAS的方式,将状态修改为PENDPENDING,并返回
if (_state.compareAndSet(state, PENDING)) return
}
// 如果为挂起状态
else -> {
// 通过CAS的方法,将状态修改为NONE
if (_state.compareAndSet(state, NONE)) {
// 如果修改成功,则恢复对应续体的执行,并返回
(state as CancellableContinuationImpl<Unit>).resume(Unit)
return
}
}
}
}
}

// 当订阅者每次处理完新数据(不一定处理成功)后,会调用takePending方法,表示完成处理
// 获取当前的状态,并修改新状态为NONE
fun takePending(): Boolean = _state.getAndSet(NONE)!!.let { state ->
assert { state !is CancellableContinuationImpl<*> }
// 如果之前的状态为PENDING,则返回true
return state === PENDING
}

// 当订阅者没有新数据需要处理时,会调用awaitPending方法挂起
@Suppress("UNCHECKED_CAST")
// 直接挂起,获取续体
suspend fun awaitPending(): Unit = suspendCancellableCoroutine sc@ { cont ->
assert { _state.value !is CancellableContinuationImpl<*> }
// 通过CAS的方式,将当前的状态修改为挂起,并返回
if (_state.compareAndSet(NONE, cont)) return@sc
// 走到这里代表状态修改失败,说明又发射了新数据,当前的状态被修改为PENDING
assert { _state.value === PENDING }
// 唤起订阅者续体的执行
cont.resume(Unit)
}

3.数据的接收


    当调用StateFlow类型对象的collect方法,会触发订阅过程,接收emit方法发送的数据,这部分在
StateFlowImpl中实现,代码如下:


override suspend fun collect(collector: FlowCollector<T>) {
// 为当前的订阅者分配一个StateFlowSlot类型的对象
val slot = allocateSlot()
try {
// 如果collector类型为SubscribedFlowCollector,
// 说明订阅者监听了订阅过程的启动,则先回调
if (collector is SubscribedFlowCollector) collector.onSubscription()
// 获取订阅者所在的协程
val collectorJob = currentCoroutineContext()[Job]
// 局部变量,保存上一次发射的数据,初始值为null
var oldState: Any? = null
// 死循环
while (true) {
// 获取当前的数据
val newState = _state.value
// 判断订阅者所在协程是否是存活的,如果不是则抛出异常
collectorJob?.ensureActive()
// 如果订阅者是第一次处理数据或者当前数据与上一次数据不同
if (oldState == null || oldState != newState) {
// 将数据发送给下游
collector.emit(NULL.unbox(newState))
// 保存当前发射数据到局部变量
oldState = newState
}

// 修改状态,如果之前不是PENGDING状态
if (!slot.takePending()) {
// 则挂起等待新数据更新
slot.awaitPending()
}
}
} finally {
// 释放已分配的StateFlowSlot类型的对象
freeSlot(slot)
}
}

    在上述代码中,假设当前订阅者处于PENGDING状态,并在处理数据后,通过takePending方法,将自身状态修改为NONE,由于之前为PENGDING状态,因此不会执行awaitPending方法进行挂起。因此进行了第二次循环,而在第二次调用takePending方法之前,如果数据没有更新,则订阅者将一直处于NONE状态,当再次调用takePending方法时,会调用awaitPending方法,将订阅者所在协程挂起。


4.数据的发射


    在StateFlowImpl类中,当需要发射数据时,可以调用emit方法、tryEmit方法、compareAndSet方法,代码如下:


override fun tryEmit(value: T): Boolean {
this.value = value
return true
}

override suspend fun emit(value: T) {
this.value = value
}

override fun compareAndSet(expect: T, update: T): Boolean =
updateState(expect ?: NULL, update ?: NULL)

    compareAndSet方法内部调用updateState方法对数据进行更新,而emit方法与tryEmit方法内部通过value属性对数据进行更新,代码如下:


@Suppress("UNCHECKED_CAST")
public override var value: T
// 拆箱
get() = NULL.unbox(_state.value)
// 更新数据
set(value) { updateState(null, value ?: NULL) }

// 拆箱操作
@Suppress("UNCHECKED_CAST", "NOTHING_TO_INLINE")
inline fun <T> unbox(value: Any?): T = if (value === this) null as T else value as T

    可以发现,无论是通过emit方法、tryEmit方法还是compareAndSet方法,最终都是通过updateState方法实现数据的更新,代码如下:


// sequence是一个全局变量,当新的数据更新时,sequence会发生变化
// 当sequence为奇数时,表示当前数据正在更新
private var sequence = 0

// CAS方式更新当前数据的值
private fun updateState(expectedState: Any?, newState: Any): Boolean {
var curSequence = 0
// 获取所有的订阅者
var curSlots: Array<StateFlowSlot?>? = this.slots
// 加锁
synchronized(this) {
// 获取当前数据的值
val oldState = _state.value
// 如果期待数据不为空,同时当前数据不等于期待数据,则返回false
if (expectedState != null && oldState != expectedState) return false
// 如果新数据与老数据相同,即前后数据没有发生变化,则直接返回true
if (oldState == newState) return true

// 更新当前数据
_state.value = newState
// 获取全局变量
curSequence = sequence
// 如果为偶数,说明updateState方法没有被其他协程调用,没有并发
if (curSequence and 1 == 0) {
// 自增加1,表示当前正在更新数据
curSequence++
// 将新值保存到全局变量中
sequence = curSequence
} else { // 如果为奇数,说明updateState方法正在被其他协程调用,处于并发中
// 加2后不改变奇偶性,只是表示当前数据发生了变化
sequence = curSequence + 2
// 返回true
return true
}
// 获取当前所有的订阅者
curSlots = slots
}

// 走到这里,说明上面不是并发调用updateState方法的情况

// 循环,通知订阅者
while (true) {
// 遍历,修改订阅者的状态,通知订阅者
curSlots?.forEach {
it?.makePending()
}
// 加锁,判断在通知订阅者的过程中,数据是否又被更新了
synchronized(this) {
// 如果数据没有被更新
if (sequence == curSequence) {
// 加1,让sequence变成偶数,表示更新完毕
sequence = curSequence + 1
// 返回true
return true
}
// 如果数据有被更新,则获取sequence和订阅者
// 再次循环
curSequence = sequence
curSlots = slots
}
}
}

5.新订阅者获取缓存数据


    当新订阅者出现时,StateFlow会将当前最新的数据发送给订阅者。可以通过调用StateFlowImpl类重写的常量replayCache获取当前最新的数据,代码如下:


override val replayCache: List<T>
get() = listOf(value)

    在StateFlow中,清除replayCache是无效的,因为StateFlow中必须持有一个数据,因此调用
resetReplayCache方法会抛出异常,代码如下:


@Suppress("UNCHECKED_CAST")
override fun resetReplayCache() {
throw UnsupportedOperationException("MutableStateFlow.resetReplayCache is not supported")
}

6.热流的融合


    SharedFlowImpl类实现了FusibleFlow接口,重写了其中的fuse方法,代码如下:


// 内部调用了fuseStateFlow方法
override fun fuse(context: CoroutineContext, capacity: Int, onBufferOverflow: BufferOverflow) =
fuseStateFlow(context, capacity, onBufferOverflow)

...

internal fun <T> StateFlow<T>.fuseStateFlow(
context: CoroutineContext,
capacity: Int,
onBufferOverflow: BufferOverflow
): Flow<T> {
assert { capacity != Channel.CONFLATED }
// 如果容量为0、1、BUFFERED,同时溢出策略为DROP_OLDEST
if ((capacity in 0..1 || capacity == Channel.BUFFERED) && onBufferOverflow == BufferOverflow.DROP_OLDEST) {
// 返回自身
return this
}
// 调用fuseSharedFlow方法
return fuseSharedFlow(context, capacity, onBufferOverflow)
}

7.只读热流


    调用MutableStateFlow方法,可以得到一个类型为MutableStateFlow的对象。通过这个对象,我们可以调用它的collect方法来订阅接收,也可以调用它的emit方法来发射数据。但大多数的时候,我们需要统一数据的发射过程,因此需要对外暴露一个只可以调用collect方法订阅而不能调用emit方法发射的对象,而不是直接暴露MutableStateFlow类型的对象。


    根据上面代码的介绍,订阅的过程实际上是对数据的获取,而发射的过程实际上是数据的修改,因此如果一个流只能调用collect方法而不能调用emit方法,这种流这是一种只读流。


    事实上,在Kotlin协程:StateFlow的设计与使用分析接口的时候可以发现,MutableStateFlow接口继承了MutableSharedFlow接口,MutableSharedFlow接口继承了FlowCollector接口,emit方法定义在FlowCollector中。StateFlow接口继承了Flow接口,collect方法定义在Flow接口中。因此只要将MutableStateFlow接口指向的对象转换为StateFlow接口指向的对象就可以将读写流转换为只读流。


    在代码中,对MutableStateFlow类型的对象调用asStateFlow方法恰好可以实现将读写流转换为只读流,代码如下:


// 该方法调用了ReadonlyStateFlow方法,返回一个类型为StateFlow的对象
public fun <T> MutableStateFlow<T>.asStateFlow(): StateFlow<T> =
// 传入当前的MutableStateFlow类型的对象
ReadonlyStateFlow(this)

// 实现了FusibleFlow接口,
// 实现了StateFlow接口,并且使用上一步传入的MutableStateFlow类型的对象作为代理
private class ReadonlyStateFlow<T>(
flow: StateFlow<T>
) : StateFlow<T> by flow, CancellableFlow<T>, FusibleFlow<T> {
override fun fuse(context: CoroutineContext, capacity: Int, onBufferOverflow: BufferOverflow) =
// 用于流融合,也是通过fuseStateFlow方法实现
fuseStateFlow(context, capacity, onBufferOverflow)
}

作者:李萧蝶
链接:https://juejin.cn/post/7147236984963432456
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

Kotlin协程:StateFlow的设计与使用

一.StateFlow的设计     StateFlow是一种单数据更新的热流,通过emit方法更新StateFlow的数据,通过value属性可以获取当前的数据。在StateFlow中,核心接口的继承关系如下图所示: ...
继续阅读 »

一.StateFlow的设计


    StateFlow是一种单数据更新的热流,通过emit方法更新StateFlow的数据,通过value属性可以获取当前的数据。在StateFlow中,核心接口的继承关系如下图所示:
image.png


1.StateFlow接口


    StateFlow接口继承自SharedFlow接口,代码如下:


public interface StateFlow<out T> : SharedFlow<T> {
// 当前的数据
public val value: T
}



  • 订阅过程:在StateFlow中,每个FlowCollecter类型的对象都被称为订阅者。调用StateFlow类型对象的collect方法会触发订阅。正常情况下,订阅不会自动结束,但订阅者可以取消订阅,当订阅者所在的协程被取消时,订阅过程就会取消。




  • 冷流转换热流:对于一个冷流,可以通过调用stateIn方法,转换为一个单数据更新的热流。




  • 相等判定:在StateFlow中,通过Any#equals方法来判断前后两个数据是否相等。当前后两个数据相等时,数据不会被更新,订阅者也不会处理。




  • 数据缓存:StateFlow必须要有一个初始值。当新订阅者出现时,StateFlow会将最新的数据发射给订阅者。StateFlow只保留最后发射的数据,除此之外不会缓存任何其他的数据。同时,StateFlow不支持resetReplayCache方法。




  • StateFlow并发: StateFlow中所有的方法都是线程安全的,并且可以在多协程并发的场景中使用且不必额外加锁。




  • 操作符使用:对StateFlow使用flowOn操作符、conflate操作符、参数为CONFLATED或RENDEZVOUS的buffer操作符、cancellable操作符是无效的。




  • 使用场景:使用StateFlow作为数据模型,可以表示任何状态。




  • StateFlow与SharedFlow的区别:StateFlow是SharedFlow的一种特定方向的、高性能的、高效的实现,广泛的用于单状态变化的场景,所有与SharedFlow相关基本规则、约束、操作符都适用于StateFlow。当使用如下的参数创建SharedFlow对象,并对其使用distinctUntilChanged操作符,可以得到一个与StateFlow行为相同的SharedFlow对象:




// StateFlow
val stateFlow = MutableStateFlow(initialValue)

// 与StateFlow行为相同的SharedFlow
// 注意参数
val sharedFlow = MutableSharedFlow(
replay = 1,
extraBufferCapacity = 0,
onBufferOverflow = BufferOverflow.DROP_OLDEST)

// 设置初始值
sharedFlow.tryEmit(initialValue)

// distinctUntilChanged方法,只有当前后发射的两个数据不同时才会将数据向下游发射
val state = sharedFlow.distinctUntilChanged()


  • StateFlow与ConflatedBroadcastChannel的区别:从概念上讲,StateFlow与ConflatedBroadcastChannel很相似,但二者也有很大的差别,推荐使用StateFlow,StateFlow设计的目的就是要在未来替代ConflatedBroadcastChannel:

    • StateFlow更简单,不需要实现一堆与Channel相关的接口。

    • StateFlow始终持有一个数据,并且无论在任何时间都可以安全的通过value属性获取。

    • StateFlow清楚地划分了只读的StateFlow和可读可写的StateFlow。

    • StateFlow对前后数据的比较是与distinctUntilChanged操作符类似的,而ConflatedBroadcastChannel对数据进行相等比较是基于标识引用。

    • StateFlow不能关闭,也不能表示失败,因此如果需要,所有的错误与完成信号都应该具体化。




2. MutableStateFlow接口


    MutableStateFlow接口继承自MutableSharedFlow接口与StateFlow接口,并在此基础上定义了一个新方法compareAndSet,代码如下:


public interface MutableStateFlow<T> : StateFlow<T>, MutableSharedFlow<T> {
// 当前数据
public override var value: T

// 通过CAS的方式,更新value
// 如果except与value相等,则将value更新为update,并返回true
// 如果except与value不相等,不做任何操作,直接返回false
// 如果except、value、update同时相等,不做任何操作,直接返回true
public fun compareAndSet(expect: T, update: T): Boolean
}

二.StateFlow的使用


1.MutableStateFlow方法


    在协程中,可以通过调用MutableStateFlow方法创建一个MutableStateFlow接口指向的对象,代码如下:


public fun <T> MutableStateFlow(value: T): MutableStateFlow<T> {
...
}

    通过MutableStateFlow方法可以创建一个类型为MutableStateFlow的对象,需要提供一个参数value,作为初始值。


    在并发场景下调用emit方法时,会使StateFlow的数据快速更新,对于处理数据慢的订阅者,将会跳过这些快速更新的数据,但当订阅者需要处理数据时,获取的一定是最新更新的数据。


2.使用示例


    代码如下:


private suspend fun test() {
// 创建一个热流,初始值为1
val flow = MutableStateFlow(1)

// 将MutableStateFlow对象转换为StateFlow对象
// StateFlow对象不能调用emit方法,因此只能用于接收
val onlyReadFlow = flow.asStateFlow()

// 接收者1
// 启动一个新的协程
GlobalScope.launch {
// 触发并处理接收的数据
onlyReadFlow.collect {
Log.d("liduozuishuai", "test1: $it")
}
}

// 接收者2
// 启动一个新协程
GlobalScope.launch {
// 订阅监听,当collect方法触发订阅时,会首先会调onSubscription方法
onlyReadFlow.onSubscription {
Log.d("liduozuishuai", "test2: ")
// 发射数据:2
// 向下游发射数据:2,其他接收者收不到
emit(2)
}.onEach {
// 处理接收的数据
Log.d("liduozuishuai", "test2: $it")
}.collect()
}

// 发送数据:3,多次发送
GlobalScope.launch {
flow.emit(3)
flow.emit(3)
flow.compareAndSet(3, 3)
}
}

    对于上面的示例,接收者1会依次打印出:1、3,接收者2会依次打印出2、3。接收者2由于在处理onSubscription方法发射的数据2时,MutableStateFlow对象内部的数据1变成了数据3,因此在处理完数据2后,直接处理数据3。


作者:李萧蝶
链接:https://juejin.cn/post/7147226015943622687
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

Flutter 工程化框架选择 — 搞定 UI 生产力

这是 《Flutter 工程化框架选择》 系列的第二篇 ,就像之前说的,这个系列只是单纯告诉你,创建一个 Flutter 工程,或者说搭建一个 Flutter 工程脚手架,应该如何快速选择适合自己的功能模块,或者说这是一个指引系列,所以比较适合新手同学。 本篇...
继续阅读 »

这是 《Flutter 工程化框架选择》 系列的第二篇 ,就像之前说的,这个系列只是单纯告诉你,创建一个 Flutter 工程,或者说搭建一个 Flutter 工程脚手架,应该如何快速选择适合自己的功能模块,或者说这是一个指引系列,所以比较适合新手同学。


本篇主要介绍 UI 相关的,但是完全单纯介绍 UI 好像又有点水,那就是加一些小知识来吸吸水分吧


做为前端开发,我们的大部分职责就是开发 UI ,但是如果有人帮我们提前把 UI 做好,那岂不美哉?事实上很多时候 UI 确实是可以模版化,而前端领域也一直是这样,例如 Ant DesignElement-UI 等 ,那 Flutter 上是否也有这样的支持?


答案肯定是有的,但是在介绍它们之前,我们先聊一个 Flutter UI 的问题:嵌套



为了不太水,我们前言聊技术,后半部分推荐项目。



前言- UI 嵌套


谈到 Flutter 肯定就有人说嵌套,是的, Flutter 本身就是通过直接嵌套 Widget 来渲染 UI , 所以大家可能就会吐槽类似下面的代码,虽然这段代码没有意义,但是这里我们要先思考两个问题:



  • Flutter 怕不怕 Widget 嵌套影响性能

  • Flutter 有没有办法解决嵌套



首先第一点就是,Flutter 一般情况下不怕嵌套影响性能,因为 “众所周知” 的原因,Flutter 里的 Widget 并不是真正的控件,我更愿意说 Widget 是配置文件,真正的绘制和布局对象是它背后的 RenderObejct 等相关逻辑



嵌套层级看起来很多的原因,是因为 Widget 颗粒度太细。



当然这个还要看你嵌套的 Widget 做了什么?或者说是嵌套的 WidgetRenderObject 做了什么,例如:



  • PaddingRenderPadding 就是在 layout 时多了一个 SizechildParentData.offset 计算

  • ColoredBox_RenderColoredBox 就是多一句 drawRect

  • AlignRenderPositionedBox 就是多计算一个 childParentData.offset


所以这些 Widget 的颗粒度很细,但是也很轻,我们直接用的时候可能会一层一层嵌套,看起来不美观,但是实际渲染时对性能影响不大。



当然,并不是所有的 Widget 都很轻不怕嵌套,例如 ClipTransformOpacity 等,如果涉及到 pushLayer 等操作时,在需要做图层合成的时候,那确实对性能影响还是比较大的。



那第二个问题,如何解决嵌套?这时候你就需要 “配置模版” ,通过封装来优化代码结构


“配置模版”是什么意思?举个例子 : Container 应该用过吧? Container 其实就是官方给大家准备的 “模版” ,它本身只是一个 StatelessWidget ,也就是一个没有 RenderObjectWidget ,它靠的就是把各种功能的 Widget 组合起来使用,如下图就是使用 Container 的对比情况。










所以在使用 Flutter 构建 UI 时,就可以谈及到两个点:



  • Widget 是配置文件,它一般很轻,不怕嵌套,真正绘制渲染的是它背后的 RenderObject

  • 通过各种 UI 配置模版来解决嵌套,特别是抽象出适合自己业务逻辑的 UI 模版


举个例子,如下方的第三方开源布局包 dashboard ,在这种复杂的 UI 布局上难道就靠直接一级一级嵌套 ColumnRow 来解决?答案肯定不是!










dashboard 的是通过 Stack + Positioned 组成模版,在手势移动时计算,通过 AnimatedBuilder 实现动画偏移,自动计算控件位置。



其实也可以直接用 AnimatedPositioned ,具体可见 《Flutter 小技巧之有趣的动画技巧》



所以可以看到, Flutter 里你其实可以不那么嵌套,具体还是看你的封装方式,除了这样,还有就是直接在 RenderObject 上进行自定义布局,比如下方这两个例子:















cloudcustom_multi_render
image-20220922120414245

你说上面的布局用 Stack + Positioned 的模式能不能做?肯定是可以,但是在 RenderObject 层实现不是更优雅吗?把脏活累活写在 RenderObject , 通过 Widget 提供配置接口,这样就不会一上来就向用户露 “底裤” 不是么



所以,把眼界打开,不要什么都盯着 Widget 嵌套,往 RenderObject 层面探索,你会发现 Flutter 其实不像表面那么浮躁,再不济来尝试下 CustomMultiChildLayout ,它也可以帮助你解决一些复杂布局下的嵌套问题。



当然,还有一些项目另辟蹊径,比如 niku ,这个项目通过 typedef 和抽象拓展,利用语法对官方控件进行二次封装,实现创建了一个 “非正道” 的 UI 配置效果,具体如下图所示,喜不喜欢就看个人爱好了,但是它确实一定程度解决了嵌套可视化的问题。




作者是个二次元,但是看地址他应该是泰国哥们



当然,我们这一期的关键是提高 UI 生产力,单说源码实现就没劲了,所以重点让我们看后半部分。


UI 套件


在前端领域,使用统一的 UI 套件可以加快开发的节奏,减少开发和设计之间的摩擦,而且风格统一。一般情况下,在企业内部都是在不知不觉中沉淀下来各种组件,最后形成组件池,从而落地成 UI 套件。


比如贝壳的 bruno ,我愿意称它为 Flutter 界的 Element-UI ,目前已经支持到 Flutter 3 ,作为少有国内大厂维护的 Flutter UI 项目,甚至它还提供了 sketch 设计指引设计物料下载

















brunogetwidgetfsuper

当然,除了 bruno 之后,像 getwidgetfsuper 也提供了日常开发中常用的 UI 套件,虽然风格风格上可能并没有 bruno 统一,但是还是可以在一定程度提高开发的生产力。



事实上对于个人开发者来说,这种套件可以解决很多设计上的问题。



另外聊到 Flutter UI 套件就要一定要介绍国内的 fluttercandies 组织,fluttercandies 是由大佬们共同维护的一系列 Flutter 开源项目,记住,是大佬们,并且一直在持续更新:




举个例子,如果 flutter framework 短期不能解决的问题,那就大佬就会 cv 一份控件自己维护,这就是 fluttercandies 的节奏和优势。



PC


既然介绍 Flutter UI ,就不得不介绍 PC 相关的风格的 UI ,因为 Flutter 不只是 Android 和 iOS ,它还支持 Web 和 PC, 所以类似 PC 的 UI 风格也值得推荐,比如 ant_design_flutter 就是一个很有意思的项目

















fluent_uimacos_uiant_design_flutter

Responsive


那有的人可能就说,我想要一套代码适配多平台的屏幕尺寸行不行?答案肯定是可以的,下面这几个 package 就提供了不同屏幕尺寸下一套代码的动态适配方案,我个人可能会比较喜欢 ResponsiveFramework 。

















ResponsiveFrameworkresponsive_sizerflutter_adaptive_ui

Appbar


这类 Appbar 的实现其实是我被问过最多的,其实它的核心实现都是 Sliver ,严格意义上我觉得并不需要第三方库,自己用 Sliver 就可以实现,但是本着能不动手就不动手原则,也推荐几个库吧:

















draggable_homeextended_sliverscroll_app_bar


gsy_flutter_demo 里也提供了几种实现思路,其实并不复杂。



Drawer


可能有人会觉得,不会吧不会吧, Drawer 也需要第三方库?


还真有,因为有时候可能需要不一样的动画效果,另外这里的 sidebarx ,也和官方提供的 NavigationRail有异曲同工之妙,能在 UI 上适配多平台的操作习惯。

















sidebarxflutter_advanced_drawercurved_drawer

Tarbar


既然都说到 Drawer ,那 Tabbar 也提供几个花里胡哨的动画效果,主要是切换时的动画效果,另外 tab_container 可能算是比较有意思的库,用的 Path 来编绘背景动画效果。

















flutter-cupertino-tabbartab_indicator_stylertab_container

BottomBar


说到 Tabbar 相对应的还有 BottomBar 相关,这里也提供几个库,主要是动画效果很有趣,我个人还是挺喜欢这种曲线的动画效果。

















curved_navigation_barsalomon_bottom_barbubble_bottom_bar

指引


启动指引这个需求,正常情况下一个 PageView 就可以满足产品经理的场景,但是有时候可能会需要你来“亿”点点动画效果来增加 KPI,所示拿着也许就对你有用了,当然你也可以把它当作 PageView 动画来使用。

















concentric_transitionnice_introintro_views_flutter

角标


这个应该无需多言了,基本上 App 都会需要用到,这两个库基本覆盖了 90% 的场景















flutter_badgescorner_decoration

动画按键


这个可能一般情况下大家都不需要这么花里胡哨的效果,但是万一呢?Material 风格上这种交互还是挺多的,不过国内对 Material 确实不是很感冒。















flutter_animated_buttonprogress_state_button

头像


没想到吧?头像为什么还需要库?


其实就是下面的这个场景,相信这个场景可能大家都不会陌生,有社交需求的时候,经常会存在这样的 UI ,掘金沸点不也有类似 UI 么?

















avatar_stackoverflow_view

swipe 卡片


这个需求可能一般人不会需要,推荐它是因为我还记得几年的时候,收了 1000 给人做了这样的一个外包,就是做一个这样的控件。

















swipe_deckswipeable_card_stackappinio_swiper

bottom sheet


这其实更多是一个 Route 相关的动画效果,感觉好像国内也不常用到,但是之前确实有好几次咨询有没有类似的实现。















we_slidesliding_up_panel

时间轴 UI


这是我在群里被问过好多次的一个需求场景,我也不知道为什么那么多应用会需要用到这样的 UI ?不过这类需求自己从头实现确实会比较费事。















timeline_tiletimelines

好了,关于 Flutter UI 相关的内容推荐就到这里,本篇主要还是提供给大家如何理解 Flutter 的 UI 布局,并且尽可能去解决嵌套,同时提供一些有意思的第三方 package ,进一步提高大家开发 UI 的生产力


最后,如果你还有什么关于 Flutter 工程或者框架的疑问,欢迎留言评论,也许新的素材又有了~


作者:恋猫de小郭
链接:https://juejin.cn/post/7147437014026043399
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

南京信息工程大学改立元宇宙工程系,网友:我很好奇课程是啥

继 Facebook 改名为 Meta 后,南京信息工程大学信息工程系更名为「元宇宙工程系」。最近两年,元宇宙(metaverse)可谓爆火,似乎整个世界都充斥着元宇宙的概念。一时之间,仿佛人人都在谈元宇宙。更有扎克伯格将 Facebook 改名为 Meta,...
继续阅读 »

继 Facebook 改名为 Meta 后,南京信息工程大学信息工程系更名为「元宇宙工程系」。

最近两年,元宇宙(metaverse)可谓爆火,似乎整个世界都充斥着元宇宙的概念。一时之间,仿佛人人都在谈元宇宙。

更有扎克伯格将 Facebook 改名为 Meta,全力来研发元宇宙,他认为这是人类的一个发展方向。其他科技巨头也砸入重金,抢占先机。

不仅科技大厂开始押宝元宇宙,高校机构也开始向这一方向发力。

9 月 24 日,据现代快报从南京信息工程大学获悉,南京信息工程大学人工智能学院(未来技术学院)信息工程系现更名为元宇宙工程系。

文件显示,「经学院党政联席会议研究决定并报学校批准,我院信息工程系更名为元宇宙工程系。」


据了解,人工智能学院的元宇宙工程系是国内高校第一个以元宇宙命名的院系。

此前,南京信息工程大学就开始探索元宇宙相关内容。今年 7 月,该校就举办过元宇宙与智慧教育国际论坛。

根据学校官网介绍,南京信息工程大学(NUIST,简称南信大)是国家双一流建设高校,始建于 1960 年(前身为南京大学气象学院),1963 年独立建校为南京气象学院,1978 年列入全国重点大学,2000 年划转江苏省人民政府主管,2004 年更名为南京信息工程大学。


而南京信息工程大学人工智能学院组建于 2019 年 6 月,由电子与信息工程学院信息工程专业整合优化并新增人工智能本科专业组合而成,是学校重点建设的特色学院之一。学院历史可以追溯到原南京气象学院计算机与信息工程系于 1997 年开设的信息工程专业。2021 年 7 月学校成立人工智能学院(未来技术学院),至今学院成立了一年左右的时间。

该学院的人工智能专业是全国首批 35 个获批的人工智能本科专业之一。目前学院已形成三个研究团队和方向:元宇宙研究院、智慧气象研究院和智慧医疗研究院。由此看来,南京信息工程大学信息工程系改名元宇宙系,也不算奇怪。

对于这一事件,网友各持不同的观点。有人对这一做法表示鼓励,并表示「南京信息工程大学一直和元宇宙有着亲密关系,说走在元宇宙研究的前列也不为过。」


还有网友开始询问元宇宙相关课程会教啥,已经在求课件了。


不过更多网友表示不赞同,认为是在蹭热度,整些花里胡哨的。如果「换汤不换药」,学的内容不变的话,改个名字似乎意义也不大。

如果后续相关课件以及配套设施能跟上的话,此次「元宇宙工程系」的更名对国内高校布局元宇宙不失为一种探索。

对于南京信息工程大学给院系改名这一事件,你怎么看,欢迎评论区留言。

参考链接:
https://www.nuist.edu.cn/main.htm
https://www.zhihu.com/question/555284488

来源:机器之心

收起阅读 »

做 Android 你后悔了吗

我是个后知后觉的人。糊里糊涂地入场2011 年 12 月份,学校已经没有课,让我们出去找工作,那个时候我是迷茫的,各种海投,不知道如何找工作,更不知道自己职场方向是什么,学校学的是 JavaEE,投的主要 JavaEE,简历上有提学过 Android,糊里糊涂...
继续阅读 »

我是个后知后觉的人。

糊里糊涂地入场

2011 年 12 月份,学校已经没有课,让我们出去找工作,那个时候我是迷茫的,各种海投,不知道如何找工作,更不知道自己职场方向是什么,学校学的是 JavaEE,投的主要 JavaEE,简历上有提学过 Android,糊里糊涂接到 Android 岗位电话,糊里糊涂拿到了 offer,糊里糊涂开始做了 Android,其实那会儿我还不知道有安卓手机,更对 Android 没概念。

想着为什么不是做后端

刚刚工作,因为什么都不懂,我又很急,希望马上就会,上班写代码,下班也在写,而且项目不少,加班家常便饭,我觉得工作之初就应该这样,项目中才能成长的更快。业余时间泡安卓巴士和 eoe,混了版主,相见恨晚世界同性交流的网站 GitHub 也开源了几个库。随着我的技术日渐成长,我能单挡一面,开始一个人干一个项目。

做 Android 时间久了,发现 Android 更多是写业务,画页面,调用接口,我这个人是有很强{忧患意识|瞎担忧},Android 这样被后端“牵制着”,为什么不是做后端,掌握更多的话语权,但没等到做后端,被 Android 内部瓦解了,Android 迎来了跨平台,16 年声音尤为强烈,“Android 没人要了”。

16 年我换工作,面试时在问我是做原生的 Android 吗?我一脸懵,事后才知道跨平台已经很火了。

做系统,为什么要转?

18 年 Android 应用我感觉做到头,需要做点改变,想往系统层开发走走,正好朋友他们在招系统开发,我就想一试,没想到转过去当初是如此之难。

Framework 我相当于从零开始,就是感觉自己菜,自信心也几乎碎了一地,甚至自卑了起来,我是不能接受一个工作 6 年的干不过应届生,18 年,部门有些不稳定,我一年内做了性能优化、系统开发、通讯,就是那种刚有点感觉,就换模块了,干的活应届生也能干,特失败的感觉,这一年没什么技术积累。

情绪低落时想着为什么要转行,以前做应用信手拈来,现在却跟应届生菜鸟互啄,甚至还干不过他们!

幸好 19 年部门开始细分模式,我做了显示服务,之前做的应用没白费,我的优势逐渐显示出来,职场也逐渐起色,也晋级了成了公司的骨干。

研发思维,转岗?

随着年纪越来越大,感觉一直做开发不是个事,内心也一直有个声音,要转管理,我一直在等这个机会。

是的,就在今年 3 月份,我竞聘成功了成了经理,我这个时间点很尴尬,金三银四,跳槽高峰期,我首要任务是留着组员及招人,是的,招人啦,招人啦,我组招人,我们是无锡华勤。

说到无锡,无锡是个好地方,如果您想选择在江苏发展,首选无锡,相对南京和苏州,无锡还是更加宜居买房的。

无锡也是个旅游的好去处,很多湿地公园,如长广溪国家湿地公园、蠡湖国家湿地公园、贡湖湾湿地公园等都是免费的,可以工作之余带着家人走走,有鼋头渚、梅园、蠡园、锡惠名胜区等一张园林卡(198 元一年)就可以畅玩,还有拈花湾,风格仿古,以禅意为主题的小镇;灵山胜境,中国最为完整、也是唯一集中展示释迦牟尼成就的佛教文化主题园区,是个感受佛教文化的好地方;大规模古建筑群,三国水浒城;如果时间够充分,无锡范围内的宜兴张公洞、善卷洞和龙背山森林公园,江阴的华西村也不妨一同造访,还有很多很多,原谅我词汇表达有限。

说到华勤,总部在上海,有上海、无锡、西安、南昌、东莞五大研发中心,南昌、东莞两大国内制造基地,印度、印尼、越南三大海外制造基地,做智能手机、平板、电脑、智能穿戴等。无锡华勤坐落在无锡市新吴区清源路 28 号,有自己的园区,一期已于 20 年 8 月投入使用,二期正在建。

说回我这个组,有显示服务、显示驱动(LCD)、TP、编解码四个模块,显示服务和编解码是 Framework 开发, LCD 和 TP 是驱动开发,目前我需要招 LCD/TP,和显示服务,说下岗位要求:

LCD/TP:
1.电子、计算机及相关专业,英语 CET4 及以上。
2.熟练掌握 C/C++编程,熟悉基本硬件电路原理,了解 Linux 内核、底层驱动开发,有一年以上相关开发经验。
3.思维清晰、敏捷,良好的学习能力,良好的沟通能力和团队协作精神。

显示服务:
1.计算机机相关理工类专业。
2.熟练掌握 Java/C++编程,有一年以上 Android 应用开发经验。
3.思维清晰、敏捷,良好的学习能力,良好的沟通能力和团队协作精神。

Base 无锡,薪资 10-15K*15 薪,还有餐补,交通补,延时补助,弹性上下班,员工旅游等常规福利,有意向跳槽加我微信(微信号:wuxiaolongtongxue)详聊,加好友请备注“跳槽”。

结语

做 Android 我后悔了吗?其实没什么后悔的,不管做什么只是一直谋生的手段罢了。做 Android 应用时,觉得应用最牛,做 Android 系统开发,觉得比应用好很多,殊不知还有 Android 驱动开发,还有硬件工程师...哎,我的格局啊。

但我必须要感谢 Android,我一没什么好的学历,二没有名企的经历,还在二线城市,是 Android 给了一张职业入场券。


作者:吴小龙同學
来源:juejin.cn/post/7077172809201352741

收起阅读 »

外包仔的自我救赎

本人96年后端Javaer一枚,现在在某知名大厂做外包仔(一入外包深似海,从此自研是路人)。为什么做外包仔?开始是没得选毕业的第三年,通过培训班转行Java,包装了两年经验。非科班出身又是半路出家,当时也不懂外包的概念,于是就糊里糊涂进了外包公司。第一家公司只...
继续阅读 »
本人96年后端Javaer一枚,现在在某知名大厂做外包仔(一入外包深似海,从此自研是路人)。

为什么做外包仔?

开始是没得选

毕业的第三年,通过培训班转行Java,包装了两年经验。非科班出身又是半路出家,当时也不懂外包的概念,于是就糊里糊涂进了外包公司。第一家公司只干了三个多月就跑路了,一方面是工资太低(8K),另一方面是技术比较老旧(SSH)。第二家公司也是外包,但是项目还不错(spring cloud),薪资也可以接受(12K)。

后来是给的多

做开发工作的第二年,跳槽时本来想着找一家自研公司,但是没忍住外包公司开的价格,一时脑热又进了外包,也就是现在这家大厂外包。薪资比较满意(18K),项目也很不错(toC业务,各种技术都有涉及)。

下定决心跳出外包

为什么要离开

干过外包的小伙伴们多多少少会有一些低人一等的感觉,说实话笔者自己也有。就感觉你虽然在大厂,但你是这里身份最低的存在,很多东西是需要权限才能接触到的。再者就是没有归属感,没有年会、没有团建、甚至不知道自己公司领导叫什么(只跟甲方主管和外包公司交付经理有接触)。

潜心修炼技术

在最近这个项目里确实学到了很多生产经验,自己写的接口也确实发生过线上故障,不再是单单的CRUD,也会参与一些接口性能的优化。对业务有了一定的的理解,技术上也有了一定的提升,大厂的开发流程、开发规范确实比较健全。

背诵八股文

三月份开始就在为跳槽做准备,先后学习了并发编程、spring源码、Mysql优化、JVM优化、RocketMQ以及分布式相关的内容(分布式缓存、分布式事务、分布式锁、分布式ID等)。学到后面居然又把前面的忘了

大环境行情和现状

大范围裁员

今年从金三银四开始,各大互联网公司就都在裁员,直到现在还有公司在裁员,说是互联网的寒冬也不为过。笔者所在的厂也是裁员的重灾区,包括笔者自己(做外包都会被优化,说是压缩预算)也遭重了,但是外包公司给换了另外一个项目组(从北京换到了杭州)。

招聘网站行情

笔者八月份先在北京投了一波简历(自研公司,外包不考虑了),三十多家公司只有一家公司给了回应(做了一道算法笔试题,然后说笔者占用内存太多就没有后续了),九月中旬又在杭州投了一波简历(也是只投自研),六十多家公司回复也是寥寥无几,甚至没约到面试(有大把的外包私聊在下,是被打上外包仔的标签了吗)。

如何度过这个寒冬

继续努力

工作之余(摸鱼的时候),笔者仍然坚持学习,今天不学习,明天变垃圾。虽然身在外包,但是笔者仍有一颗向往自研的心,仍然想把自己学到的技术运用到实际生产中(现在项目用到的技术都是甲方说了算,当然我也会思考哪些场景适合哪些技术)。

千万不要辞职

现在的项目组做的是内部业务,并发几乎没有,但是业务相对复杂。笔者只能继续狗着(简历还是接着投,期望降低一些),希望互联网的寒冬早日结束,希望笔者和正在找工作的小伙伴们早日找到心仪的公司(respect)。


作者:我一定有办法
来源:https://juejin.cn/post/7146220688800481294

收起阅读 »

图解常见排序算法

1. 冒泡排序 冒泡排序属于交换排序的一种,从数组的第一个角标开始逐个与后面的元素进行比较,如果小于就将其置换 首先取出第一个元素,与后面的元素挨个比较,如果大于后面的某个元素就将两个元素位置互换,然后继续比较直到最后一个。第二轮从第二个元素开始比较、第三轮...
继续阅读 »

1. 冒泡排序


冒泡排序属于交换排序的一种,从数组的第一个角标开始逐个与后面的元素进行比较,如果小于就将其置换


冒泡.webp


首先取出第一个元素,与后面的元素挨个比较,如果大于后面的某个元素就将两个元素位置互换,然后继续比较直到最后一个。第二轮从第二个元素开始比较、第三轮从第三个以此类推,最后一轮比较完毕就会形成一个有序数组


        int[] arr = {5,1,2,9,7};
//轮数
for (int i=0;i<arr.length-1;i++){
//从第i个元素开始比较
for (int j = i+1;j<arr.length;j++){
if(arr[i]>arr[j]){
//交换位置
int temp = arr[i];
arr[i] = arr[j];
arr[j] = temp;
}
}
System.out.println("第"+(i+1)+"轮:"+Arrays.toString(arr));
}
System.out.println(Arrays.toString(arr));

打印结果:


第1轮:[1, 5, 2, 9, 7]
第2轮:[1, 2, 5, 9, 7]
第3轮:[1, 2, 5, 9, 7]
第4轮:[1, 2, 5, 7, 9]
[1, 2, 5, 7, 9]

2. 快速排序


从数组中选取一个标准数,小于标准数的元素放在左边、大于标准数的元素放在右边,然后把分开的两个数组再进行以上操作,此步骤可通过递归来实现。


快速.webp


选择5为标准数进行分边,将1、2放在左边,7、9放在右边,通过递归将左右两个数组再次进行分边,当不能再分即数组块<2时跳出方法,以此类推最后会得出一个有序数组。代码部分:


public static void quickSort(int[] arr,int start,int end){
//递归结束条件
if(start>=end){
return;
}
int standard = arr[start];//选取第start个元素为标准数
int low = start;//低位指针
int high = end;//高位指针
//通过一个循环将小的数字分配到标准数左边、
//大的放在右边,标准数放在中间
//循环的结束条件为两个指针碰撞即low==high,
while (low<high){
//首先从高位开始找比标准数小的数字
while (low<high&&standard<=arr[high]){
//将高位角标+1继续比较
high--;
}
//找到比标准数小的数字放在low角标处,此时的low即start
arr[low] = arr[high];

//从低位开始找比标准数大的数字
while (low<high&&arr[low]<=standard){
//将低位指针+1继续比较
low++;
}
//找到比标准数大的数字放在high角标处
arr[high] = arr[low];
}
//能执行到这说明low==high,将标准值放在low/high角标中
arr[low] = standard;
System.out.println("start:"+start+"--end:"+end+"--"+Arrays.toString(arr));
//执行完以上步骤后就完成了第一轮数字分配,
//通过递归将分开的两个数组再次进行数组分配
quickSort(arr,start,low-1);//将左边数组进行数字分配
quickSort(arr,low+1,end);//将右边数组进行数字分配
}

执行如下代码:


 int[] arr = {5,1,7,9,2};
quickSort(arr,0,arr.length-1);
System.out.println("-------------");
System.out.println(Arrays.toString(arr));

打印结果


start:0--end:4--[2, 1, 5, 9, 7]
start:0--end:1--[1, 2, 5, 9, 7]
start:3--end:4--[1, 2, 5, 7, 9]
-------------
[1, 2, 5, 7, 9]

3. 直接插入排序


从第二个元素开始与第一个元素进行比较,如果小于第一个元素则交换位置。然后从第三个元素开始与第二个元素进行比较,如果小于第二个元素进行位置互换,再拿着第二个元素跟第一个元素比较,大于第一个元素就交换位置,以此类推


     int[] arr = {5,1,7,9,2};
for (int i=1;i<arr.length;i++){
//如果当前遍历数字小于前一个数字
if(arr[i]<arr[i-1]){
int temp = arr[i];//记录下来当前遍历的数字
int j;
//将temp与前面数字进行比较,
//如果小于前面数字将前一数字,
//就将当前数字设置成与前一数组相同
for (j = i-1;j>=0&&arr[j]>temp;j--){
arr[j+1] = arr[j];
}
//最后还要将temp放在j+1的位置
arr[j+1] = temp;
}
}
System.out.println(Arrays.toString(arr));

打印结果:


[1, 2, 5, 7, 9]

代码可能与上面的文字描述有些出入,但目的都是为了交换位置。


4. 希尔排序


首先获取到数组长度,将长度/2得到一个步长,举个例子来说明一下步长的作用,假如有一个长度为5的数组,那么步长就是2,将第4个元素和第2(4-步长)个元素进行比较,小于前面数字则交换位置,再将第2个元素与第0(2-步长)个元素比较,小于前面数字交换位置。然后再将第3个和第一个比较,以此类推,比较完一轮后将步长/2进行下一轮比较。


希尔.webp




  • 第一轮:将5、7、2和1、9进行比较得到第二轮

  • 第二轮:将2、1、5、9、7按步长为1进行比较



        int[] arr = {5,1,7,9,2};
//遍历步长,每遍历一轮步长除2,直到小于等于0跳出循环
for (int d = arr.length/2;d>0;d/=2){

//遍历每个元素
for (int i = d;i<arr.length;i++){
//遍历本步长组中的元素
for (int j=i-d;j>=0;j-=d ){
//将当前元素与加上步长的元素比对
//如果当前元素大就交换位置
if (arr[j]>arr[j+d]){
//交换位置
int temp = arr[j];
arr[j] = arr[j+d];
arr[j+d] = temp;
}
}
}
System.out.println("d:"+d+Arrays.toString(arr));
}
System.out.println(Arrays.toString(arr));

打印结果:


d:2[2, 1, 5, 9, 7]
d:1[1, 2, 5, 7, 9]
[1, 2, 5, 7, 9]

第一个for循环步长的轮数,第二个for循环从步长开始遍历后面每个元素,第三个for循环用于遍历一个步长组然后交换位置。


5. 简单选择排序


选择排序跟冒泡排序类似,从一个数字开始往后遍历,选出最小值并记录其角标然后第一位进行位置交换,再从第二个数字开始做以上操作以此类推


选择.webp


    int[] arr = {2,3,5,1};
for (int i=0;i<arr.length-1;i++){
int index = i;
for (int j=i+1;j<arr.length;j++){
//记录本轮最小值角标
if(arr[j]<arr[index]){
index = j;
}
}
//交换位置
if(i!=index) {
int temp = arr[i];
arr[i] = arr[index];
arr[index] = temp;
}
System.out.println("第"+(i+1)+"轮:"+Arrays.toString(arr));
}
System.out.println("----------------");
System.out.println(Arrays.toString(arr));

打印结果:


第1轮[1, 3, 5, 2]
第2轮[1, 2, 5, 3]
第3轮[1, 2, 3, 5]
----------------
[1, 2, 3, 5]

6. 归并排序


归并排序就是将一堆无序数字分成两部分,左右两边都保证有序,最后再将两边有序数字进行排序


归并.webp


通过递归的方式将数组拆分直到被拆分的数组长度<=1未知,原始数组可拆分为A和B,A数组又可拆分为C和D,D数组又可拆分为G和H,数组G和H长度都为1所以不能再往下进行拆分,因为数组G和H长度都为1所以可视为两个数组都是有序的,然后通过归并算法将G和H合并成一个有序数组,此时数组D就变成了[1,2],再通过归并算法将C和D合并成有序数组,此时A就变成了[1,2,5],依次类推最终就可以实现排序功能。


//归并算法就是将左右两边的两个有序数组归并成一个有序数组
public static void merge(int[] arr,int low,int middle,int high){
int[] temp = new int[high-low+1];//创建一个临时数组
int i = low;//第一个数组需要遍历的角标
int j = middle+1;//第二个数组需要遍历的角标
int index = 0;//记录临时数组的下表
//遍历两个数组,取出小的数字放入临时数组中
while (i<=middle&&j<=high){
//把小的数据放入临时数组中,小的一方角标+1
if(arr[i]<arr[j]){
temp[index] = arr[i];
i++;
}else {
temp[index] = arr[j];
j++;
}
//临时数组角标+1
index++;
}
//处理右边多余的数据
while (j<=high){
temp[index] = arr[j];
j++;
index++;
}
//处理左边多余的数据
while (i<=middle){
temp[index] = arr[i];
i++;
index++;
}

//将临时排好序的临时数组放入到原数组
for (int k=0;k<temp.length;k++){
arr[low+k] = temp[k];
}
}

重点说一下下面的两个取多余数据的代码,首先这两个while循环是互斥的,什么时候会执行这两个while循环呢?假如左边的所有数据都小于右边的第一个数据,此时会将左边数组全部放到临时数组中,当放入最后一个元素后左边数组的角标i已经>middle了,会跳出第一个while循环,但是右面的元素还没有放入到临时数组,所以要将右边多余的数字放入到临时数组。其他部分注释标的都很清楚就不一一叙述了,下面来看数组拆分的算法:


    public static void mergeSort(int[] arr,int low,int high){
//递归结束条件
if(high<=low){
return;
}
int middle = (high+low)/2;
//处理左边
mergeSort(arr,low,middle);
//处理右边
mergeSort(arr,middle+1,high);
//归并
merge(arr,low,middle,high);
}
...
//以下代码在main()方法中运行
int[] arr = {2,3,5,1,11,2,15};
mergeSort(arr,0,arr.length-1);
System.out.println(Arrays.toString(arr));

通过递归的方式拆分数组,然后结合上面写的归并算法进行排序。下面来看代印结果:


[1, 2, 2, 3, 5, 11, 15]

7. 基数排序


创建一个长度为10的二维数组,遍历无序数组,将个位数为0 - 9的放在二维数组的第0-9个位置,然后按顺序将元素取出,再将十位数为0 - 9的放在二维数组的第0-9个位置,然后再取出,以此类推最后会得到一个有序数组


基数.webp


首先创建一个二维数组也就是图中中间的那个数组,然后遍历需要排序的数组将个位数为0 - 9的元素放入到二维数组中0 - 9位置,然后再从前到后将元素逐个取出,这样第一轮就完成了,然后再进行下一轮,进行的轮数就是最大数的长度。


 //基数排序
public static void radixSort(int[] arr){
//存数组中最大的数,目的获取其位数
int max = Integer.MIN_VALUE;
for (int x:arr){
if(x>max){
max = x;
}
}
//最大值长度
int maxLength = (max+"").length();
//创建一个二维数组存储临时数据
int[][] temp = new int[10][arr.length ];
//创建一个数组,用来记录temp内层数组存储元素的个数
int[] count = new int[10];
//将数据放入二维数组中
for (int i =0,n=1;i<maxLength;i++,n*=10){
for (int j=0;j<arr.length;j++){
int number = arr[j]/n;
//将number放入指定数组的指定位置
temp[number][count[number]] = arr[j];
//将count数组中记录元素个数的元素+1
count[number]++;
}
//从二维数组中取数据
int index = 0;
for (int x=0;x<count.length;x++){
if(count[x]!=0){
for (int y=0;y<count[x];y++){
arr[index] = temp[x][y];
index++;
}
count[x] = 0;
}
}
}
}
...
//以下代码在main()方法中运行
int[] arr = {11,2,6,552,12,67,88,72,65,23,84,17};
radixSort(arr);
System.out.println(Arrays.toString(arr));



  • 首先遍历数组取出最大值,通过最大值确定轮数

  • 创建一个二维数组和一个存放二维数组每个角标中元素个数的数组

  • 将元素放入到二维数组中指定的位置

  • 从二维数组中逐个将元素取出



打印结果:


[2, 6, 11, 12, 17, 23, 65, 67, 72, 84, 88, 552]

作者:Bezier
链接:https://juejin.cn/post/7145772697367085069
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

Java 泛型知多少

你可能遇到过以下困惑,为什么在 java 中我们不能 new 一个泛型,而 C++ 却可以,如下这样 此种方法在 java 中直接通不过编译,而如果我们要实现同样的功能,只能通过显示的传入 class,然后通过 RTTI 方式来在运行时动态创建 public...
继续阅读 »

你可能遇到过以下困惑,为什么在 java 中我们不能 new 一个泛型,而 C++ 却可以,如下这样


1362430-3d0473c0398ff1c1.webp
此种方法在 java 中直接通不过编译,而如果我们要实现同样的功能,只能通过显示的传入 class,然后通过 RTTI 方式来在运行时动态创建


public class AnimalPlayground<T>  {
public T create(Class<T> t) {
try {
return t.newInstance();
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}

这个原因是因为 Java 的泛型其实是假泛型,他只在编译时进行了泛型校验,生成的字节码其实不存在泛型的概念,也就是所谓的泛型擦除。比如如下两段代码:


public class AnimalPlayground<T>  {
private T obj;
public void create(T t) {
this.obj = t;
}
}

public class AnimalPlayground {
private Object obj;
public void create(Object t) {
this.obj = t;
}
}

通过 javac 然后 javap 看他们的字节码,发现生成的字节码其实是一样的,没有包含特殊的泛型信息。


public void create(T);
descriptor: (Ljava/lang/Object;)V
flags: (0x0001) ACC_PUBLIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: aload_1
2: putfield #7 // Field obj:Ljava/lang/Object;
5: return

这一点解释了为什么我们无法对泛型进行 new 的操作,因为泛型进行了擦除,所以我们无法验证这个泛型是否有默认的构造函数,所以 Java 编译器干脆进行了编译时报错处理。因为泛型擦除的原因,所以以下等式可以成立


List<Integer> list1 = new ArrayList<>();
List<String> list2 = new ArrayList<>();
System.out.println(list1.getClass() == list2.getClass()); // true

而且我们也留意到,我们可以声明 List.class 而无法使用 List<Integer>.class,因为第二种本身无意义。那如何得到包含泛型的列表的类型呢,此时我们可以使用 ParameterizedType。此篇文章对 ParameterizedType 的用法讲解的比较详细。


协变和逆变


个人理解泛型的本质是在尽可能编程灵活的情况下,做到逻辑自洽,此时一门语言是否好用就取决于它的编译器的聪明程度。


比如我们声明一个 Animal 类,然后再声明一个 Dog 类继承自 Animal。此时按照我们直觉的推断,如果一个 Dog 是 Animal 的子类,那么一个 Dog 的列表是否是一个 Animal 列表的子类呢?很可惜,如果我们直接这样做直接编译器就会不通过:


1362430-4e53c15e13034c5e.webp


此时我们就需要引入协变的概念,字面意思就是可以协同实际类型来变化。在 Java 中 List 是支持协变的,可以使用以下写法:


ArrayList<? extends Animal> animals = new ArrayList<Dog>();

任何 Animal 子类的列表都可以赋值给:ArrayList<? extends Animal> 。但要注意在 Java 中协变的 List 是没法使用 add 去增加元素的。这是为啥呢?


因为协变类型可以被任何子类数组赋值,而由于 Java 的泛型擦除机制,我们是没办法在编译时及时发现这个列表被传入了其他子类,比如上面的 animals 如果可以使用 add,那么我们执行 animals.add(new Cat()) 是没法在编译时发现问题的,那就有违 Java 是一门类型安全语言的设定,所以 Java 中直接去掉了协变增加元素的功能。


协变 我们知道是跟随实际类型的父子关系而来,那逆变呢?按照字面意思理解就是和实际类型的父子关系反过来,比如同样的 ArrayList 逆变则可以使用如下表达


ArrayList<? super Animal> animals = new ArrayList<Animal>();

ArrayList<? super Animal> 这种表达是 Animal 子类的一个列表,只能接收一个 Animal 的列表。此种方法我们知道列表一定是一个 Animal 类的列表,所以我们可以随意的向其中增加元素


ArrayList<? super Animal> animals = new ArrayList<>();
animals.add(new Cat());
animals.add(new Dog());
animals.add(new Animal());

写在最后


C++ 中使用泛型是通过 template 来实现,你可以理解它只是一个模板,是无法单独编译。C++ 在编译的过程中遇到 template 则会使用真实的类型来替换模板中的泛型,然后新生成一段机器码。而 Java 的泛型类是可以单独编译的,编译完成后的字节码就是一个普通的类,在运行层面的使用就是把它当作一个普通类来使用的。理解这一点,应该能帮助你理解 Java 中泛型种种限制的原因。


作者:CPPAlien
链接:https://juejin.cn/post/7146080877552861220
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

为什么你学不会递归?谈谈我的经验

前言 大家好,我是小彭。 今天分享到计算机科学中一个基础又非常重要的概念 —— 递归。递归是计算机中特有的概念,你很难在现实世界中找到一个恰当的例子与之关联起来。因此,对于很多初学编程的人,一开始会很难理解。 那么,究竟什么是递归,我们为什么要使用递归?我们今...
继续阅读 »

前言


大家好,我是小彭。


今天分享到计算机科学中一个基础又非常重要的概念 —— 递归。递归是计算机中特有的概念,你很难在现实世界中找到一个恰当的例子与之关联起来。因此,对于很多初学编程的人,一开始会很难理解。


那么,究竟什么是递归,我们为什么要使用递归?我们今天就围绕这两个问题展开。




学习路线图:





1. 什么是递归?


递归(Recursion)是一种通过 “函数自己调用自己” 的方式,将问题重复地分解为同类子问题,并最终解决问题的编程技巧。


举个例子,要求一个数 nn 的阶乘 n!=n(n1)(n2)21n! = n*(n-1)*(n-2)*…*2*1 ,有 2 种思考问题的思路:



  • 递推(一般思维): 我们从 11 开始,用 11 乘以 22 得到 2!2! 问题的解,用 33 乘以 2!2! 得到 3!3! 问题的解。依次类推,直到用 nn 乘以 (n1)!(n-1)! 得到原问题 n!n! 的解。这就是用递推解决问题,这是相对简单直接的思考方式;

  • 递归(计算机思维): 我们把 n!n! 的问题拆分为一个 (n1)!(n-1)! 的问题,如果我们知道 (n1)!(n-1)! 的解,那么将它乘以 nn 就可以得出 n!n! 的解。以此类推,我们将一个 (n1)!(n-1)! 的问题拆分为同类型的规模更小的 (n2)!(n-2)! 子问题,直到拆分到无法拆分,可以直接得出结果 1!1! 问题。此时,我们再沿着拆分问题的路径,反向地根据子问题的解求出原问题的解,最终得到原问题 n!n! 的结果。这就是用递归解决问题。


求 n!



从这个例子可以看出, 递归其实是在重复地做 2 件事:



  • 1、自顶向下拆分问题: 从一个很难直接求出结果的、规模较大的原问题开始,逐渐向下拆分为规模较小的子问题(从 n!n! 拆分到 (n1)!(n-1)!),直到拆分到问题边界时停止拆分,这个拆分的过程就是 “递”(问题边界也叫基准情况或终止条件);

  • 2、自底向上组合结果: 从问题边界开始,逐渐向上传递并组合子问题的解(从 (n1)!(n-1)! 得到 n!n!),直到最终回到原问题获得结果,这个组合的过程就是 “归”。


看到这里你会不会产生一个疑问: 我们直接从问题边界 1!1! 一层层自底向上组合结果也可以得到 n!n! 的解,自顶向下拆分问题的过程显得没有必要。确实,对于对于这种原问题与子问题只是 “线性” 地减少一个问题规模的情况,确实是这样。但是对于很多稍微复杂一些的问题,原问题与子问题会构成一个树型的 “非线性” 结构,这个时候就适合用递归解决,很难用递推解决。


举个例子, 求斐波那契数列,这个问题同时也是 LeetCode 上的一道典型例题:LeetCode · 509. 斐波那契数:该数列从 11 开始,每一项数字都是前面两项数字的和。


LeetCode 例题



虽然,我们可以利用递推的方式从 F(0)F(0)F(1)F(1) 自底向上推导出 F(n)F(n) 的解,但是这种非线性的方式在编程语言中很难实现,而使用递归的方式自顶向下地解决问题,在编码上是很容易实现的。


当然,这段代码中存在非常多的重复计算,最终使得整个算法的时间复杂度达到惊人的指数级 O(2n)O(2^n)。例如在计算 F(5)=F(3)+F(4)F(5)=F(3)+F(4)F(6)=F(4)+F(5)F(6)=F(4)+F(5) 的时候,F(4)F(4) 就被重复计算 2 次,这种重复计算完全相同的子问题的情况就叫 重叠子问题 ,以后我们再专门讨论。


用递归解决斐波那契数列



用递归解决(无优化)


class Solution {
fun fib(N: Int): Int {
if(N == 0){
return 0
}
if(N == 1){
return 1
}
// 拆分问题 + 组合结果
return fib(N - 1) + fib(N - 2)
}
}



2. 递归的解题模板



  • 1、判断当前状态是否异常,例如数组越界,n < 0 等;

  • 2、判断当前状态是否满足终止条件,即达到问题边界,可以直接求出结果;

  • 3、递归地拆分问题,缩小问题规模;

  • 4、组合子问题的解,结合当前状态得出最终解。


fun func(n){
// 1. 判断是否处于异常条件
if(/* 异常条件 */){
return
}
// 2. 判断是否满足终止条件(问题边界)
if(/* 终止条件 */){
return result
}
// 3. 拆分问题
result1 = func(n1)
result2 = func(n2)
...
// 4. 组合结果
return combine(result1, result2, ...)
}



3. 计算机如何实现递归?


递归程序在解决子问题之后,需要沿着拆分问题的路径一层层地原路返回结果,并且后拆分的子问题应该先解决。这个逻辑与栈 “后进先出” 的逻辑完全吻合:



  • 拆分问题: 就是一次子问题入栈的过程;

  • 组合结果: 就是一次子问题出栈的过程。


事实上,这种出栈和入栈的逻辑,在编程语言中是天然支持的,不需要程序员实现。程序员只需要维护拆分问题和组合问题的逻辑,一次函数自调用和返回的过程就是一次隐式的函数出栈入栈过程。在程序运行时,内存空间中会存在一块维护函数调用的区域,称为 函数调用栈 ,函数的调用与返回过程,就天然对应着一次子问题入栈和出栈的过程:



  • 调用函数: 程序会创建一个新的栈帧并压入调用栈的顶部;

  • 函数返回: 程序会将当前栈帧从调用栈栈顶弹出,并带着返回值回到上一层栈帧中调用函数的位置。


我们在分析递归算法的空间复杂度时,也必须将隐式的函数调用栈考虑在内。




4. 递归与迭代的区别


递归(Recursion)和迭代(Iteration)都是编程语言中重复执行某一段逻辑的语法。


语法上的区别在于:



  • 迭代: 通过迭代器(for/while)重复执行某一段逻辑;

  • 递归: 通过函数自调用重复执行函数中的一段逻辑。


核心区别在于解决问题的思路不同:



  • 迭代:迭代的思路认为只要从问题边界开始,在所有元素上重复执行相同的逻辑,就可以获得最终问题的解(迭代的思路与递推的思路类似);

  • 递归:递归的思路认为只要将原问题拆分为子问题,在每个子问题上重复执行相同的逻辑,最终组合所有子问题的结果就可以获得最终问题的解。


例如, 在计算 n! 的问题中,递推或迭代的思路是从 1! 开始重复乘以更大的数,最终获得原问题 n! 的解;而递归的思路是将 n! 问题拆分为 (n-1)! 的问题,最终通过 (n-1)! 问题获得原问题 n! 的解。


再举个例子,面试中出现频率非常高的反转链表问题,同时也是 LeetCode 上的一道典型例题:LeetCode 206 · 反转链表。假设链表为 1 → 2 → 3 → 4 → ∅,我们想要把链表反转为 ∅ ← 1 ← 2 ←3 ←4,用迭代和递归的思路是不同的:



  • 迭代: 迭代的思路认为,只要重复地在每个节点上处理同一个逻辑,最终就可以得到反转链表,这个逻辑是:“将当前节点的 next 指针指向前一个节点,再将游标指针移动到后一个节点”。

  • 递归: 递归的思路认为,只要将反转链表的问题拆分为 “让当前节点的 next 指针指向后面整段子链的反转链表”,在每个子链表上重复执行相同的逻辑,最终就能够获得整个链表反转的结果。


这两个思路用示意图表示如下:


示意图



迭代题解


class Solution {
fun reverseList(head: ListNode?): ListNode? {
var cur: ListNode? = head
var prev: ListNode? = null

while (null != cur) {
val tmp = cur.next
cur.next = prev
prev = cur
cur = tmp
}
return prev
}
}

迭代解法复杂度分析:



  • 时间复杂度:每个节点扫描一次,时间复杂度为 O(n)O(n)

  • 空间复杂度:使用了常量级别变量,空间复杂度为 O(1)O(1)


递归题解


class Solution {
fun reverseList(head: ListNode?): ListNode? {
if(null == head || null == head.next){
return head
}
val newHead = reverseList(head.next)
head.next.next = head
head.next = null
return newHead
}
}

递归解法复杂度分析:



  • 时间复杂度:每个节点扫描一次,时间复杂度为 O(n)O(n)

  • 空间复杂度:使用了函数调用栈,空间复杂度为 O(n)O(n)


理论上认为迭代程序的运行效率会比递归程序更好,并且任何递归程序(不止是尾递归,尾递归只是消除起来相对容易)都可以通过一个栈转化为迭代程序。但是,这种消除递归的做法实际上是以牺牲程序可读性为代价换取的,一般不会为了运行效率而刻意消除递归。


不过,有一种特殊的递归可以被轻松地消除,一些编译器或运行时会自动完成消除工作,不需要程序员手动消除,也不会破坏代码的可读性。




5. 尾递归


在编程语言中,尾调用是指在一个函数的最后返回另一个函数的调用结果。如果尾调用最后调用的是当前函数本身,就是尾递归。为什么我们要专门定义这种特殊的递归形式呢?因为尾递归也是尾调用,而在大多数编程语言中,尾调用可以被轻松地消除 ,这使得程序可以模拟递归的逻辑而又不损失性能,这叫 尾递归优化 / 尾递归消除 。例如,以下 2 段代码实现的功能是相同的,前者是尾递归,而后者是迭代。


尾递归


fun printList(itr : Iterator<*>){
if(!itr.hasNext()) {
return
}
println(itr.next())
// 尾递归
printList(itr)
}

迭代


fun printList(itr : Iterator<*>){
while(true) {
if(!itr.hasNext()) {
return
}
println(itr.next())
}
}

可以看到,使用一个 while 循环和若干变量消除就可以轻松消除尾递归。




6. 总结


到这里,相信你已经对递归的含义以及递归的强大之处有所了解。 递归是计算机科学中特有的解决问题的思路:先通过自顶向下拆分问题,再自底向上组合结果来解决问题。这个思路在编程语言中可以用函数自调用和返回实现,因此递归在编程实现中会显得非常简洁。 正如图灵奖获得者尼克劳斯·维尔特所说:“递归的强大之处在于它允许用户用有限的语句描述无限的对象。因此,在计算机科学中,递归可以被用来描述无限步的运算,尽管描述运算的程序是有限的。”


作者:彭旭锐
链接:https://juejin.cn/post/7145888770410151967
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

拒绝手动Notifydatasetchanged(),使用ListAdapter高效完成RecyclerView刷新

关于RecyclerView的更新  RecyclerView在显示静态的列表的数据的时候,我们用普通的Adapter,然后添加列表,调用notifyDataSetChanged()即可展示列表,但是对于动态变化的列表来说,全靠notifyDataSetCha...
继续阅读 »

关于RecyclerView的更新

  RecyclerView在显示静态的列表的数据的时候,我们用普通的Adapter,然后添加列表,调用notifyDataSetChanged()即可展示列表,但是对于动态变化的列表来说,全靠notifyDataSetChanged()来完成列表更新显得非常没有效率,因为有时候开发者只是想增删一个Item,而这却要付出刷新全部列表的代价。于是谷歌又给我们提供了多种api让我们完成局部Item的增删查改,如下:

  1. notifyItemRemoved()
  2. notifyItemInserted()
  3. notifyItemRangeChanged()
  4. ...

  这些api固然好用但是对于某些场景来说我们难以下手,例如后台返回的列表的全部数据,在获取新的列表之后,开发者也许想比较新旧列表的不同,然后更新发生变化的item,这又如何实现呢?

关于DiffUtil

  谷歌根据开发者需要比较新旧列表异同的痛点,推出了DiffUtil工具,它的核心算法是Myers差分算法,有兴趣可以自行学习,这篇文章不作深入探讨(其实笔者也不会)。

关于ListAdapter

  注:这个ListAdapter是需要额外引入的,给RecyclerView使用的一个Adapter,并非SDK里面的那个,因此需要区分开来。

  ListAdapter是谷歌基于上述的DiffUtil进行封装的一个Adapter,简单地继承重写即可达到DiffUtil的效果,高效完成RecyclerView的更新,这个也是本篇的重点。

实战

布局和对应的实体类

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools">

<TextView
android:id="@+id/tv_name"
tools:text="名字"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>

<TextView
android:id="@+id/tv_age"
tools:text="18岁"
app:layout_constraintStart_toEndOf="@id/tv_name"
app:layout_constraintTop_toTopOf="parent"
android:layout_marginStart="20dp"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>

<TextView
android:id="@+id/tv_tall"
tools:text="180cm"
app:layout_constraintStart_toEndOf="@id/tv_age"
app:layout_constraintTop_toTopOf="parent"
android:layout_marginStart="20dp"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>

<TextView
android:id="@+id/tv_long"
tools:text="18cm"
app:layout_constraintStart_toEndOf="@id/tv_tall"
app:layout_constraintTop_toTopOf="parent"
android:layout_marginStart="20dp"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>

</androidx.constraintlayout.widget.ConstraintLayout>

image.png

data class ItemTestBean(
val name:String,
val age:Int,
val tall:Int,
val long:Int
)

重写ListAdapter

ListAdapter的重写包含的关键点比较多,这里分步骤说明:

第一步:实现DiffUtil.ItemCallback

  这是整个ListAdapter中最最最关键的一个步骤,因为它是DiffUtil知道如何正确修改列表的核心,我们直接看代码。

object ItemTestCallback : DiffUtil.ItemCallback<ItemTestBean>() {
override fun areItemsTheSame(oldItem: ItemTestBean, newItem: ItemTestBean): Boolean {
return oldItem.name == newItem.name
}

override fun areContentsTheSame(oldItem: ItemTestBean, newItem: ItemTestBean): Boolean {
return oldItem.name == newItem.name
&& oldItem.age == newItem.age
&& oldItem.tall == newItem.tall
&& oldItem.long == newItem.long
}

}

  乍一看非常复杂,实际原理非常简单,areItemsTheSame()方法判断的是实体类的主键,areContentsTheSame()方法判断的是实体类中会导致UI变化的字段

第二步:实现viewHolder

这一步和其他的Adapter没什么区别,笔者用了viewBinding,你也可以根据自己项目实际情况改造。

inner class ItemTestViewHolder(private val binding: ItemTestBinding):RecyclerView.ViewHolder(binding.root){

fun bind(bean:ItemTestBean){
binding.run {
tvName.text=bean.name
tvAge.text=bean.age.toString()
tvTall.text=bean.tall.toString()
tvLong.text=bean.long.toString()
}
}

}

第三步:组合成完整的ListAdapter

在ListAdapter中填入相应的泛型(实体类和ViewHolder类型),然后在构造函数中传入我们刚才实现的DiffUtil.ItemCallback即可,实现的两个方法和其他Adapter大同小异,唯一需要注意的是ListAdapter为我们提供了一个getItem的快捷方法,因此在onBindViewHolder()时可以直接调用。

class ItemTestListAdapter : ListAdapter<ItemTestBean,ItemTestListAdapter.ItemTestViewHolder>(ItemTestCallback) {

inner class ItemTestViewHolder(private val binding: ItemTestBinding):RecyclerView.ViewHolder(binding.root){
//...省略
}

override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): ItemTestViewHolder {
return ItemTestViewHolder(ItemTestBinding.inflate(LayoutInflater.from(parent.context),parent,false))
}

override fun onBindViewHolder(holder: ItemTestViewHolder, position: Int) {
//通过ListAdapter内部实现的getItem方法找到对应的Bean
holder.bind(getItem(position))
}

}

使用ListAdapter完成列表的增删查改

为了方便演示,使用如下的List和初始化代码:

private val testList = listOf<ItemTestBean>(
ItemTestBean("小明",18,180,18),
ItemTestBean("小红",19,180,18),
ItemTestBean("小东",20,180,18),
ItemTestBean("小刘",18,180,18),
ItemTestBean("小德",15,180,18),
ItemTestBean("小豪",14,180,18),
ItemTestBean("小江",12,180,18),
)

override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val binding=ActivityMainBinding.inflate(LayoutInflater.from(this))
setContentView(binding.root)
val adapter=ItemTestListAdapter()
binding.rv.adapter=adapter
}

插入元素

插入全新的列表

adapter.submitList(testList)

image.png

完事了??

  是的,我们只需要调用submitList方法告诉Adatper我们要插入一个新的列表即可。

image.png

局部插入元素

  也许插入全新列表并不能让你感觉到ListAdapter的精妙之处,因为这和原来的Adapter差别并不大,我们再来试试往列表中插入局部的元素,例如我们要在小刘和小德之间插入一个新的Item。

  我们对列表转成可变列表(为什么使用不可变列表,原因后面会解释),然后插入元素,最后调用submitList把新的列表传入进去即可。

val newList=testList.toMutableList().apply {
add(3,ItemTestBean("坤坤鸡",21,150,4))
}
adapter.submitList(newList)

image.png

  列表更新了,由此可见,无论是增加一个元素还是多个元素,我们都只需要调submitList即可。

  这里说一下为什么要重新传入一个新的List而不是对原来的List进行修改,因为源码中有这样一段,笔者推测是因为这个校验差分的逻辑是异步的,如果外部对原列表进行修改会导致内部的逻辑异常(未验证只是猜测)。

  因此我们切记要传入新的List而不是对原List进行修改。

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

//...省略
//校验列表是否是同一个对象
if (newList == mList) {
// nothing to do (Note - still had to inc generation, since may have ongoing work)
if (commitCallback != null) {
commitCallback.run();
}
return;
}
//...省略
}

删除元素和修改元素

  聪明的读者估计也已经猜到了,无论是增加删除和修改,我们都只需要submitList即可,因为List中就已经包含了列表的更新信息,一切的更新ListAdapter已经自动替我们完成了。

val newList=testList.toMutableList().apply {
//删除
removeAt(2)
//修改
this[3]=this[3].copy(name = "改名后的小帅哥")
}

adapter.submitList(newList)

列表清空

  一切尽在submitList,如果我们要让列表清空,那我们就submit一个空对象就行了,非常简单!

adapter.submitList(null)

使用新的列表进行更新(项目中最常见的复杂场景)

val newList=listOf(
//修改
ItemTestBean("小明",18,20,18),
ItemTestBean("小红",19,180,18),
//插入
ItemTestBean("蔡徐鸡",20,180,18),
ItemTestBean("小刘",18,180,18),
ItemTestBean("我爱你",14,180,18),
ItemTestBean("小江",12,180,18),
)

adapter.submitList(newList)

image.png

我们可以看到,新的列表相对原列表而言,发生了修改、删除、插入等操作,如果这些由开发者自己来维护,是非常麻烦的,但是依靠ListAdapter内置的差异性算法,自动帮我们完成了这些工作。

总结

  笔者使用一个简单的案例演示了ListAdapter如何帮助开发者完成列表差异性更新的逻辑,非常适合那些返回整段列表然后更新局部元素的逻辑,例如后台返回的一整段列表,这些列表可能只有一两个元素发生了变化,如果按照传统的notifyDataSetChange()会严重浪费性能,而ListAdapter只会更新那些发生了变化的区域。

  如果你的项目不能直接使用ListAdapter,也希望使用这个差分算法,你可以直接使用DiffUtil去更新你项目的Adapter,关于这个DiffUtil的直接使用,网上有许多教程,用起来也并不难,这里不在赘述。


作者:晴天小庭
链接:https://juejin.cn/post/7125275626134585352
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »

【Android爬坑日记四】组合替代继承,减少Base类滥用

背景 先说一下背景,当接触了比较多的项目之后,其实会发现每一个项目都会封装BaseActivity、BaseFragment等等。其实初衷其实是好的。每一个Activity和Fragment都是很多模板代码的,为了减少模板代码,封装进Base类其实是一种比较方...
继续阅读 »

背景


先说一下背景,当接触了比较多的项目之后,其实会发现每一个项目都会封装BaseActivity、BaseFragment等等。其实初衷其实是好的。每一个Activity和Fragment都是很多模板代码的,为了减少模板代码,封装进Base类其实是一种比较方便且可行的选择。


Base类涵盖了抽象、继承等面向对象特性,用得好会减少很多样板代码,但是一旦滥用,会对项目有很多弊端。


举个例子


当项目大了,需要封装进Base类的逻辑会非常多,比如说打印生命周期、ViewBinding 或者DataBinding封装、埋点、监听广播、监听EventBus、展示加载界面、弹Dialog等等其他业务逻辑,更有甚者把需要Context的函数都封装进Base类中。


以下举一个BaseActivity的例子,里面封装了上面所说的大部分情况,实际情况可能更多。


abstract class BaseActivity<T: ViewBinding, VM: ViewModel>: AppCompatActivity {

protected lateinit var viewBinding: T

protected lateinit var viewModel: VM

override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// 打印日志!!
ELog.debugLifeCycle("${this.localClassName} - onCreate")

// 初始化viewModel
viewModel = initViewModel()
// 初始化视图!!
initView()
// 初始化数据!!
initData()
// 注册广播监听!!
registerReceiver()
// 注册EventBus事件监听!!
registerEventBus()

// 省略一堆业务逻辑!

// 设置导航栏颜色!!
window.navigationBarColor = ContextCompat.getColor(this, R.color.primary_color)
}

protected fun initViewModel(): VM {
// 初始化viewModel
}

private fun initViewbinding() {
// 初始化viewBinding
}

// 让子类必须实现
abstract fun initView()

abstract fun initData()

private fun registerReceiver() {
// 注册广播监听
}

private fun unregisterReceiver() {
// 注销广播监听
}

private fun registerEventBus() {
// 注册EventBus事件监听
}

protected fun showDialog() {
// 需要用到Context,因此也封装进来了
}

override fun onResume() {
super.onResume()
ELog.debugLifeCycle("${this.localClassName} - onResume")
}

override fun onPause() {
super.onPause()
ELog.debugLifeCycle("${this.localClassName} - onPause")
}

override fun onDestroy() {
super.onDestroy()
ELog.debugLifeCycle("${this.localClassName} - onDestroy")
unregisterReceiver()
}
}

其实看起来还好,但是在使用的时候难免会遇到一些问题,对于中途接手项目的人来说问题更加明显。我们从中途接手项目的心路历程看看Base类的缺陷。


心路历程




  1. 当创建新的Activity或者Fragment的时候需要想想有没有逻辑可以复用,就去找Base类,或许写Base类的人不同,发现一个项目中可能会存在多个Base类,甚至Base类仍然有多个Base子类实现不同逻辑。这个时候就需要去查看分析每个Base类分别实现了什么功能,决定继承哪个。




  2. 如果一个项目中只有一个Base类的话,仍需要看看Base类实现了什么逻辑,没有实现什么逻辑,防止重复写样板代码。




  3. 当出现Base类实现了的,而自己本身并不想需要,例如不想监听广播或者不想用ViewModel,对于不想监听广播的情况就要特殊做适配,例如往Base类加标志位。对于不想用ViewModel但是由于泛型限制,还是只能传进去,不然没法继承。




  4. 当发现自己集成Base类出BUG了,就要考虑改子类还是改Base类,由于大量的类都集成了Base类,显然改Base类比较麻烦,于是改自己比较方便。




  5. 如果一个Activity中展示了多个Fragment,可能会有业务逻辑的重复,其实只需要一个就好了。




其实第一第二点还好,时间成本其实没有重复写样板代码那么高。但是第三点的话其实用标志位来决定Base类的功能哪个需要实现哪个不需要实现并不是一种优雅的方式,反而需要重写的东西多了几个。第四点归根到底就是Base类其实并不好维护。


爬坑


那么对于Base类怎样实践才比较优雅呢?在我看来组合替代继承其实是一种不错的思路。对于Kotlin first的Android项目来说,组合替代继承其实是比较容易的。以下仅代表个人想法,有不同意见可以交流一下。


成员变量委托


对于ViewModel、Handler、ViewBinding这些Base变量使用委托的方式是比较方便的。


对于ViewBinding委托可以看看我之前的文章,使用起来其实是非常简单的,只需要一行代码即可。


// Activity
private val binding by viewBinding(ActivityMainBinding::inflate)
// Fragment
private val binding by viewBinding(FragmentMainBinding::bind)

对于ViewModel委托,官方库则提供了一个viewBindings委托函数。


private val viewModel:HomeViewModel by viewModels()

需要在Gradle中引入ktx库


implementation 'androidx.fragment:fragment-ktx:1.5.1'
implementation 'androidx.activity:activity-ktx:1.5.1'

而对于Base变量则尽量少封装在Base类中,需要使用可以使用委托,因为如果实例了没有使用其实是比较浪费内存资源的,尽量按需实例。


扩展方法


对于需要用到Context上下文的逻辑封装到Base类中其实是没有必要的,在Kotlin还没有流行的时候,如果说需要使用到Context的工具方法,使用起来其实是不太优雅的。


例如展示一个Dialog:


class DialogUtils {
public static void showDialog(Activity activity, String title, String content) {
// 逻辑
}
}

使用起来就是这样:


class MyActivity : AppCompatActivity() {
...
fun initButton() {
button.setOnClickListener {
DialogUtils.showDialog(this, "title", "content")
}
}
}

使用起来可能就会有一些迷惑,第一个参数把自己传进去了,这对于展示Dialog的语义上是有些奇怪的。按理来说只需要传title和content就好了。


这个时候就会有人想着把这个封装到Base类中。


public abstract class BaseActivity extends AppCompatActivity {

protected void showDialog(String title, String content) {
// 这里就可以用Context了
}
}

使用起来就是这样:


class MyActivity : AppCompatActivity() {
...
fun initButton() {
button.setOnClickListener {
showDialog("title", "content")
}
}
}

是不是感觉好很多了。但是写在Base类中在Java中比较好用,对于Kotlin则完全可以使用扩展函数语法糖来替代了,在使用的时候和定义在Base类是一样的。


fun Activity.showDialog(title: String, content: String) {
// this就能获取到Activity实例
}

class MyActivity : AppCompatActivity() {
...
fun initButton() {
button.setOnClickListener {
// 使用起来和定义在Base类其实是一样的
showDialog("title", "content")
}
}
}

这也说明了,需要使用到Context上下文的函数其实不用在Base类中定义,直接定义在顶层就好了,可以减少Base类的逻辑。


注册监听器


对于注册监听器这种情况则需要分情况,监听器是需要根据生命周期来注册和取消注册的,防止内存泄漏。对于不是每个子类都需要的情况,有的人可能觉得提供一个标志位就好了,如果不需要的话让子类重写。如果定义成抽象方法则每个子类都要重写,如果不是抽象方法的话,子类可能就会忘记重写。在我看来获取生命周期其实是比较简单的事情。按需添加代码监听就好了。


那么什么情况需要封装在Base类中呢?




  • 怕之后接手项目的人忘记写这部分代码,则可以写到Base类中,例如打印日志或者埋点。




  • 而对于界面太多难以测试的功能,例如收到被服务器踢下线的消息跳到登录页面,这个可以写进Base类中,因为基本上每个类都需要监听这种消息。




总结


没有最优秀的架构,只有最适合的架构!对于Base类大家的看法都不一样,追求更少的工作量完成更多事情这个目的是统一的。而Base类一旦臃肿起来了会造成整个项目难以维护,因此对于Base类应该辩证看待,养成只有必要的逻辑才写在Base类中的习惯,feature类应该使用组合的方式来使用,这对于项目的可维护性和代码的可调试性是有好处的。


作者:米奇律师
链接:https://juejin.cn/post/7144671989159067656
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

付费上班,你听说过吗?

众所周知,打工人上班是要拿工资的,哪怕工资再少,也是对打工人劳动的报酬。然而,最近职场上出现了一个新概念,叫做“付费上班”。什么意思呢?你在公司给老板打工,老板不但不需要给你钱,你反倒要给老板“发工资”。有谁会傻到上班还要倒贴钱?这不是滑天下之大稽吗?最近,由...
继续阅读 »

众所周知,打工人上班是要拿工资的,哪怕工资再少,也是对打工人劳动的报酬。

然而,最近职场上出现了一个新概念,叫做“付费上班”。什么意思呢?你在公司给老板打工,老板不但不需要给你钱,你反倒要给老板“发工资”。

有谁会傻到上班还要倒贴钱?这不是滑天下之大稽吗?

最近,由于国内宏观经济形势不太乐观,上千万大学生的就业比较困难。在这样的背景下,还真有一位专家在微博上提出了“付费加班”的建议:


好一个两全其美!这条微博一出来,立刻招来了网友们的激烈嘲讽:

“上班不拿工资,还要倒贴钱给老板,那我们打工到底图什么?嫌家里钱太多吗?”

如果大家觉得,“付费加班”只是某些脑子进水的专家的天方夜谭,根本不可能在现实社会中出现,那就有些天真了。

在今年6月,某著名网络游戏公司,就曾经开设过一个“付费上班”项目:支付17800元,即可参加完美技术中心参与开发的一款无缝大世界多人在线生存类网络游戏。


项目参与者进入工作组后,需在理解项目核心玩法的基础之上,完成策划、原画、3D建模、动作、特效等一系列工作。根据游戏项目开发进度,实践时间将长达三个月或以上,超过三个月部分不再额外收费。

后来,这个项目在社会上引起较大的争议,终于被叫停了。

究竟是怎样的原因,才会滋生出“付费上班”这样畸形的职场模式呢?

我觉得原因主要有三点:

1. 高校的教学内容偏重理论,和实际工作脱节,使得应届毕业生无法快速满足职场需求。

2. 今年国内的经济形势不容乐观,用人单位对外招聘的岗位数量都在缩减。

3. 部分在校大学生自身也存在一定问题,要么选择了并不感兴趣的专业,要么没有很好地学习专业知识、为自己的职业发展做准备。(包括当年的我自己)

说起付费上班,小灰也不禁回想起了我当年刚毕业时候的黑历史。

小灰本科毕业是在2008年,那年正好赶上了全球经济危机,当年的应届毕业生普遍难就业。同时小灰对所学的专业(电气自动化)也不大感兴趣,大学四年整天翘课在网吧里打游戏,一学期下来,连课程老师长什么样都不知道。

转眼到了大四那年,小灰面试了好多家公司,都没有人要。最后,在一次机缘巧合之下,小灰去面试了一个只有30多人的小公司,其主营业务是航空维修。

面试官考察我专业知识,小灰基本上啥也不会,但公司老板娘看小灰比较可爱,就留下了我。就这样,小灰在公司做了半年维修工作,每天拧螺丝焊电路板,月工资只有可怜的2000元。

再后来,小灰报了一个IT培训班,培训了一年编程技术,最后总算是转行做了一名程序员。

这段经历很曲折,同时也教会了小灰,年轻时候的不学无术,早晚是要还债的。

那么,抛开情绪层面,让我们来理性看待一下“付费上班”的现象。

当今就业形势严峻,这是客观事实,只是一味在网上发泄,并不能真正解决问题。

如果用人单位真的能够用心培养应届毕业生,在不存在欺诈的前提下,那些竞争力较差的应届毕业生暂时花费一些金钱换取工作经验,也并非完全不可取。

暂时的投入,只是为了在未来更好地挣钱,这是可以理解的。

但是,“付费上班”这种模式也仅仅是非常时期的一种临时解决方案,**绝对不可以常态化**。

最后,小灰提醒广大的年轻朋友们,务必在学生时代为自己的前途做好规划,千万不要随意挥霍宝贵的青春年华。毕竟,机会都是留给有准备的人。

同时,也祝愿大家早日找到满意的工作,走上人生的正规。

来源:程序员小灰

收起阅读 »

uniapp的骨架屏生成指南

骨架屏一般用于页面在请求远程数据尚未完成时,页面用灰色块预显示本来的页面结构,给用户更好的体验。 使用到的API有uni.createSelectorQuery()uni.getSystemInfoSync()。常规首页的布局一般而言,我们的首页的基础布局是包...
继续阅读 »

骨架屏一般用于页面在请求远程数据尚未完成时,页面用灰色块预显示本来的页面结构,给用户更好的体验。 使用到的API有uni.createSelectorQuery()uni.getSystemInfoSync()

常规首页的布局

一般而言,我们的首页的基础布局是包含的有:顶部搜索、轮播、金刚区、新闻简报、活动魔方。

<template>
   <view class="content">
       <!-- 顶部搜索 -->
       <headerSerch></headerSerch>
       <!-- 轮播 -->
       <swiperBg></swiperBg>
       <!-- 金刚区 -->
       <menus></menus>
       <!-- 新闻简报 -->
       <news></news>
       <!-- 活动魔方 -->
       <activity></activity>
       <!-- 骨架屏 -->
       <skeleton :show="show"></skeleton>
   </view>
</template>

<script>
   import headerSerch from './components/headerSerch.vue'
   import swiperBg from './components/swiperBg.vue'
   import menus from './components/menus.vue'
   import news from './components/news.vue'
   import activity from './components/activity.vue'
   import skeleton from './components/skeleton.vue'
   export default {
       components: {
           headerSerch,
           swiperBg,
           menus,
           news,
           activity,
           skeleton
      },
       data() {
           return {
               show: true
          }
      },
       mounted() {
           setTimeout(()=>{
               this.show = false
          },1200)
      }
  }
</script>

<style scoped>

</style>

skeleton组件的实现

代码如下,稍后给大家解释


步骤一 设置骨架屏的基础样式

我们通过绝对定位的方式把组件的根元素提高层级,避免被父组件的其他组件覆盖掉。使用 uni.getSystemInfoSync()同步获取系统的可使用窗口宽度和可使用窗口高度并赋值给组件根元素的宽高。

<view :style="{
width: windowWidth,
height: windowHeight,
backgroundColor: bgColor,
position: 'absolute',
zIndex: 9999,
top: top,
left: left
}">
......
......
</view>

<script>
   let systemInfo = uni.getSystemInfoSync();
   export default {
       name: 'skeleton',
       props: {
           show: {
               type: Boolean,
               default: true
          },
      },
       data() {
           return {
               windowWidth: systemInfo.windowWidth + 'px',
               windowHeight: systemInfo.windowHeight + 'px',
               bgColor: '#fff',
               top: 0,
               left: 0,
          }
      }
    }
</script>

步骤二 渲染出占位的灰色块

通过uniapp的uni.createSelectorQuery()接口,查询页面带有指定类名的元素的位置和尺寸, 通过绝对定位的方式,用同样尺寸的灰色块定位到相同的位置。

在骨架屏中多数用的主要的矩形节点rectNodes 和圆形节点circleNodes。

首先给这些元素加上相同的skeleton-fade类,这个类的主要为了有一个灰色的背景并使用animate属性使其看到颜色的深浅变化。


按照官方的API使用说明,我们得在mounted 后进行调用方法。 在uni.createSelectorQuery()的后面加in(this.$parent)在微信小程序才能生效,在H5端不用加也生效。(我们主要是获取指定元素的位置和高度详细并赋值给rectNodes、circleNodes,所以得到之后可以把这两个方法删掉。)

mounted() {
   // 矩形骨架元素
   this.getRectEls();
   // 圆形骨架元素
   this.getCircleEls();
},

methods: {
   getRectEls() {
       let query = uni.createSelectorQuery().in(this.$parent)
       query.selectAll('.skeleton-rect').boundingClientRect(res => {
               console.log('rect', JSON.stringify(res));
      }).exec(function() {

      })
  },
   getCircleEls() {
       let query = uni.createSelectorQuery().in(this.$parent)
       query.selectAll('.skeleton-circle').boundingClientRect(res => {
               console.log('circle', JSON.stringify(res));
      }).exec(function() {

      })
  }
},

如下图,在控制台上可以得到我们想到的节点信息。


然后再复制粘贴给data中的rectNodes、circleNodes。 skeleton组件基本上就完成了。我们再做下优化,skeleton组件接收父组件传的show值,默认是true,当父组件的数据接口请求完成之后show设置为false。

大功告成,以下的在浏览器端和微信小程序端的骨架屏展示:



作者:清风programmer
来源:juejin.cn/post/7037476325480742920

收起阅读 »

前端人抓包羊了个羊,玩一次就过关

web
1. 前言最近微信小游戏「羊了个羊」非常火爆,火爆的原因不是因为它很好玩,而是第二关难度非常高,据说只有 0.1% 的人能通关。我也尝试了下,第一关非常容易,第二关玩到对自己的智商产生了怀疑:真的有人自己打通关吗?既然不能常规方法通关,能不能通过别的方式通关呢...
继续阅读 »

1. 前言

最近微信小游戏「羊了个羊」非常火爆,火爆的原因不是因为它很好玩,而是第二关难度非常高,据说只有 0.1% 的人能通关。我也尝试了下,第一关非常容易,第二关玩到对自己的智商产生了怀疑:真的有人自己打通关吗?既然不能常规方法通关,能不能通过别的方式通关呢?答案是可以的,我们可以使用抓包工具进行通关,如果你不知道抓包是什么,可以看看《前端人必须掌握的抓包技能》,里面有较详尽的解释。本文主要讲述羊了羊的通关原理以及使用 whistle 进行抓包通关。

2. 通关原理

2.1 游戏玩法

羊了个羊是一个消消乐类的游戏,只不过主角是羊,点击要消除的蔬菜类食物,三个进入槽内就可以消除。

一共有两关,两关都通关后即可获得一套新羊装皮肤,并加入自己所属省份的羊群去,为自己的省份排名出一分力。



可以看到第一关是非常容易的,一般都不需要使用任何道具就可以轻松过关。第二关显然要难得多,

既然如此,能否通过抓包的方式,篡改第二关的地图数据,让它加载第一关的数据呢。


2.2 环境配置

只要地图数据是通过服务端返回给客户端的,就可以通过抓包工具抓取篡改,现在先做好环境的配置:

whistle 是基于 Node 实现的跨平台抓包免费调试工具,可以使用 npm 进行安装

  1. 先安装 node,建议用 nvm 管理

  2. 全局安装 whistle

npm i -g whistle & w2 start

成功启动服务后,就可以通过浏览器访问 http://127.0.0.1:8899/ 查看抓包、修改请求等。


  1. 由于羊了羊客户端与服务端的通信是 https 协议,需要把 whistle 的 https 根证书安装到手机证书管理处并信任。


  1. 此时,再在与电脑连接了同一个 wifi 的手机上配置代理指向 PC 电脑的 IP 和 whistle 监听的端口即可在电脑上截获数据包。

  2. 通过电脑抓包,可以发现地图接口请求路径如下:

# 第一关地图数据

https://cat-match.easygame2021.com/sheep/v1/game/map_info_new?map_id=80001

响应数据:{"err_code":0,"err_msg":"","data":"046ef1bab26e5b9bfe2473ded237b572"}

# 第二关地图数据

https://cat-match.easygame2021.com/sheep/v1/game/map_info_new?map_id=90019

响应数据:{"err_code":0,"err_msg":"","data":"fdc2ccf2856998d37446c004bcc0aae7"}

知道了地图数据的请求路径,就可以改写响应了。

2022-09-20 更新

地图接口请求的数据变更为:

https://cat-match.easygame2021.com/sheep/v1/game/map_info_ex?matchType=3

3. 通关方式

3.1 改写响应体

在 whistle 中添加过滤规则,拦截第二关地图的请求,返回第一关地图的响应数据。

先在 rules 面板添加一条过滤规则,然后再 values 添加一条返回值,注意要检查是否对应清楚,否则会请求会一直卡住无法响应。



规则设置完后,删除小游戏,重新进入,即可看到抓取的第二关地图请求返回的数据时第一关地图的。


在测试过程中,发现第二关地图的请求 id 以日期递增,比如 900018、900019,注意修改,具体以抓取到的地图请求路径为准。

2022-09-20 更新

上面这种方式已被官方优化,不再有先有第一关和第二关先后请求,但原理是一样的。

添加 whistle 规则:

https://cat-match.easygame2021.com/sheep/v1/game/map_info_ex?matchType=3 resBody://{ylgyV2}

对应的 values 设置为:

{
   "err_code":0,
   "err_msg":"",
   "data":{
       "map_md5":[
           "046ef1bab26e5b9bfe2473ded237b572", // 第一关
           "046ef1bab26e5b9bfe2473ded237b572" // 第二关,用第一关的值替换第二关
      ],
       "map_seed": [4208390475,3613589232,3195281918,329197835]
  }
}

3.2 302 重定向

客户端与服务端是通过 https 通信,传递 HTTP 报文,HTTP 报文包括起始行、首部和主体。


HTTP 请求报文中包含命令和 URL,HTTP 响应报文中包含了事务的结果,而响应的状态码为客户端提供了一种理解事务处理结果的便捷方式。其中 300 ~ 399 代表重定向状态码,重定向状态码要么告知客户端使用替代位置来访问目标资源内容,

要么就提供一个替代的响应而不是资源的内容。如果资源已被移动,可发送一个重定向状态码和一个可选的 Location 首部来告知客户端资源已被移走,以及现在可以在哪里找到它。

常见的重定向状态对比:

  • 301:表明目标资源被永久的移动到了一个新的 URI,任何未来对这个资源的引用都应该使用新的 URI

  • 302:所请求的页面已经临时转移到新的 URI,302 允许各种各样的重定向,一般情况下都会实现为到 GET 的重定向,但是不能确保 POST 会重定向为 POST。

301和302跳转,最终看到的效果是一样的,但对于 SEO 来说有两个区别:

  • 301 重定向是永久的重定向,搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址。

  • 302 存在网址URL劫持,一个不道德的人在他自己的网址A做一个302重定向到你的网址B,出于某种原因, Google搜索结果所显示的仍然是网址A,但是所用的网页内容却是你的网址B上的内容,这种情况就叫做网址URL劫持

知道重定向的原理后,请求第二关地图时,就可以通过返回重定向响应状态码,告诉客户端,资源已被移动,可以去请求第一关地图数据,

在 whistle 添加 302 重定向规则如下:

https://cat-match.easygame2021.com/sheep/v1/game/map_info_new?map_id=90019 redirect://https://cat-match.easygame2021.com/sheep/v1/game/map_info_new?map_id=80001

2022-09-20 更新,上面这种方式已被官方优化,不再有先有第一关和第二关先后请求,此方式不再可行。

要实现了羊了个羊通关,除了更改地图数据还可以篡改道具数据,但尝试时发现它获取道具的方式不是通关网络请求,而是通关转发朋友圈/看广告后获得回调,前端直接做的逻辑处理,因此作罢。

4. 总结

本文是《前端人必须掌握的抓包技能》的案例实践,简单地讲述如何使用 whistle 实现羊了羊通关。考虑到羊了个羊的官方不断更新迭代,现在的漏洞很快会被修复,本文的通关策略会很快失效。如果你能学会到本文的抓包技巧,能给你在日常的开发调试工作中提供一种思路,本文的目的也就达到了。

感谢 Kagol 大佬的建议,才有此篇文章的延生。

声明:本文所述相关技术仅供学习交流使用。

作者:jecyu
来源:juejin.cn/post/7145256312488591391

收起阅读 »

Compose挑灯夜看 - 照亮手机屏幕里面的书本内容

一、前言上一篇文章 Compose回忆童年 - 手拉灯绳-开灯/关灯里面82年钨丝灯,让我又有了新的想法,我们怎么照亮手机里面的文本内容呢?我们会在上一篇文章的基础上来实现“挑灯夜看”的功能,怎么下手呢?往下看👇二、文本着色器我们想要实现照亮功能,那...
继续阅读 »

一、前言

上一篇文章 Compose回忆童年 - 手拉灯绳-开灯/关灯里面82年钨丝灯,让我又有了新的想法,我们怎么照亮手机里面的文本内容呢?

我们会在上一篇文章的基础上来实现“挑灯夜看”的功能,怎么下手呢?往下看👇

二、文本着色器

我们想要实现照亮功能,那肯定需要有不亮的文本内容。

通过透明度来可以吗?肯定不行,文本内容是可以上下滑动的,是一个整体,我们不能通过透明度来做。

在看到小米手机的文本着色效果之后:

小米万象息屏.png

我知道如何下手了,我先来看看ComposeText如何做渐变着色?

1. 有些同学可能喜欢用Canvas去绘制:

Canvas(...) {
drawIntoCanvas { canvas ->
canvas.nativeCanvas.drawText(text, x, y, paint)
}
}

2. 我们可以使用ModifeirdrawWithCache修饰符,官方文档的链接里面也给我们了不少示例。

QQ20220830-203813@2x.png

Text(
text = "永远相信美好的事情即将发生❤️",
modifier = Modifier
.graphicsLayer(alpha = 0.99f)
.drawWithCache {
val brush = Brush.horizontalGradient(
listOf(
Color(0xFFE24CE2),
Color(0xFF73BB70),
Color(0xFFE24CE2)
)
)
onDrawWithContent {
drawContent()
drawRect(brush, blendMode = BlendMode.SrcAtop)
}
}
)

上面代码,我们使用到了BlendMode,我们这里用的是BlendMode#SrcAtop: 将源图像合成到目标图像上,仅限于与目标重叠的位置,确保只有文本可见并且矩形的其余部分被剪切。

3. Google在Compose1.2.0-beta01API变更里面,向TextStyleSpanStyle添加了 Brush API,以提供使用渐变颜色绘制文本的方法。

兄弟们支持了吗.png

private val GradientColors = listOf(
Color(0xFF00FFFF), Color(0xFF97E063),
Color(0xFFE24CE2), Color(0xFF97E063)
)
Text(
modifier = Modifier.align(Alignment.Center).requiredWidthIn(max = 250.dp),
text = "永远相信美好的事情即将发生❤️,我们不会期待米粉的期待!\n\n兄弟们支持了吗?",
style = TextStyle(
brush = Brush.linearGradient(
colors = GradientColors
)
)
)

我们可以看到Emoji表情没有被着色,非常Nice。

我们看一下linearGradient/verticalGradient/radialGradient/sweepGradient效果对比:

linearGradient.pngverticalGradient.png

左边的是linearGradient右边的是verticalGradient

4444.png5555.png

左边的是radialGradient右边的是sweepGradient

还有一种内置的BrushSolidColor,填充指定颜色。

查看Brush#LinearGradient源码发现它继承自ShaderBrush

// androidx.compose.ui.graphics.Brush
class LinearGradient internal constructor(
private val colors: List<Color>,
private val stops: List<Float>? = null,
private val start: Offset,
private val end: Offset,
private val tileMode: TileMode = TileMode.Clamp
) : ShaderBrush()

自定义ShaderBrush,可以修改画笔大小,那么我们也来整一个,用于下面的钨丝灯的照亮效果,刚刚上面还介绍了到一个gradient符合我们的要求,radialGradient,更多的源码细节,这里就不做深入介绍,夜深了哈哈哈。

我们接下来需要初始化一个ShaderBrush

object : ShaderBrush() {
override fun createShader(size: Size): Shader {
return RadialGradientShader(
center = ...,
radius = ...,
colors = ...
)
}
...
}

三、实现照亮文本

刚刚上面初始化了一个ShaderBrush,我们照亮文本内容,文本内容不可能只有一屏对吧,肯定需要支持滑动文本,那要怎么做呢?

我想肯定有掘友知道了,我们可以用ModifierverticalScroll修饰符,记录滚动状态ScrollState,然后设置到RadialGradientShadercenter里面。

我们这里的文本内容引用了:三国演义的第一章内容,我们同样需要上一篇文章RopHandleState

private fun ComposeText(state: RopeHandleState) {
Text(
text = sanguoString,
modifier = Modifier
.fillMaxSize()
.padding(16.dp)
.verticalScroll(state.scrollState),
style = LocalTextStyle.current.merge(
TextStyle(
fontSize = 18.sp,
brush = state.lightContentBrush
)
)
)
}

这里我们用到了TextStyle#Brush的API,同时也添加了滚动修饰符,因为我们需要上下滑动文本,保证“钨丝灯”能照亮我们的文本内容。

我们在RopHandleState里面初始化ScrollState

val scrollState = ScrollState(0)

private val scrollOffset by derivedStateOf {
// 这里增加Y轴的距离
Offset(size.width / 2F, scrollState.value.toFloat() + size.width * 0.2F)
}

可以滚动,我们需要把滚动的距离同步给我们的ShaderBrush

// isOpen == true,钨丝灯亮了需要初始化ShaderBrush
object : ShaderBrush() {
override fun createShader(size: Size): Shader {
lastScrollOffset = Offset(size.width/2F, scrollOffset.y)
return RadialGradientShader(
center = lastScrollOffset!!,
radius = size.minDimension,
colors = listOf(Color.Yellow, Color(0xff85733a), Color.DarkGray)
)
}
override fun equals(other: Any?): Boolean {
return lastScrollOffset?.y == scrollOffset.y
}
}

// isOpen == false,钨丝灯灭了
SolidColor(Color.DarkGray)

根据“钨丝灯”的状态,返回不同的Brush:

val lightContentBrush by derivedStateOf {
if(isOpen) {
object : ShaderBrush() { ... }
} else {
SolidColor(Color.DarkGray)
}
}

这里需要注意一下,我们在打开和关闭钨丝灯的时候,需要把lastScrollOffset设置为初始状态值

fun toggle() {
isOpen = !isOpen
lastScrollOffset = Offset.Zero
}

其他相关的代码,请参考上一篇文章 Compose回忆童年 - 手拉灯绳-开灯/关灯

我们来看看最终效果吧

2022-08-30 22_18_31.gif

延伸:这里其实还可通过手指触摸指定范围区域内高亮哦,有兴趣的可以去试试!!


作者:Halifax
链接:https://juejin.cn/post/7137673203714899998
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »

把数据库里的未付款订单改成已付款,会发生什么

导言 不知道大家在网上购物的时候,有没有这样的念头,如果能把未付款的订单偷偷用一条SQL改成已付款,该多么美好啊。那么在实际开发过程中,我们应当如何保证数据库里的数据在保存后不会被偷偷更改? 大家好我是日暮与星辰之间,创作不易,如果觉得有用,求点赞,求收藏,...
继续阅读 »

导言


不知道大家在网上购物的时候,有没有这样的念头,如果能把未付款的订单偷偷用一条SQL改成已付款,该多么美好啊。那么在实际开发过程中,我们应当如何保证数据库里的数据在保存后不会被偷偷更改?



大家好我是日暮与星辰之间,创作不易,如果觉得有用,求点赞,求收藏,求转发,谢谢。



理论


在介绍具体的内容之间,先介绍MD5算法,简单的来说,MD5能把任意大小、长度的数据转换成固定长度的一串字符,经常玩大型游戏的朋友应该都注意到过,各种补丁包、端游客户端之类的大型文件一般都附有一个MD5值,用于确保你下载文件的完整性。那么在这里,我们可以借鉴其思想,对订单的某些属性进行加密计算,得出来一个 MD5值一并保存在数据库当中。从数据库取出数据后第一时间进行校验,如果有异常更改,那么及时抛出异常进行人工处理。


实现


道理我都懂,但是我要如何做呢,别急,且听我一一道来。


这种需求听起来并不强绑定于某个具体的业务需求,这就要用到了我们熟悉的鼎鼎有名的AOP(面向切面编程)来实现。


首先定义四个类型的注解作为AOP的切入点。@Sign@Validate都是作用在方法层面的,分别用于对方法的入参进行加签和验证方法的返回值的签名。@SignField用于注解关键的不容篡改的字段。@ValidateField用于注解保存计算后得出的签名值。


@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Sign {
}

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Validate {
}

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface SignField {
}

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface ValidField {
}

以订单的实体为例 sn,amt,status,userId就是关键字段,绝不能允许有人在落单到数据库后对这些字段偷偷篡改。


public class Order {
@SignField
private String sn;
@SignField
private String amt;
@SignField
private int status;
@SignField
private int userId;
@ValidField
private String sign;
}

下面就到了重头戏的部分,如何通过AOP来进行实现。


1. 定义切入点


@Pointcut("execution(@com.example.demo.annotations.Sign * *(..))")
public void signPointCut() {

}

@Pointcut("execution(@com.example.demo.annotations.Validate * *(..))")
public void validatePointCut() {

}

2.环绕切入点


@Around("signPointCut()")
public Object signAround(ProceedingJoinPoint pjp) throws Throwable {
Object[] args = pjp.getArgs();
for (Object o : args) {
System.out.println(o);
sign(o);
}
Object res = pjp.proceed(args);
return res;
}

@Around("validatePointCut()")
public Object validateAround(ProceedingJoinPoint pjp) throws Throwable {
Object[] args = pjp.getArgs();
Object res = pjp.proceed(args);
valid(res);
return res;
}

3. 签名的实现


1.获取需要签名字段


private Map<String, String> getSignMap(Object o) throws IllegalAccessException {
Map<String, String> fieldNameToValue = new HashMap<>();
for (Field f : o.getClass().getDeclaredFields()) {
System.out.println(f.getName());
for (Annotation annotation : f.getDeclaredAnnotations()) {
if (annotation.annotationType().equals(SignField.class)) {
String value = "";
f.setAccessible(true);
fieldNameToValue.put(f.getName(), f.get(o).toString());
}
}
}
return fieldNameToValue;
}

2.计算出签名值,这里在属性名和属性值以外加入了我的昵称以防止他人猜测,同时使用了自定义的分隔符来加强密码强度。


private String getSign(Map<String, String> fieldNameToValue) {
List<String> names = new ArrayList<>(fieldNameToValue.keySet());
StringBuilder sb = new StringBuilder();
for (String name : names)
sb.append(name).append("@").append(fieldNameToValue.get(name));
System.out.println(sb.append("日暮与星辰之间").toString());
String signValue = DigestUtils.md5DigestAsHex(sb.toString().getBytes(StandardCharsets.UTF_8));
return signValue;
}


  1. 找到保存签名的字段


private Field getValidateFiled(Object o) {
for (Field f : o.getClass().getDeclaredFields()) {
for (Annotation annotation : f.getDeclaredAnnotations()) {
if (annotation.annotationType().equals(ValidField.class)) {
return f;
}
}
}
return null;
}


  1. 对保存签名的字段进行赋值


public void sign(Object o) throws IllegalAccessException {
Map<String, String> fieldNameToValue = getSignMap(o);
if (fieldNameToValue.isEmpty()) {
return;
}
Field validateField = getValidateFiled(o);
if (validateField == null)
return;
String signValue = getSign(fieldNameToValue);
validateField.setAccessible(true);
validateField.set(o, signValue);
}


  1. 对从数据库中取出的对象进行验证


public void valid(Object o) throws IllegalAccessException {
Map<String, String> fieldNameToValue = getSignMap(o);
if (fieldNameToValue.isEmpty()) {
return;
}
Field validateField = getValidateFiled(o);
validateField.setAccessible(true);
String signValue = getSign(fieldNameToValue);
if (!Objects.equals(signValue, validateField.get(o))) {
throw new RuntimeException("数据非法");
}

}

使用示例


对将要保存到数据库的对象进行签名


@Sign
public Order save( Order order){
orderList.add(order);
return order;
}

验证从数据库中取出的对象是否合理


@Validate
public Order query(@ String sn){
return orderList.stream().filter(e -> e.getSn().equals(sn)).findFirst().orElse(null);
}

作者:日暮与星辰之间
链接:https://juejin.cn/post/7144378128914186270
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

超好用的官方core-ktx库,了解一下~

ktx
本篇文章主要是研究core-ktx库中graphics包下提供的关于View绘制、Bitmap、Rect、Color等操作的一系列扩展API,看看能为我们开发带来哪些便利。 Drawable与Bitmap相互间转换 Bitmap.toDrawable(Res...
继续阅读 »

本篇文章主要是研究core-ktx库中graphics包下提供的关于View绘制、BitmapRectColor等操作的一系列扩展API,看看能为我们开发带来哪些便利。



DrawableBitmap相互间转换


Bitmap.toDrawable(Resource)实现BitmapDrawable


image.png


Bitmap定义了一个快速转换成BitmapDrawable的扩展方法,还是少写了一些模板代码的。


Drawable.toBitmap()实现Drawable转换成Bitmap对象


image.png


Drawable转换成Bitmap应该是我们日常开发中常见的场景,这里官方库直接给我们提供了一个toBitmap()的API,非常的方便,下面我们来简单介绍下其中的原理:




  1. 首先判断当前Drawable的类型是否为BitmapDrawable,如果是直接调用其getBitmap()就能直接拿到Bitmap对象,然后根据传入的宽高进行一定比例的压缩转换后进行返回;




  2. 如果不是BitmapDrawable,就首先需要创建一个Bitmap对象,可以理解为一个"画布",然后接着创建一个Canvas对象并传入之前创建的Bitmap对象,这样我们就可以利用Canvas提供的绘制API在Bitmap这个"画布"上作画了,接下来直接调用Drawable的draw()方法并传入Canvas,就可以将Drawable中的显示内容绘制到我们一开始创建的Bitmap上了,这样就完成了DrawableBitmap的转换




Bitmap系列


简化对Bitmap的绘制操作


我们先看下日常开发中,我们怎么在Bitmap中绘制一点东西:


private fun test4(bitmap: Bitmap) {
val canvas = Canvas(bitmap)
canvas.apply {
//进行一些绘制操作
drawLine(0f, 0f, 100f, 100f, Paint())
}
}

有些繁琐,看下官方库给我们提供了什么便利的扩展实现:


image.png


帮助我们创建好Canvas对象,并且方法参数是一个接收者为Canvas的函数类型,这意味我们可以直接在外部传入的lambda中进行绘制操作:


private fun test4(bitmap: Bitmap) {
bitmap.applyCanvas {
//进行一些绘制操作
drawLine(0f, 0f, 100f, 100f, Paint())
}
}

简化Bitmap创建


1.createBitmap()创建指定大小和像素格式的Bitmap


image.png


还是简化了创建Bitmap的操作,虽然很小。


2.scale()缩放(压缩)Bitmap


image.png


这个也是我们常用的通过降低分辨率压缩Bitmap大小的一种方式。


操作Bitmap中的像素点


1.Bitmap.get(x: Int, y: Int)获取指定位置的像素点RGB值


image.png


经典的运算符重载函数,代码中可以直接val pointRGB = bitmap[100, 100]使用。


2.Bitmap.set()设置某个点的RGB像素值


image.png


同样也是个运算符重载方法,代码中直接bitmap[100, 100] = Color.RED使用。


3.Bitmap.contains()判断指定位置点是否落在Bitmap


image.png


运算符重载方法,直接Point(100, 100) in bitmap使用


color系列


普通扩展属性获取颜色的A、R、G、B


image.png


使用如下:


private fun test10(@ColorInt value: Int) {
val a = value.alpha
val r = value.red
val g = value.green
val b = value.blue
}

解构获取颜色的A、R、G、B


image.png


带有operator修饰componenX就是解构方法,X和参数声明的位置一一对应:


private fun test10(@ColorInt value: Int) {
val (a, r, g, b) = value
}

向我们常见的data classHashMap都实现了类似的解扩展。


转换颜色Color对象


1.Int.toColor()整形颜色转换Color对象


image.png


2.String.toColorInt()实现字符串转Color对象


image.png


这个应该比较常用,直接"#ffffff".toColorInt()即可


Rect系列


解构获取左、上、右、下的值


image.png


熟悉的解构,使用和上面一样(RectF也同样提供了相同的解构方法),如下:


private fun test10(rect: Rect) {
val (left, top, right, bottom) = rect
}

缩放Rect范围


下面是扩充Rect范围的API:


image.png
image.png


image.png


使用如下:


private fun test10(rect: Rect) {
val rect1 = rect + rect
val rect2 = rect + 10
val rect3 = rect + Point(100, 200)
}

同样也提供了minus()缩减Rect范围


Rect间取交集、并集等


image.png


image.png


判断某个点是否落在Rect


image.png


使用:Point(11, 11) in rect


Point、PointX系列



下面的扩展方法无非就是解构、通过运算符重载控制Point位置,上面已经讲了一大堆这样的使用,大家走马观花的看下就行,有个印象即可。



经典的解构取值方法


image.png


操作Point的位置


image.png


image.png


总结



上面的内容已经把graphics包下提供的扩展工具讲的七七八八了,大家主要是有个印象就行,使用的时候能想起来用更好,如果需要详细了解的请直接参考该包下的源码即可。




关于探索官方core-ktx库的还剩下大概最后一篇文章讲解了,希望可以在这个系列中带给大家一些帮助,提供大家的开发效率。并且通过学习官方库中的封装思路,也同样会给大家日常开发中小优化带来启发。


作者:长安皈故里
链接:https://juejin.cn/post/7121718556546482190
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

Android 官方模块化方案解读

前言 前不久整理下 Now In Android 项目是如何做模块化的(Android 官方项目是怎么做模块化的?快来学习下),没想到官方不久前也在官方文档中更新了模块化相关的章节,下面就一起看一下官方文档中是如何描述 Android App 模块化的。 概述...
继续阅读 »

前言


前不久整理下 Now In Android 项目是如何做模块化的(Android 官方项目是怎么做模块化的?快来学习下),没想到官方不久前也在官方文档中更新了模块化相关的章节,下面就一起看一下官方文档中是如何描述 Android App 模块化的。


概述


首先思考下,为什么要做模块化或者说如果不做模块化会有什么问题?


模块化解决了什么问题?


随着项目以及业务的不断迭代,整个项目中代码数量会不断的增长,在这个过程中代码的可扩展性、可读性都会随着时间的推移而下降。


解决这个问题方式大致有两种,一种是定期 Review 代码架构并做一些防劣化措施,从而保证项目的质量不会随着项目的增长而下降。但是这种方式在需求快速迭代的团队中由于工期及人力投入的原因是很难被执行的。另外就是需要团队中有能够敏锐发现代码劣化倾向的人,从而发起 Review,这个角色通常由技术专家或者是架构师承担。这种方式可操作性并不高。


另外一种解决思路就是将复杂问题拆解成多个小的、简单问题,而对简单问题的处理通常并不需要特别依赖高级人才。这种方式就是分而治之,将大型、复杂问题拆解成一个个小的、简单问题,从而可以做到各个击破。这种方式对应的工程手段之一就是模块化


什么是模块化?


模块化简单讲就是把多功能、高耦合的代码逻辑拆散成多个功能单一、职责明确的模块(module)。一个项目模块化后的整体架构大致如下:


图片



注::app:phone 是模块名,app表示是子目录的形式,具体可以参考我给 Now In Android 提交的 PR 241



模块化有哪些好处?


模块化的好处有很多,主要集中表现在提高代码库的可维护性和整体质量上。下表总结了主要优势。























优点概括
多 App复用模块化是在多 App 开发中复用代码逻辑的基础。每个模块都是一个独立有效的构建单元。
严格的访问权限模块可以很好做控制代码的可访问性,模块内部私有的逻辑添加 internal 或者 private 修饰。防止代码被其他模块引用而导致的过度耦合。
可定制的交付可以使用动态下发( Play Feature Delivery )功能(注:国内应用商店基本不可用) 。

上述好处只能通过模块化才能实现。以下是不使用模块化也能实现的好处,但模块化可以更好地实现。































优点概括
可扩展性在代码紧密耦合的代码仓库中,一个微小的更改都有可能导致牵一发动全身。一个好的模块化的项目会做到代码解耦(关注点分离原则),从而规避了上述问题。
负责人一个模块可以有一个专门的负责人,负责维护代码、修复错误、添加测试和 CodeReview 。方便代码与人员的双重管理。
封装封装意味着代码的每一部分都应该对其他部分有尽可能少的了解(最少知道原则)。孤立的代码更容易阅读和理解。
可测试性可测试性描述了测试代码的难易程度。可测试代码是可以轻松独立测试组件的代码。小类总比大型类容易测试,依赖少的类总比依赖多的类容易测试。
构建时间模块化可以提升编译速度,例如增量构建、构建缓存或并行构建。

模块化常见的误区


任何一项技术都有好坏,模块化也是如此。对模块化使用不当,可能也会引入一些问题。一些常见的问题如下:




  • 太细粒度:太细粒度就意味着项目中会有很多模块,而多模块又会导致编译耗时以及多模块配置同步的问题;




  • 太粗粒度:太粗粒度就意味着项目中会有很少模块,基本不能完全发挥出模块化的好处;当做这是一个循序渐进的过程,太粗粒度可以是一个开始不应该是一个结束;




  • 太复杂:将项目模块化并不总是有意义的。如果在可预见的未来项目的增长并不明确,保持现状也是一种不错的选择。




高内聚低耦合原则


没有适合所有项目的模块化方案。下面讲下模块化开发过程中可以采用的一些一般规则和常见模式。


高内聚低耦合是模块化项目的一种属性。耦合衡量模块相互依赖的程度,内聚衡量单个模块的元素在功能上的相关性。应该争取低耦合和高内聚:




  • 低耦合模块不应该了解其他模块的内部工作原理,这意味着模块应该尽可能地相互独立,以便对一个模块的更改对其他模块的影响为零或最小。




  • 高内聚意味着模块应该仅包含相关性的代码。在一个示例电子书应用程序,将书籍和支付的代码混合在同一个模块中可能是不合适的,因为它们是两个不同的功能领域。




如果两个模块严重依赖彼此,那么它们实际上应该作为一个系统运行。相反,如果一个模块的两个部分不经常交互,它们可能应该是单独的模块。


小结


模块化就是一种将复杂问题拆解成多个简单问题的工程化方案。所以如果你觉得项目还没有那么复杂,引入模块化的收益将没有那么明显。这里的复杂性包括多 App 复用、严格的代码可见性以及 Google Paly 的动态下发(Play Feature Delivery)。当然,如果希望在可扩展性、所有权、封装或构建时间中受益,那么模块化是值得考虑的事情。


模块的类型


App 模块


应用程序模块是应用程序的入口点。它们依赖于特性(feature)模块,通常提供导航能力。使用多渠道打包方案,单个应用程序模块可以编译为许多不同的二进制文件。


如,根据使用用途可以分为正式版本 App、 测试 Demo App,其中正式版本 App 根据其发布平台又可以分为 智能手机、汽车、电视、可穿戴设备等,其依赖关系大致如下:


图片


特性(Feature)模块


特性是 App 中功能相对独立的部分,通常对包含一个页面或一系列密切相关的页面,例如注册或结帐流程。如果您的应用具有底部栏导航,则很可能每个目的地都是一项功能。


特性模块中一般会包含页面或路由(destinations)。因此,在模块内部需求处理 UI Layer 中相关的内容。特性模块中不必局限于单个页面或导航目的地,可以包含多个页面。特性模块依赖于数据模块。


图片


数据(Data)模块


数据模块通常包含 RepositoryDataSource 和实体类。数据模块主要有三个职责:



  1. 封装某个领域的所有数据和业务逻辑:每个数据模块应该负责处理代表某个领域的数据。它可以处理多种相关类型的数据。




  1. 将 Repository 公开为外部 API:数据模块的公共 API 应该是 Repository,因为它们负责将数据公开给 App 的其余部分。




  1. 对外隐藏所有实现细节和 DataSource:DataSource 只能由同一模块的 Repository 访问,对外是隐藏的状态。可以通过使用 Kotlin 的 private 或者 internal 关键字来强制执行此操作。


图片


公共(Common)模块


公共模块,也称为核心模块或者基础模块,包含其他模块经常使用的代码。以下是常用模块的示例:



  • 基础 UI 模块:如果 App 中使用自定义 View 和样式(style),应该考虑将他们统一封装到一个模块中,以便可以复用。也就是大家通常所说的 UI 规范库,这可以使 UI 在不同特性模块之间保持一致。

  • 打点统计模块:打点统计模块,一般是使用市面上现有的 SDK,当然也有自研的。取决于项目需要。

  • 网络模块:网络库模块,通常是对三方网络库(如 OhHttp)的封装,简化自定义配置时,减少不必要的重复代码。

  • 工具模块:工具类,也称为帮助类,通常是在应用程序中重用的小段代码。如文件读写、电子邮件验证器或自定义运算符等。


App 模块化整体汇总形式大致如下:


图片


\


模块间通信



注:此部分结合自身经验以及官方文档整合而得,请批判性观看。



项目虽然采用了模块化方式进行开发,减少了代码之间的耦合,但是模块间的通信仍是不可避免的事情。模块间相互依赖的方式在工程上并不可行,Android 项目并不允许模块间的相互依赖。通常的做法就是引入第三个中介模块,模块间通过中介模块来进行通信。


中介模块在依赖形式上有可以分为两种,一种是向下抽象,抽离出两个模块共有的数据层逻辑,模块通过回调或者是数据流的方式监听逻辑的变化;另一种形式是抽象,在宿主 App 模块中组合拼装两个模块的逻辑。前者是下沉逻辑,后者是控制反转。


下面我以一个简单的业务场景举例:在购书籍列表页面,选择特定的一本书并下单购买。


图片


抽离基础模块


大致流程如下:



  1. 分别在 :feature:home 与 :feature:checkout 设置对基础依赖模块的初始化操作,如接口实现、回调监听等;




  1. 在 :feature:home 模块内通过依赖的 :data:books模块,调用其 navigate() 方法跳转至 :feature:checkout 模块;




  1. 在 :feature:books 模块内将跳转事件通过 onNavigationBook 分发出去,由 :feature:checkout模块模块实现;

  2. :feature:home 模块通过 :data:books模块提供的 onPaymentCanceled() 回调来监听对应的结果;



这种通讯方式随着业务的迭代,底层通用的数据模块会不断膨胀,耦合也会越加严重,所以并不建议使用此方式。官方文档中示例方式则是交由调用者处理,各自模块也相对内聚。


依赖调用者模块


这种方式一般是依赖 app 模块来组装各个业务模块的业务逻辑,也就是一样意义上的胶水代码。大致方式如下:



  1. :app 模块调用 :feature:home提供的 navigate 函数跳转至 home 页面,并通过 onCheckout 函数将对应的结果回调出去;

  2. :app 模块监听到 onCheckout() 回调后,调用 :feature:checkout模块提供 navigate 函数进行跳转,并通过 onPaymentCanceled() 回调将结果抛出;



此种方式使得各业务模块的逻辑更加内聚,虽然这种方式的结果及事件也能很好的暴露出去。但是如果这种方式在大型项目中使用时会导致产生大量的胶水代码(频繁的初始化以及 Callback 设置),不利于项目中后续迭代。为了解决胶水代码问题,可以在项目中引入依赖管理的框架。


依赖管理框架


依赖管理不仅可以很好地解决对象繁琐的初始化逻辑,还可以很好的实施控制反转的编码思想。目前主流的依赖管理的方案有两种,分别为依赖注入与服务查找:




  1. 依赖注入:依赖注入使类能够定义其依赖项而不构造它们。在运行时,另一个类负责提供这些依赖项。一般是使用注解方式,适合大中型项目,如 Hilt




  2. 服务查找:服务查找的方式一般是维护一个注册表,所需的依赖都可以在这个注册表中查找;一般是使用相对简单,适合中小型项目,如 koin




官方推荐使用 Hilt 来进行依赖管理,如果你的项目中在使用其他的依赖管理方式,并且没有遇到问题的话,那么继续使用当前的框架即可。


依赖管理的方式不仅可以使用模块间通信,在模块内部通信也是一种很好的解耦与复用的手段,只是在模块间通信会流程变得更加复杂,也更能突出依赖管理的重要性。整个依赖管理在模块化整体架构大致如下图:


图片


以服务查找方式实现,其大致流程(忽略模块内通讯)如下:



  1. 数据层可以将对应的数据注入到 DI 容器中;

  2. 在特性模块中可以获取到数据层提供的数据,同时也可以将自身的数据注入到 DI 中;

  3. 在 app 模块获取所需的数据或特性功能;


小结


其实整个模块间的通信可以按照其行为方式分为两大类,一种是不同模块间页面直接的跳转,另一种则是不同模块间的数据交互。


对于前者有各种路由框架,Android 官方也提供了 Navigation 库;对于后者也有不少框架,如 Dagger2、Koin,Android 官方也提供了 hilt 库;当然社区中也有两者都能满足的库,如阿里的 ARouter


官方文档中只是提到了比较原始的方式,也是对初学者比较友好的方式。大家可以根据自己项目中的现状选择适合自己的即可。


最佳实践


虽然开发模块化 App 没有唯一正确的方式,但是以下的一些建议仍可以使代码更具可读性、可维护性和可测试性。


保持配置一致


每个模块都会引入配置开销。当模块数量达到某个阈值,则管理一致的配置将成为一项挑战。下面的配置可以减少这部分的工作量:





  • 使用 约定插件 在模块之间共享 build.gradle 中的构建逻辑。


尽量少暴露


模块的公共接口应该是最小的,并且仅仅只公开必需公开的。它不应该在外面暴露任何实现细节。尽可能的缩小外部调用者的可访问范围,使用 Kotlin 的privateinternal 可以很好的做到这一点。在模块中声明依赖项时推荐使用implementation,而非apiimplementation不会透传依赖,从而可以做到缩短构建时间。


尽量使用 Kotlin 和 Java 模块


Android Studio 支持三种基本类型的模块:



  • 应用程序模块AndroidManifest.xml是您的应用程序的入口点。它们可以包含源代码、资源、资产和. 应用模块的输出是一个 Android App Bundle (AAB) 或一个 Android 应用程序包 (APK)。




  • 库模块 依赖项与应用程序模块具有相同的内容。它们被其他 Android 模块用作依赖项。库模块的输出是一个 Android Archive (AAR),在结构上与应用程序模块相同,但它们被编译为一个 Android Archive (AAR) 文件,以后可以被其他模块用作。库模块可以在许多应用程序模块中封装和重用相同的逻辑和资源。




  • Kotlin 和 Java 库不包含任何 Android 资源、资产或清单文件。


由于 Android 模块会带来开销,因此您最好尽可能使用 Kotlin 或 Java 类型。


总结


以上内容是根据官方文档整理而得,对部分内容做了结构调整、重新绘制了 UML 图以及添加了些自己的经验感悟。对原文整理会存在疏忽遗漏的部分,请大家到官方文档中查看,做到“交叉验证”。


如果你想快速搭建一个全新的 Android 模块化项目,可以到 architecture-templates 仓库中 clone,可以说是非常便捷了。


虽然模块化技术在国内并算不上什么新技术了,但是我仍然看到了一些积极的影响:



  • 对于初学者而言,有一套相对详细指导文档并且完整示例的项目(Now in Android)可以参考,从而可以快速搭建模块化的项目;

  •  对于已经实践过模块化项目团队,我相信仍能从官方文章中学习到一些新思路及方法,以复盘的视角审视自己团队中的模块化方案的优劣;


当然,模块化本身并不是终点。模块化之后还有组件化,组件化之后还有壳工程和动态化。每个技术阶段对应到团队发展的阶段,那些适合目前团队现状的技术才是”好“技术。


作者:RethinkAndroid
链接:https://juejin.cn/post/7142884855091560479
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 收起阅读 »

Android 三行代码实现高斯模糊

设计:有了毛玻璃效果,产品的逼格直接拉满了呀我:啊,对对对。我去 GayHub 上找找有没有好的解决方案吧设计:GayHub ???寻找可行的方案要实现高斯模糊的方式有很多,StackBlur、RenderScript、Glide 等等都是不错的方式,但最简单...
继续阅读 »

设计:有了毛玻璃效果,产品的逼格直接拉满了呀

我:啊,对对对。我去 GayHub 上找找有没有好的解决方案吧

设计:GayHub ???

寻找可行的方案

要实现高斯模糊的方式有很多,StackBlur、RenderScript、Glide 等等都是不错的方式,但最简单直接效率最高的方式,还得是上 Github。

搜索的关键词为 android blur,可以看到有两个库是比较合适的, Blurry 和 BlurView。 这两个库 Star 数比较高,并且也还在维护着。

于是,便尝试了一番,发现 BlurView 比 Blurry 更好用,十分推荐上手 BlurView

image-20220917223800119

Blurry

  • 优点:API 使用非常简洁,效果也不错,提供同步和异步加载的解决方案
  • 缺点:奇奇怪怪的 Bug 非常多,并且只能作用于 ImageView
    • 使用时,基本会遇到这两个 Bug:issue1 和 issue2 。
    • issue1(NullPointerException) 已经有现成的解决方案
    • issue2(Canvas: trying to use a recycled bitmap) 则从 17 年至今毫无进展,并且复现概率还比较高

BlurView(推荐)

  • 优点:使用的过程中几乎没有遇到 bug,实现时调用的代码较少。并且,可以实现复杂的模糊 View

  • 缺点:需要在 xml 中配置,并且需要花几秒钟的时间理解一下 rootView 的概念

  • 使用方式:

    XML:

    <androidx.constraintlayout.widget.ConstraintLayout
    ...
    android:id="@+id/rootView"
    android:background="@color/purple_200" >

    <ImageView
    ...
    android:id="@+id/imageView" />

    <eightbitlab.com.blurview.BlurView
    ...
    android:id="@+id/blurView" />

    </androidx.constraintlayout.widget.ConstraintLayout>

    MainActivity#onCreate:

    // 这里的 rootView,只要是 blurView 的任意一个父 View 即可
    val rootView = findViewById<ConstraintLayout>(R.id.rootView)
    val blurView = findViewById<BlurView>(R.id.blurView)
    blurView.setupWith(rootView, RenderScriptBlur(this))
  • 实现的效果:

    使用前:

    181663475092_.pic

    使用后:

    171663475091_.pic
  • Tips :

    • 在 BlurView 以下的 View 都会有高斯模糊的效果

    • rootView 可以选择离 BlurView 最近的 ViewGroup

    • .setBlurRadius() 可以用来设置卷积核的大小,默认是 16F

    • .setOverlayColor() 可以用来设置高斯模糊覆盖的颜色值

    • 例如如下参数配置时可以达到这样的效果:

      blurView.setupWith(rootView, RenderScriptBlur(this))
      .setBlurRadius(5F)
      .setOverlayColor(Color.parseColor("#77000000"))
      191663495988_.pic


作者:很好奇
链接:https://juejin.cn/post/7144663860027326494
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

收起阅读 »

5年前端,我学会接受自己的平凡

前言前端工作之余,回顾了一下自己的职业生涯,感慨万千,每当经历过一些事,对个人对工作以及这份职业都会有新的感悟,只希望以一个过来人的经验和感悟,与诸君共勉~青春岁月本人17年毕业于某211高校,和很多大学生一样,每天基本3点一线,当我现在回首我的大学时光,是快...
继续阅读 »


前言

前端工作之余,回顾了一下自己的职业生涯,感慨万千,每当经历过一些事,对个人对工作以及这份职业都会有新的感悟,只希望以一个过来人的经验和感悟,与诸君共勉~

青春岁月

本人17年毕业于某211高校,和很多大学生一样,每天基本3点一线,当我现在回首我的大学时光,是快乐的,但也有后悔的地方,就是花费了很多时间在lol上,上课就是玩手机,下课就是看视频玩游戏,当时觉得很快乐,现在觉得错失了很多的时光,每到学期末,就开始读书复习,幸运的是,大学4年都没有挂科,除了论文答辩坎坷了点,第二次答辩顺利结业了。

毕业

我一共有过3个工作经历,说起第一段工作经历,那真是很怀念,邻近毕业了,没打算考研,就一股脑去找工作了,当时互联网比较火热,外加计算机课学过js基础,就开始拿了一本红宝书进行学习,那会才开始写下第一行代码console.log('hello world~'),这算是入行的一个契机;

就这样看了1个月的书,就开始写简历,跑各种各样的宣讲会,那会经常跑中大和华工去参加宣讲会,记忆犹新的有两个事,有一次去参加一个游戏公司的宣讲会,现场面试,我投递的是测试岗位,我现在记得问了我什么是黑盒什么是白盒测试,我一无所知,后面他问我程序设计学的怎么样,年轻的我说才刚开始学,他说如果我想走写代码这条路,就要坚持下去,不要转投其他的岗位。或许,这坚定了我选择前端的决心。

第二个记忆犹新的事,是在一个酒店,参加唯品会的校招面试,笔试貌似是线上的,当时我还记得面试官问了我盒子模型是什么,margin属性的设置规则(上右下左),这些我统统答不上来,后面他聊起了公司伙食好,他发福了好多哈哈哈~

总的来说,我的校招并不顺利,从并不知道自己能做什么,找什么样的工作,以及后面找到想做的事了,但是因为没有准备,也错过了很多的机会,导致了我秋招没找到像样的工作。

秋招

就这样,秋招快结束了,焦虑过彷徨过,后面又参加了一个在天河华师的宣讲会,现场笔试面试,终于拿到了offer,如果我没记错的话,当时的薪资是6500一个月,放到如今的现在,比90%的毕业生的现在薪水都要低,但那是我最快乐的一年,穷并快乐着。

工作

后面开始就是疯狂的吸收学习成长,在业务中成长,第二年开始跳到c厂,工资翻倍涨到13k,在c厂体验到了大公司的开发规范,先进的基础设施,学习成长很多,于是一呆又是2年。

工作3年后,面临着异地问题,于是双双从广州,顺德,一起奔赴深圳,也就是在工作的第四年,薪资终于涨到了20k,也是很多毕业生刚毕业就能拿到的薪资。

但是时代变化的太快了,13年上学,17年毕业参加工作,在我的青春读书的岁月里,人们谈论最多的并不是买房,房价也还没变成勒死年轻人的绳索,彼时互联网还是新兴产业,朝阳崛起,没有现在的反垄断和中概股暴跌。

于是乎到了现在,虽然收入每年都在增长,但是我已经不再是当年那个满口“路飞,橡胶橡胶xxx”的快乐的少年,焦虑焦虑还是焦虑

思考

其实,对于前端这份工作,我一直以来的心态就是平凡,我干的这份职业,并不值得对亲朋好友吹嘘,我干的这份工作,也仅仅是一份工作,他并不比扫大街送外卖这份职业高等好多,因为总归到头,我们都是一个大城市里的打工人。

我甚至觉得这份工作,只要正常念完中学的孩子,进培训班培训半年,也一样能做,所以我们没有资格对这份工作报以骄傲。

总有亲朋好友说:谁谁小孩进了字节,谁谁小孩进了腾讯,好像就能高人一等了,殊不知公司体量越大,裁员也会越多,谁都有生涯到头的时候吧。

最后,我想以一个平凡人的角度,希望正在挣扎的你能接受自己平凡

因为,很多的这样的你我,都是一样的平凡人

我们注定成不了金字塔里的顶尖

我们注定成不了行业中的翘楚

我们注定成不了传说中的扫地僧

我们注定成不了技术中的大拿

不管你究竟付出了多大的努力,也是如此。

所以,我希望这样的你,能宽恕自己的平凡,花更多的时间在陪伴家人,拓展社交,培养兴趣爱好,甚至是可以去养花花草草,有机会的话,多发展发展副业,人脉,如果能学会投资理财,这是最好的。

年近30,才有所这样的领悟,只是希望技术不要成为你的唯一,毕竟生活和健康,才是你真正需要拥有的东西

年近30,我接受这样平凡的自己

就像许巍的歌“曾梦想仗剑走天涯,看一看世界的繁华”

我也曾拥有每个前端人的那个最初的梦想“努力钻研技术,出任公司ceo,赢取白富美,走上人生巅峰”

但是繁华过后,确是生活的平凡和美好

作者:lemonwater

来源:https://juejin.cn/post/7145022995172425741

收起阅读 »

糟糕的 Kotlin 语法糖

这几天在 review 同事的代码的时候,发现一块有意思的代码,我将其写成对应的伪代码如下:class UserViewModel(val userUsecase: UserUsecase) {    // 根据 userId 获取 use...
继续阅读 »

这几天在 review 同事的代码的时候,发现一块有意思的代码,我将其写成对应的伪代码如下:

class UserViewModel(val userUsecase: UserUsecase) {

   // 根据 userId 获取 userName
   fun getUser(userId:Int) {
       val name = userUsecase(userId).name
  }
   
}

class User(val name: String, val age: Int) {}

起初在看到这段代码的时候,觉得十分反人类,在 Kotlin 中,对象的初始化可以省略 new 操作符,也即类后面再配个 () 即可,为啥一个初始化的对象还能继续用 (),在直观的感受下,我以为是初始化了一个对象,唯一让我觉得不像是初始化的就是 userUsecase 开头并不是大写,这才打消我认为他是初始化对象的疑虑。

在我想点进去看下根据 userId 获取 User 的过程,我无论追踪代码,都无法跳转到真正的逻辑代码调用处,点击 userUsecase 会直接跳转到 UserViewModel 的构造方法,点击 name 会跳转到 User 对象,这让我很苦恼。

我不得不点击 UserUsecase 类去看下里面的代码,这对于 review 人来说简直是灾难,但为了解决问题,先妥协,再一探究竟。

进入 UserUsecase 类,伪代码如下:

class UserUsecase {
   operator fun invoke(userId: Int): User {
       // 从数据库中根据 id 获取 User 数据
       // 返回 User 数据
       return User("lisi", 30)
  }
}

看到了奇怪的 invoke 函数,并且是用了 operator 操作重载符,为了了解这种语法,我在 Kotlin 中文网查了下该语法的使用,在调用操作符章节中有所说明:


对象() 等价于 对象.invoke()()内为函数的参数,也即我们上面的那段代码,可以翻译一下:

class UserViewModel(val userUsecase: UserUsecase) {
   fun getUser() {
       val name = userUsecase(1001).name
       // 等价于
       val name2 = userUsecase.invoke(1001).name
  }
}

也可以用 Kotlin Decompile 看下结果:


需要说明的是,对象() 这种写法是有条件的:

  • 必须用 operator 修饰方法

  • 方法名称必须是 invoke

  • invoke 参数可以多个,不做限制

由于 invoke 函数参数不加限制,这又带来了一个问题,如果重载了多个 invoke 函数,就更不知道业务方在调用的时候是做了什么事情,依然不得不进入代码才能知道逻辑。

上面的示例给的已足够简单,但实际在我们的业务中,比这还复杂,invoke 函数被封装到了父类,当我点进去的时候根本找不到 invoke 函数,只能往上查看父类有没有,在找到 invoke 函数时才发现,他最终调用了个抽象方法,该抽象方法由子类实现,我又不得不返回到子类查看这个方法,最终才敲定这个方法做了什么逻辑。

总结:

虽然 operator invoke 可以省略调用方写函数名这个过程,但需要注意的是,代码无论是类名还是方法名还是变量名,一定要做到见名识意,显然,他已经破坏了这个规则,让 review 人很抓狂。

我也很理解大家对 Jetpack 的热爱,这种写法在官方也有出现,可以参考 Domain Layer 这章。但我想说的是,省略方法名这个过程真的有必要吗?写代码到底是为了炫技还是为了让别人能看懂自己的代码呢?


作者:codelang
来源:juejin.cn/post/7081112122179977224

收起阅读 »

我在 Shopee 毕业了

大家好,2022年 9 月 19 日,我成为了一名前 Shopee 员工,是的,我毕业了。2022年 9 月 19 日可以被「转名」为 Shoppe 黑色星期一,原因很简单,Shopee 全公司开启大规模裁员,当然今天不会是最后一天,在接下来的几天可能还会持续...
继续阅读 »

大家好,2022年 9 月 19 日,我成为了一名前 Shopee 员工,是的,我毕业了。

2022年 9 月 19 日可以被「转名」为 Shoppe 黑色星期一,原因很简单,Shopee 全公司开启大规模裁员,当然今天不会是最后一天,在接下来的几天可能还会持续裁员。


早上刚到公司,同组的同事都在开玩笑说「虾皮大群发不了消息了,群禁言了,这难道是要裁员了」,当时大家都不以为然,以为真是一个玩笑。

然后没有过多久,大约 10点半左右,开启了一个全员线上会议,会议全程 7 分钟左右。会议由 CEO David 主持,会议直接进入主题,这次 David 没有往昔的和颜悦色,全程只有 David,败家大佬 YC 并没有出现。之前这样的会议都是至少一个小时起步的,今天只有短短的几分钟,内容很简单,总结一句话就是:「我们将开启裁员行动」。

会议结束后,行动立即开始,是的,立即开始。会议刚结束,同组成员就马上收到 HRBP 的邀请,1 VS 1 面谈,面谈最长 10 分钟,快的同学 5 分钟 over。

面谈只谈补偿,不谈其他无用的,在 Shopee 这么久,从来没有一个会议这么高效。面谈完,不需要任何的交接,交还电脑和工牌,直接收拾东西走人即可。

整个流程快速高效,不拖泥带水。

「毕业」前的叮铃

中秋前就有风声说中秋后会有大动作,还算人性的是,让大家拿了中秋礼盒过一个好的中秋之后在裁员。中秋节来之后,就收到了全员邮件「降本」,缩减成本,12~18月内会有更多的措施。还有机智的同学提前让老 leader 拉一把转组了去了波及小的团队。

「毕业」先前条件

  1. leader 上报维护系统,必须人员/模块负责人/组内人员排名。

  2. hr 根据条件1,以及裁员成本,人力成本制定排名。

  3. 极少高潜应届生留存。

  4. 项目组确定裁员数量。

「毕业」优先级

综合先前上面四点,裁员优先级大致:

  1. 非高潜应届生

  2. 试用期

  3. 年限短拿过c

  4. 年限长拿过c

  5. 年限短没拿过a/非核心

  6. 年现长没拿过a

  7. 年限短拿过a

  8. 年限长拿过a/非核心

  9. 基本团灭

「毕业」补偿

  • n + 2,base = 总包 / 12

  • 股票未归属部分,按时间进行归属,9月底可拿

  • 年假也会转换为钱进行补偿

「毕业」重灾区

  • IM

  • 金融

  • 支付

  • 供应链

  • ...

这部分业务裁员比较严重,我在的业务团队裁员 60 %。裁员少的团队15%~30%,裁员多的团队100%。

最后

「毕业」对我个人来说,感觉也不是一个坏事,无车、无房、无贷款、无娃,没有任何的压力,并且我还拿了钱,拿钱走人也不见得是不好的事,转换一个思路,作为打工人的我们本来的工作就是拿钱办事!

塞翁失马焉知非福,对于裁员这种事情看开点,洗洗睡,明天还是新的一天。放平心态,很多事情不是我们能决定的,所以不用给自己太多的压力。

大家要切记切记:社保不能断哈,这个是重点!

拿着补偿先在家休息一段时间,做一些在想做的事情,因为现在最多的就是时间。


接下里几天持续更新最新消息,大家一起吃瓜,😁。


作者:拜小白
来源:juejin.cn/post/7145282164932739109

收起阅读 »

被「羊了个羊」逼疯后,鹅厂程序员怒而自制「必通关版」|GitHub热榜

「羊了个羊」有多恶心?能逼程序员气到撸起袖子自己上……这两天,GitHub上就出现这么一个仿制版,名曰「鱼了个鱼」。不同于以「极低通关率」肝死玩家的原版,此版作者放出话来——没广告!可自定义关卡和图案!道具无限!。甚至可以定制出这(离)样(谱)的界面:目前,该...
继续阅读 »

「羊了个羊」有多恶心?

能逼程序员气到撸起袖子自己上……

这两天,GitHub上就出现这么一个仿制版,名曰「鱼了个鱼」


不同于以「极低通关率」肝死玩家的原版,此版作者放出话来——

没广告!可自定义关卡和图案!道具无限!

甚至可以定制出这(离)(谱)的界面:


目前,该项目已登GitHub热榜,获297个Star。(链接已附在文末)


比「羊」更让人舒适

先看看这款「鱼了个鱼」体验如何。

从最简单模式开启,简直不要太Easy,道具都无需使用。


再看中等和困难模式,稍有难度,还好有道具!

原版的洗牌、撤回、移出可无限次使用,还有更多玄妙功能。

比如透视,能看到最下方两列叠起来图案依次是什么,这感觉,相当于斗地主把最后三张看完了。


再比如圣光,能把一大堆图案下面的图层从灰变白,看得更清楚。


最逆天的还是破坏功能,直接消掉3个同样图案:


也就是说,一直狂按这个道具能直接通关。


值得一提的是,通关后祝贺画面是这个:


建议作者优化下前端,直接换成这个:


怒而自制必通关版

据作者介绍,自己也是玩「羊了个羊」几十次,其间,他用尽道具,看了几十遍借贷广告,向富家千金反复求婚,仍然过不了第二关——

他发现事情不对劲。

由于方块生成完全随机,那越到后期,越来越多方块叠压在一起,可选方块变少,自然越来越难,经常无解也是常事。

另一方面,正是极低的通关率让每个「自以为必胜」的玩家上头得不行,形成了上瘾感。


于是……他怒而自制一个必能通关的版本。

要求嘛,务必无广告,务必道具无限,要能自定义难度和图案,那更是一件美事儿。

具体到原理,作者提出四大纲领。

首先,游戏全局参数设置上,需要将槽位数量、层数等变量抽取成统一的全局变量,每当修改一处,系统自动适配,此外,作者还开放了参数自定义——

嫌槽位不足?可以自己多加一个!


其次是整体网格设计。

为了能快速做出游戏,作者直接将画布分为24×24的虚拟网格,类似一个棋盘——

每个网格又被划分成3×3的小单元,各层图案生成时,会相互错开1-2个单元,形成层层交叠、密密麻麻的样子。


第三步是设计随机生成块的图案和坐标。

先根据全局参数计算总块数,游戏难度越高,块数和相应层数也越多,然后作者用shuffle函数打乱存储所有动物图案的数组,再依次,把图案重新填充到方块中。

至于如何生成方块坐标,直接让程序随机选取坐标范围内的点,同时随层级变深,坐标范围也越来越小,造成一种——

越往深了去,图案越拥挤,难度相应越高的效果。


大致分布规律就是越「深」层越「挤」

最后,设定上下层块与块的关系。

作者先给每个块指定一个层级属性,随机生成时,给相互重叠的块绑定层级关系,确保消掉上层块,才能点击下层块。

基于上述思路,作者熬夜爆肝几个小时,就把游戏雏形做出来了,还放到GitHub上将代码开源——

他感慨道,总算是满足了自己的通关夙愿。


作者介绍

事实上,「鱼了个鱼」项目作者「程序员鱼皮」已小有名气。

据其个人公开资料显示,「程序员鱼皮」98年出生,现在鹅厂,从事全栈应用开发,同时,也是腾讯云开发高级布道师。

工作之外,鱼皮利用业余时间做了很多入职大厂经验、技术干货和资源分享,据他称,在校期间就带领工作室建设了几十个校园网站。


最后,附上「鱼了个鱼」在线体验链接,收获通关喜悦(狗头):

https://yulegeyu.cn

参考链接:
[1]https://github.com/liyupi/yulegeyu
[2]https://www.bilibili.com/video/BV1Pe411M7wh
[3]https://mp.weixin.qq.com/s/D_I1Tq-ofhKhlp0rkOpaLA

来源:詹士 发自 凹非寺

收起阅读 »

开发这么久,gradle 和 gradlew 啥区别、怎么选?

使用 Gradle 的开发者最常问的问题之一便是: gradle 和 gradlew 的区别? 。 这两个都是应用在特定场景的 Gradle 命令。通过本篇文章你将了解到每个命令干了什么,以及如何在两个命令中做选择。 快速摘要 如果你正在开发的项目当中已经包...
继续阅读 »

使用 Gradle 的开发者最常问的问题之一便是: gradlegradlew 的区别?


这两个都是应用在特定场景的 Gradle 命令。通过本篇文章你将了解到每个命令干了什么,以及如何在两个命令中做选择。



快速摘要


如果你正在开发的项目当中已经包含 gradlew 脚本,安啦,可以一直使用它。没有包含的话,请使用 gradle 命令生成这个脚本。


想知道为什么吗,请继续阅读。



gradle 命令


如果你从 Gradle 官网(gradle.org/releases)下载和安装了 Gradle 的话,你便可以使用安装在 bin 路径下的 gradle 命令了。当然你记得将该 bin 路径添加到设备的 PATH 环境变量中。


此后,在终端上运行 gradle 的话,你会看到如下输出:



你会注意到输出里打印了 Gradle 的版本,它对应着你运行的 gradle 命令在设备中的 Gradle 安装包版本。这听起来有点废话,但在谈论 gradlew 的时候需要明确这点,这很重要。


通过这个本地安装的 Gradle,你可以使用 gradle 命令做很多事情,包括:



  • 使用 gradle init 命令创建一个新的 Gradle 项目或者使用 gradle wrapper 命令创建 gradle wrapper 目录及文件

  • 在一个 Gradle 项目内使用 gradle build 命令进行 Gradle 编译

  • 通过 gradle tasks 命令查看当前的 Gradle 项目中支持哪些 task


上述的命令均使用你本地安装的 Gradle 程序,无论你安装的是什么版本。


如果你使用的是 Windows 设备,那么 gradle 命令等同于 gradle.bat,gradlew 命令等同于 gradlew.bat,非常简单。


gradlew 命令


gradlew 命令,也被了解为 Gradle wrapper,与 gradle 命令相比它是略有不同的。它是一个打包在项目内的脚本,并且它参与版本控制,所以当年复制了某项目将自动获得这个 gradlew 脚本。


“可那又如何?”


好吧,如果你这么想。让我告诉你,它有很多重要的优势。


1. 无需本地安装 gradle


gradlew 脚本不依赖本地的 Gradle 安装。在设备上第一次运行的时候会从网络获取 Gradle 的安装包并缓存下来。这使得任何人、在任何设备上,只要拷贝了这个项目就可以非常简单地开始编译。


2. 配置固定的 gradle 版本


这个 gradlew 脚本和指定的 Gradle 版本进行绑定。这非常有用,因为这意味着项目的管理者可以强制要求该项目编译时应当使用的 Gradle 版本。


Gradle 特性并不总是互相兼容各版本的,所以使用 Gradle wrapper 可以确保项目每次编译都能获得一致性的结果。


当然这需要编译项目的人使用 gradlew 命令,如下是在项目内运行 ./gradlew 的示例:



输出和运行 gradle 命令的结果比较相似。但仔细查看你会发现版本不一样,不是上面的 6.8.2 而是 6.6.1


这个差异说重要也重要,说不重要也不重要。


但当使用 gradlew 的话可以免于担心由于 Gradle 版本导致的不一致性,缘自它可以保证所有的团队成员以及 CI 服务端都会使用相同的 Gradle 版本来构建这个项目。


另外,几乎所有使用 gradle 命令可以做的事情,你也可以使用 gradlew来完成。比如编译一个项目就是 ./gradlew build


如果你愿意的话,可以拷贝 示例项目 并来试一下gradlew


gradle 和 gradlew 对比


至此你应该能看到在项目内使用 gradlew 通常是最佳选择。确保 gradlew 脚本受到版本控制,这样的话你以及其他开发者都可以收获如上章节提到的好处。


但是,难道没有任何情况需要使用 gradle 命令了吗?当然有。如果你期望在一个空目录下搭建一个新的 Gradle 项目,你可以使用 gradle init 来完成。这个命令同样会生成 gradlew 脚本。


(如下的表格简单列出两者如何选)可以说,使用 gradlew 确实是 Gradle 项目的最佳实践。

你想做什么?gradle 还是 gradlew?
编译项目gradlew
测试项目gradlew
项目内执行其他 Gradle taskgradlew
初始化一个 Gradle 项目或者生成 Gradle wrappergradle

作者:TechMerger
链接:https://juejin.cn/post/7144558236643885092
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
收起阅读 »

Android性能优化 - 捕获java crash的那些事

背景 crash一直是影响app稳定性的大头,同时在随着项目逐渐迭代,复杂性越来越提高的同时,由于主观或者客观的的原因,都会造成意想不到的crash出现。同样的,在android的历史化过程中,就算是android系统本身,在迭代中也会存在着隐含的crash。...
继续阅读 »

背景


crash一直是影响app稳定性的大头,同时在随着项目逐渐迭代,复杂性越来越提高的同时,由于主观或者客观的的原因,都会造成意想不到的crash出现。同样的,在android的历史化过程中,就算是android系统本身,在迭代中也会存在着隐含的crash。我们常说的crash包括java层(虚拟机层)crash与native层crash,本期我们着重讲一下java层的crash。


java层crash由来


虽然说我们在开发过程中会遇到各种各样的crash,但是这个crash是如果产生的呢?我们来探讨一下一个crash是如何诞生的!


我们很容易就知道,在java中main函数是程序的开始(其实还有前置步骤),我们开发中,虽然android系统把应用的主线程创建封装在了自己的系统中,但是无论怎么封装,一个java层的线程无论再怎么强大,背后肯定是绑定了一个操作系统级别的线程,才真正得与驱动,也就是说,我们平常说的java线程,它其实是被操作系统真正的Thread的一个使用体罢了,java层的多个thread,可能会只对应着native层的一个Thread(便于区分,这里thread统一只java层的线程,Thread指的是native层的Thread。其实native的Thread也不是真正的线程,只是操作系统提供的一个api罢了,但是我们这里先简单这样定义,假设了native的线程与操作系统线程为同一个东西)


每一个java层的thread调用start方法,就会来到native层Thread的世界


public synchronized void start() {
throw new IllegalThreadStateException();
group.add(this);

started = false;
try {
nativeCreate(this, stackSize, daemon);
started = true;
} finally {
try {
if (!started) {
group.threadStartFailed(this);
}
} catch (Throwable ignore) {
/* do nothing. If start0 threw a Throwable then
it will be passed up the call stack */
}
}
}

最终调用的是一个jni方法


private native static void nativeCreate(Thread t, long stackSize, boolean daemon);

而nativeCreate最终在native层的实现是


static void Thread_nativeCreate(JNIEnv* env, jclass, jobject java_thread, jlong stack_size,
jboolean daemon) {
// There are sections in the zygote that forbid thread creation.
Runtime* runtime = Runtime::Current();
if (runtime->IsZygote() && runtime->IsZygoteNoThreadSection()) {
jclass internal_error = env->FindClass("java/lang/InternalError");
CHECK(internal_error != nullptr);
env->ThrowNew(internal_error, "Cannot create threads in zygote");
return;
}
// 这里就是真正的创建线程方法
Thread::CreateNativeThread(env, java_thread, stack_size, daemon == JNI_TRUE);
}

CreateNativeThread 经过了一系列的校验动作,终于到了真正创建线程的地方了,最终在CreateNativeThread方法中,通过了pthread_create创建了一个真正的Thread


Thread::CreateNativeThread 方法中
...
pthread_create_result = pthread_create(&new_pthread,
&attr,
Thread::CreateCallback,
child_thread);
CHECK_PTHREAD_CALL(pthread_attr_destroy, (&attr), "new thread");

if (pthread_create_result == 0) {
// pthread_create started the new thread. The child is now responsible for managing the
// JNIEnvExt we created.
// Note: we can't check for tmp_jni_env == nullptr, as that would require synchronization
// between the threads.
child_jni_env_ext.release(); // NOLINT pthreads API.
return;
}
...

到这里我们就能够明白,一个java层的thread其实真正绑定的,是一个native层的Thread,有了这个知识,我们就可以回到我们的crash主题了,当发生异常的时候(即检测到一些操作不符合虚拟机规定时),注意,这个时候还是在虚拟机的控制范围之内,就可以直接调用


void Thread::ThrowNewException(const char* exception_class_descriptor,
const char* msg) {
// Callers should either clear or call ThrowNewWrappedException.
AssertNoPendingExceptionForNewException(msg);
ThrowNewWrappedException(exception_class_descriptor, msg);
}

进行对exception的抛出,我们目前所有的java层crash都是如此,因为对crash的识别还属于本虚拟机所在的进程的范畴(native crash 虚拟机就没办法直接识别),比如我们常见的各种crash


image.png


然后就会调用到Thread::ThrowNewWrappedException 方法,在这个方法里面再次调用到Thread::SetException方法,成功的把当次引发异常的信息记录下来


void Thread::SetException(ObjPtr<mirror::Throwable> new_exception) {
CHECK(new_exception != nullptr);
// TODO: DCHECK(!IsExceptionPending());
tlsPtr_.exception = new_exception.Ptr();
}

此时,此时就会调用Thread的Destroy方法,这个时候,线程就会在里面判断,本次的异常该怎么去处理


void Thread::Destroy() {
...

if (tlsPtr_.opeer != nullptr) {
ScopedObjectAccess soa(self);
// We may need to call user-supplied managed code, do this before final clean-up.
HandleUncaughtExceptions(soa);
RemoveFromThreadGroup(soa);
Runtime* runtime = Runtime::Current();
if (runtime !=