转载自：python批量重命名
有这样一个需求，自己刚从b站下载的视频，但是文件名字看起来不好，想批量修改，不想一个一个的改，太麻烦
before：
after：
代码：
import os
path = 'G:/go'
num= 1
for file in os.listdir(path):
before = os.path.join(path,file)
after = os.path.join(path,str(num)+".flv")
os.rename(before,after)
num+=1
import android.content.Context;
import android.os.storage.StorageManager;
import java.lang.reflect.Method;
public class USBUtil {
public static String getUSBPath(Context context) {
StorageManager storageManager = (StorageManager) context.getSystemService(Context.STORAGE_SERVICE);
try {
// 通过反射调用getVolumeList，获取所有挂载的设备（内部sd卡、外部sd卡、挂载的U盘）
Method getVolumeListMethod = StorageManager.class.getMethod("getVolumeList");
Object[] volumes = (Object[]) getVolumeListMethod.invoke(storageManager);
Class<?> storageVolumeClazz = Class.forName("android.os.storage.StorageVolume");
// 通过反射调用getPath、isRemovable
Method getPathMethod = storageVolumeClazz.getMethod("getPath");
Method isRemovableMethod = storageVolumeClazz.getMethod("isRemovable");
if (volumes != null && volumes.length > 0) {
for (Object volume : volumes) {
String path = (String) getPathMethod.invoke(volume); // 获取路径
boolean isRemovable = (boolean) isRemovableMethod.invoke(volume);// 是否可移除
if (isRemovable) {
return path;
}
}
}
} catch (Exception e) {
e.printStackTrace();
}
return "/";
}
}
参考链接：
获取Android设备上的所有存储设备
首先，笔者的主Activity中包含了多个Fragment，通过show、hide来切换展示。当笔者切换到其他的APP，操作一段时间后，返回到当前APP，有很大几率会出现Fragment重叠现象。
首先，在Activity的生命周期中，当Activity不在前台展示时，如果此时其他的APP需要使用内存，系统会杀掉该APP的进程，当用户重新进入该APP时，系统会重新创建Activity。
Activity不在前台展示时会保存Fragment的状态，当系统重新创建Activity时会恢复之前保存的Fragment的状态。
方案一：在Activity的onCreate方法中判断savedInstanceState是否为空，不为空则使用系统保存的Fragment。
public class MainActivity extends AppCompatActivity {
Fragment fragment;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
if (savedInstanceState != null) {
fragment = getSupportFragmentManager().findFragmentByTag("fragment");
} else {
fragment = new Fragment();
getSupportFragmentManager().beginTransaction().add(R.id.frameLayout, fragment, "fragment").commit();
}
}
}
方案二：在Activity的onCreate方法中，调用super方法时直接传null，不使用保存的状态。
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(null);
}
参考资料：
Android fragment 重叠问题——通过hide，show方式导致的解决方法
参考链接：
转载自：解决Mosquitto创建MQTT服务器提示Starting in local only mode
使用新下载的Mosquitto创建MQTT服务器提示Starting in local only mode. Connections will only be possible from clients running on this machine.测试发现服务器只能接入本机的客户端，而其他设备上的客户端在连接时直接被重置了。
随后查阅了一下Mosquitto的更新记录，原来在其2.0.0大版本更新后如果不加载配件文件则使用回环接口（仅可用于本地Socket通信）。
Breaking changes
· When the Mosquitto broker is run without configuring any listeners it will now bind to the loopback interfaces 127.0.0.1 and/or ::1. This means that only connections from the local host will be possible.
· Running the broker as mosquitto or mosquitto -p 1883 will bind to the loopback interface.
· Running the broker with a configuration file with no listeners configured will bind to the loopback interface with port 1883.
· Running the broker with a listener defined will bind by default to 0.0.0.0 / :: and so will be accessible from any interface. It is still possible to bind to a specific address/interface.
先修改软件安装目录中的配置文件mosquitto.conf然后加载配置文件来启动服务器。
# On systems that support Unix Domain Sockets, it is also possible
# to create a # Unix socket rather than opening a TCP socket. In
# this case, the port number should be set to 0 and a unix socket
# path must be provided, e.g.
# listener 0 /tmp/mosquitto.sock
#
# listener port-number [ip address/host name/unix socket path]
listener 1883
# Boolean value that determines whether clients that connect
# without providing a username are allowed to connect. If set to
# false then a password file should be created (see the
# password_file option) to control authenticated client access.
#
# Defaults to false, unless there are no listeners defined in the configuration
# file, in which case it is set to true, but connections are only allowed from
# the local machine.
allow_anonymous true
Android使用TouchDelegate增加View的触摸范围
ListView Tips & Tricks #5: Enlarged Touchable Areas
TouchDelegateGroup
import android.graphics.Rect;
import android.view.MotionEvent;
import android.view.TouchDelegate;
import android.view.View;
import androidx.annotation.NonNull;
import java.util.ArrayList;
public class TouchDelegateGroup extends TouchDelegate {
private ArrayList<TouchDelegate> mTouchDelegates = new ArrayList<>();
private TouchDelegate mCurrentTouchDelegate;
public TouchDelegateGroup(@NonNull Rect bounds, @NonNull View delegateView) {
super(bounds, delegateView);
mTouchDelegates.add(this);
}
public void addTouchDelegate(@NonNull TouchDelegate touchDelegate) {
mTouchDelegates.add(touchDelegate);
}
@Override
public boolean onTouchEvent(MotionEvent event) {
TouchDelegate delegate = null;
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
for (TouchDelegate touchDelegate : mTouchDelegates) {
if (onDelegateTouchEvent(touchDelegate, event)) {
mCurrentTouchDelegate = touchDelegate;
return true;
}
}
break;
case MotionEvent.ACTION_MOVE:
delegate = mCurrentTouchDelegate;
break;
case MotionEvent.ACTION_CANCEL:
case MotionEvent.ACTION_UP:
delegate = mCurrentTouchDelegate;
mCurrentTouchDelegate = null;
break;
}
if (delegate != null) {
return onDelegateTouchEvent(delegate, event);
}
return false;
}
public boolean onSelfTouchEvent(MotionEvent event) {
return super.onTouchEvent(event);
}
public boolean onDelegateTouchEvent(TouchDelegate touchDelegate, MotionEvent event) {
if (touchDelegate instanceof TouchDelegateGroup) {
return ((TouchDelegateGroup) touchDelegate).onSelfTouchEvent(event);
} else {
return touchDelegate.onTouchEvent(event);
}
}
}
节选自：对Jetpack Compose设计的初步解读与思考
Jetpack Compose前段时间进入了Alpha阶段。经过去年年底至今剧烈的api变化后，现在Compose整体上大致稳定，所以我们也能对于Compose的设计进行初步的解读和评价了。
Compose从整体技术风格上来说是这样一个产物：在语法上激进模仿SwiftUI，编译/运行过程充满Svelte风格，同时也综合了各方包括Android开发组自身对UI框架的思考结果。
使用Compose时，最值得关注的就是Compose的编译器插件。可以这么说，Compose的runtime、api都是依附于编译器插件的，那个巨大而无所不包的编译器插件才是Compose的本体。Compose插件强势的入侵了原版Kotlin的语法，导致包含了Compose的Kotlin基本上可以算作新语言（算成个新虚拟机都不过分）。初次了解的时候确实让我很困惑，因为这与React，Flutter推崇的趋势简直是背道而驰。但是了解了Svelte，SwiftUI之后，Compose显得没有那么突兀了。
Svelte试图解决的问题是：如何用声明式的代码书写风格，一对一直接翻译成纯粹命令式的DOM操作，从而达到无额外开销+极小runtime的效果。最终Svelte选择发明一套自制的模板语法来翻译到Javascript上。这个好理解，因为大家很熟悉，显然javascript以及其工具链没有任何实现这个目标的可能。
Compose在框架设计方面的野心明显超越Flutter。Compose团队多次表示Compose就是对Android SDK的重写。Compose对自身的定位估计类似于SwiftUI在苹果系生态中的定位，那就是高层次、生态内通用、外加依靠自身定位尽可能挖掘以及定制工具链以实现先进的开发模式。Compose使用了语法上和Swift神似的Kotlin，也面临相似的问题，于是Compose（出于一些原因）选择了简单粗暴的魔改Kotlin编译器（而不是模仿SwiftUI玩类型系统杂耍）。
Compose团队解释过Compose的出发点：构建一个通用的、描述树状结构渲染过程的框架，不管是是手机UI组件树或者是浏览器HTML Element。
Compose一不做二不休，直接把Kotlin编译器魔改到底。最后利用编译器魔改实现了几大功能。
目前Compose的官方资料仍然较为缺乏，因此很难知道Compose除此之外的优化设计以及runtime具体调度机制。但总体来说，我认为
这个已经可以算作在Kotlin/JVM上重新发明了一个虚拟机了。结构化的执行流程，内存，ABI，call site，复杂的调度策略都有了，我觉得就差来个人来证明能跑操作系统了。在已经因为DSL特性高度特化的Kotlin语言上继续发明新虚拟机，总归是有点奇怪的事情。与此对比，SwiftUI对语言的入侵很少而且是隐式的。