因为我有SM.MS账号，所以一直是登录使用。最近才发现SM.MS禁止了游客上传图像，今天试的imgdd上传出现了问题。正好闲来无事整理一下现在可用的免费图床。
可选择多种文件尺寸和图像质量，并可在线预览对比图像质量后保存。
几乎全能图像在线转换压缩处理工具
以下为图床列表，示例图片文件大小为1.01Mb左右(1041 kb，1065532 字节)，你可以按F12，在开发人员工具中选择网络-停用缓存，然后按F5刷新页面，查看图片下载速度。
只做收集使用，没有任何利益关系。请注意备份您的数据
为了防止有奇怪的人不断试你的密码，你可以尝试修改你的Typecho的登录路径。
以下举例，我们将admin修改为SAVq87NqJ9ecUSYl
admin为SAVq87NqJ9ecUSYlconfig.inc.php文件，修改大约第12行的define('__TYPECHO_ADMIN_DIR__', '/admin/');install.php（如果已经完成网站安装，可忽略），大约第14行已经第405行define('__TYPECHO_ADMIN_DIR__', '/admin/');将移上所有的admin修改为SAVq87NqJ9ecUSYl即可。
实时语音传输的核心在于持续流式处理，我们通过一个完整的代码示例来揭示其工作原理：
// 音频采集线程
class AudioCaptureThread extends Thread {
private static final int SAMPLE_RATE = 48000; // 48kHz采样率
private static final int FRAME_DURATION = 20; // 20ms帧间隔
private static final int FRAME_SIZE = (SAMPLE_RATE * FRAME_DURATION) / 1000; // 960采样点
@Override
public void run() {
AudioRecord recorder = createAudioRecord();
ByteBuffer buffer = ByteBuffer.allocateDirect(FRAME_SIZE * 2); // 16bit采样
recorder.startRecording();
while (isRunning) {
// 读取20ms的PCM数据
int readBytes = recorder.read(buffer, FRAME_SIZE * 2);
// 添加RTP头部（时间戳+序号）
RtpPacket packet = new RtpPacket();
packet.timestamp = SystemClock.elapsedRealtimeNanos() / 1000;
packet.sequence = nextSequenceNumber();
packet.payload = buffer.array();
// 立即发送数据包
networkSender.send(packet);
buffer.rewind(); // 重用缓冲区
}
}
private AudioRecord createAudioRecord() {
return new AudioRecord.Builder()
.setAudioFormat(new AudioFormat.Builder()
.setEncoding(AudioFormat.ENCODING_PCM_16BIT)
.setSampleRate(SAMPLE_RATE)
.setChannelMask(AudioFormat.CHANNEL_IN_MONO)
.build())
.setBufferSizeInBytes(FRAME_SIZE * 4) // 双缓冲
.build();
}
}关键原理说明：
(elapsedRealtimeNanos()/1000)确保时序精度class AudioPlaybackThread extends Thread {
private static final int JITTER_BUFFER_DEPTH = 5; // 100ms缓冲深度
private final PriorityBlockingQueue<RtpPacket> buffer =
new PriorityBlockingQueue<>(50, Comparator.comparingLong(p -> p.timestamp));
private AudioTrack audioTrack;
private long lastPlayedTimestamp = 0;
@Override
public void run() {
audioTrack = createAudioTrack();
audioTrack.play();
while (isRunning) {
RtpPacket packet = waitForNextPacket();
writeToAudioTrack(packet);
updateTimeline(packet);
}
}
private RtpPacket waitForNextPacket() {
if (buffer.size() < JITTER_BUFFER_DEPTH) {
// 缓冲不足时插入静音包
return generateSilencePacket();
}
return buffer.poll(20, TimeUnit.MILLISECONDS); // 阻塞等待
}
private void writeToAudioTrack(RtpPacket packet) {
// 抖动补偿计算
long expectedTimestamp = lastPlayedTimestamp + 20000; // 20ms间隔
long timestampDelta = packet.timestamp - expectedTimestamp;
if (timestampDelta > 50000) { // 超过50ms延迟
resetPlayback(); // 重置时间线
}
audioTrack.write(packet.payload, 0, packet.payload.length);
lastPlayedTimestamp = packet.timestamp;
}
private AudioTrack createAudioTrack() {
return new AudioTrack.Builder()
.setAudioFormat(new AudioFormat.Builder()
.setEncoding(AudioFormat.ENCODING_PCM_16BIT)
.setSampleRate(SAMPLE_RATE)
.setChannelMask(AudioFormat.CHANNEL_OUT_MONO)
.build())
.setBufferSizeInBytes(FRAME_SIZE * 4)
.setTransferMode(AudioTrack.MODE_STREAM)
.build();
}
}核心算法解析：
在做之前我完全没考虑过网络通话是如何实现。就是如何做到你在说话的同时，对方一直可以听到的。我的意思是，你说了一句很长的话，对方不是你说完才听到的，是你一直在说，对方那边一直播放。
上面的TL;DR部分几乎可以解答我所有的疑惑了。不过要实现类似微信语音通话的实时对话功能，需要深入理解音视频流式处理的完整技术链。本文将重点从Android客户端的视角，剖析实时语音通话的核心技术实现。本文结束后，有包括上面的代码在内的完整的示例代码，有需要都可以自取。
graph LR
A[麦克风持续采集] --> B[20ms数据分块]
B --> C[即时编码]
C --> D[网络实时发送]
D --> E[接收端缓冲]
E --> F[持续解码播放]与传统文件传输不同，实时通话采用流水线式处理：
| 指标 | 目标值 | 实现要点 |
|---|---|---|
| 端到端延迟 | <400ms | 编解码优化/Jitter Buffer控制 |
| 音频采样率 | 48kHz | 硬件加速支持 |
| 抗丢包能力 | 5%-20% | FEC/Opus冗余 |
| CPU占用率 | <15% | MediaCodec硬件编码 |
// 低延迟音频采集配置
private void setupAudioRecorder() {
int sampleRate = 48000; // 优先选择硬件支持的采样率
int channelConfig = AudioFormat.CHANNEL_IN_MONO;
int audioFormat = AudioFormat.ENCODING_PCM_16BIT;
int bufferSize = AudioRecord.getMinBufferSize(sampleRate,
channelConfig, audioFormat);
AudioRecord recorder = new AudioRecord(
MediaRecorder.AudioSource.VOICE_COMMUNICATION, // 专用通信模式
sampleRate,
channelConfig,
audioFormat,
bufferSize * 2); // 双缓冲避免溢出
// 环形缓冲区实现
audioThread = new Thread(() -> {
byte[] buffer = new byte[960]; // 20ms数据量：48000Hz * 20ms * 16bit / 8 = 1920字节
while (isRecording) {
int readBytes = recorder.read(buffer, 0, buffer.length);
if (readBytes > 0) {
encoderQueue.offer(buffer.clone()); // 提交编码队列
}
}
});
}关键参数选择依据：
VOICE_COMMUNICATION ：启用回声消除硬件加速// 硬件编码器初始化
MediaFormat format = MediaFormat.createAudioFormat(
MediaFormat.MIMETYPE_AUDIO_OPUS, 48000, 1);
format.setInteger(MediaFormat.KEY_BIT_RATE, 24000);
format.setInteger(MediaFormat.KEY_MAX_INPUT_SIZE, 960);
MediaCodec encoder = MediaCodec.createEncoderByType("audio/opus");
encoder.configure(format, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE);
encoder.start();
// 编码循环
while (!encoderQueue.isEmpty()) {
int inputIndex = encoder.dequeueInputBuffer(10000);
if (inputIndex >= 0) {
ByteBuffer inputBuffer = encoder.getInputBuffer(inputIndex);
byte[] rawData = encoderQueue.poll();
inputBuffer.put(rawData);
encoder.queueInputBuffer(inputIndex, 0, rawData.length,
System.nanoTime()/1000, 0);
}
MediaCodec.BufferInfo bufferInfo = new MediaCodec.BufferInfo();
int outputIndex = encoder.dequeueOutputBuffer(bufferInfo, 10000);
if (outputIndex >= 0) {
ByteBuffer encodedData = encoder.getOutputBuffer(outputIndex);
sendToNetwork(encodedData); // 网络发送
encoder.releaseOutputBuffer(outputIndex, false);
}
}编码优化技巧：
MediaCodec.CONFIGURE_FLAG_ENCODE开启硬件编码KEY_MAX_INPUT_SIZE防止缓冲区溢出(System.nanoTime()/1000)UDP封包结构示例
+--------+--------+--------+-------------------+
| RTP头 | 时间戳 | 序列号 | Opus载荷（20ms数据）|
+--------+--------+--------+-------------------+
| 12字节 | 4字节 | 2字节 | 可变长度 |
+--------+--------+--------+-------------------+NAT穿透实现
// STUN协议实现示例
public InetSocketAddress discoverNAT() throws IOException {
DatagramSocket socket = new DatagramSocket();
byte[] stunRequest = createStunBindingRequest();
// 发送到公共STUN服务器
socket.send(new DatagramPacket(stunRequest, stunRequest.length,
InetAddress.getByName("stun.l.google.com"), 19302));
// 接收响应
byte[] buffer = new byte[1024];
DatagramPacket response = new DatagramPacket(buffer, buffer.length);
socket.receive(response);
// 解析XOR-MAPPED-ADDRESS
return parseStunResponse(response.getData());
}Jitter Buffer设计
class JitterBuffer {
private static final int MAX_BUFFER_SIZE = 10; // 存储200ms数据
private PriorityQueue<AudioPacket> buffer =
new PriorityQueue<>(Comparator.comparingInt(p -> p.sequence));
private int lastPlayedSeq = -1;
public void addPacket(AudioPacket packet) {
if (packet.sequence > lastPlayedSeq) {
buffer.offer(packet);
// 缓冲区溢出处理
if (buffer.size() > MAX_BUFFER_SIZE) {
buffer.poll(); // 丢弃最旧数据包
}
}
}
public AudioPacket getNextPacket() {
if (!buffer.isEmpty() &&
buffer.peek().sequence == lastPlayedSeq + 1) {
lastPlayedSeq++;
return buffer.poll();
}
return null;
}
}低延迟播放配置
AudioTrack audioTrack = new AudioTrack.Builder()
.setAudioAttributes(new AudioAttributes.Builder()
.setUsage(AudioAttributes.USAGE_VOICE_COMMUNICATION)
.setContentType(AudioAttributes.CONTENT_TYPE_SPEECH)
.build())
.setAudioFormat(new AudioFormat.Builder()
.setEncoding(AudioFormat.ENCODING_PCM_16BIT)
.setSampleRate(48000)
.setChannelMask(AudioFormat.CHANNEL_OUT_MONO)
.build())
.setBufferSizeInBytes(960 * 2) // 双缓冲
.setTransferMode(AudioTrack.MODE_STREAM)
.build();
audioTrack.play();
// 播放线程
while (isPlaying) {
AudioPacket packet = jitterBuffer.getNextPacket();
if (packet != null) {
audioTrack.write(packet.data, 0, packet.data.length);
} else {
generateComfortNoise(); // 生成舒适噪声
}
}// Protobuf消息定义
message SignalMessage {
enum Type {
OFFER = 0;
ANSWER = 1;
ICE_CANDIDATE = 2;
}
Type type = 1;
string sdp = 2;
repeated string iceCandidates = 3;
}核心功能：
客户端A ↔ TURN Server ↔ 客户端B
↓
当P2P不通时启用中继| 优化方向 | 具体措施 | 效果预估 |
|---|---|---|
| 采集延迟 | 使用AudioRecord的READ_NON_BLOCKING模式 | 减少2-5ms |
| 编码延迟 | 启用MediaCodec异步模式 | 减少3-8ms |
| 网络传输 | 开启UDP QoS标记（DSCP 46） | 减少10-50ms |
| 播放缓冲 | 动态调整Jitter Buffer深度 | 减少20-100ms |
// 通话中唤醒锁管理
PowerManager pm = (PowerManager) getSystemService(POWER_SERVICE);
WakeLock wakeLock = pm.newWakeLock(
PowerManager.PARTIAL_WAKE_LOCK, "MyApp:VoiceCall");
wakeLock.acquire(10*60*1000L /*10分钟*/);
// 根据网络状态调整编码参数
if (isNetworkPoor) {
encoder.setVideoBitrate(1000000); // 降低码率
adjustFrameRate(15);
}peerConnection.getStats(new StatsObserver() {
@Override
public void onComplete(StatsReport[] reports) {
for (StatsReport report : reports) {
if (report.type.equals("ssrc")) {
// 获取音频流统计信息
Log.d("Stats", "丢包率: " + report.values.get("packetsLost"));
}
}
}
});# 采集延迟
D/AudioRecorder: Frame captured (seq=325, ts=158746532)
# 网络事件
W/Network: Packet lost detected, seq=1234, enabling FEC
# 播放状态
I/AudioTrack: Buffer underrun, inserting 20ms comfort noise实现高质量的实时语音通话需要Android开发者深入掌握以下核心技术：
未来演进方向：
建议进一步研究：
掌握这些核心技术后，开发者可以构建出媲美商业级应用的实时通信系统。希望本文能为各位Android开发者在实时音视频领域提供有价值的参考。
// 音频采集线程
class AudioCaptureThread extends Thread {
private static final int SAMPLE_RATE = 48000; // 48kHz采样率
private static final int FRAME_DURATION = 20; // 20ms帧间隔
private static final int FRAME_SIZE = (SAMPLE_RATE * FRAME_DURATION) / 1000; // 960采样点
@Override
public void run() {
AudioRecord recorder = createAudioRecord();
ByteBuffer buffer = ByteBuffer.allocateDirect(FRAME_SIZE * 2); // 16bit采样
recorder.startRecording();
while (isRunning) {
// 读取20ms的PCM数据
int readBytes = recorder.read(buffer, FRAME_SIZE * 2);
// 添加RTP头部（时间戳+序号）
RtpPacket packet = new RtpPacket();
packet.timestamp = SystemClock.elapsedRealtimeNanos() / 1000;
packet.sequence = nextSequenceNumber();
packet.payload = buffer.array();
// 立即发送数据包
networkSender.send(packet);
buffer.rewind(); // 重用缓冲区
}
}
private AudioRecord createAudioRecord() {
return new AudioRecord.Builder()
.setAudioFormat(new AudioFormat.Builder()
.setEncoding(AudioFormat.ENCODING_PCM_16BIT)
.setSampleRate(SAMPLE_RATE)
.setChannelMask(AudioFormat.CHANNEL_IN_MONO)
.build())
.setBufferSizeInBytes(FRAME_SIZE * 4) // 双缓冲
.build();
}
}关键原理说明：
class AudioPlaybackThread extends Thread {
private static final int JITTER_BUFFER_DEPTH = 5; // 100ms缓冲深度
private final PriorityBlockingQueue<RtpPacket> buffer =
new PriorityBlockingQueue<>(50, Comparator.comparingLong(p -> p.timestamp));
private AudioTrack audioTrack;
private long lastPlayedTimestamp = 0;
@Override
public void run() {
audioTrack = createAudioTrack();
audioTrack.play();
while (isRunning) {
RtpPacket packet = waitForNextPacket();
writeToAudioTrack(packet);
updateTimeline(packet);
}
}
private RtpPacket waitForNextPacket() {
if (buffer.size() < JITTER_BUFFER_DEPTH) {
// 缓冲不足时插入静音包
return generateSilencePacket();
}
return buffer.poll(20, TimeUnit.MILLISECONDS); // 阻塞等待
}
private void writeToAudioTrack(RtpPacket packet) {
// 抖动补偿计算
long expectedTimestamp = lastPlayedTimestamp + 20000; // 20ms间隔
long timestampDelta = packet.timestamp - expectedTimestamp;
if (timestampDelta > 50000) { // 超过50ms延迟
resetPlayback(); // 重置时间线
}
audioTrack.write(packet.payload, 0, packet.payload.length);
lastPlayedTimestamp = packet.timestamp;
}
private AudioTrack createAudioTrack() {
return new AudioTrack.Builder()
.setAudioFormat(new AudioFormat.Builder()
.setEncoding(AudioFormat.ENCODING_PCM_16BIT)
.setSampleRate(SAMPLE_RATE)
.setChannelMask(AudioFormat.CHANNEL_OUT_MONO)
.build())
.setBufferSizeInBytes(FRAME_SIZE * 4)
.setTransferMode(AudioTrack.MODE_STREAM)
.build();
}
}核心算法解析：
class UdpSender {
private static final int MAX_RETRIES = 2;
private static final int MTU = 1400; // 典型移动网络MTU
private final DatagramChannel channel;
private final InetSocketAddress remoteAddress;
void send(RtpPacket packet) {
ByteBuffer buffer = ByteBuffer.wrap(packet.serialize());
// 分片发送（应对MTU限制）
while (buffer.hasRemaining()) {
int bytesToSend = Math.min(buffer.remaining(), MTU);
ByteBuffer slice = buffer.slice();
slice.limit(bytesToSend);
sendWithRetry(slice);
buffer.position(buffer.position() + bytesToSend);
}
}
private void sendWithRetry(ByteBuffer data) {
int attempt = 0;
while (attempt <= MAX_RETRIES) {
try {
channel.send(data, remoteAddress);
return;
} catch (IOException e) {
if (++attempt > MAX_RETRIES) {
reportNetworkError(e);
}
}
}
}
}关键技术点：
import com.googlecode.javaewah.EWAHCompressedBitmap;
import com.googlecode.javaewah.IntIterator;
class FecEncoder {
// Reed - Solomon(5,3)编码配置
private static final int DATA_SHARDS = 3;
private static final int PARITY_SHARDS = 2;
private static final int TOTAL_SHARDS = DATA_SHARDS + PARITY_SHARDS;
private final RSCodec codec = new RSCodec(DATA_SHARDS, PARITY_SHARDS);
public List<byte[]> encode(byte[] input) {
byte[][] shards = splitIntoShards(input);
codec.encodeParity(shards, 0, DATA_SHARDS);
List<byte[]> result = new ArrayList<>();
for (byte[] shard : shards) {
result.add(shard);
}
return result;
}
private byte[][] splitIntoShards(byte[] data) {
int shardSize = (data.length + DATA_SHARDS - 1) / DATA_SHARDS;
byte[][] shards = new byte[TOTAL_SHARDS][shardSize];
for (int i = 0; i < DATA_SHARDS; i++) {
int start = i * shardSize;
int end = Math.min(start + shardSize, data.length);
System.arraycopy(data, start, shards[i], 0, end - start);
}
return shards;
}
}数学原理：
// 使用WebRTC AEC模块的JNI接口
extern "C" JNIEXPORT void JNICALL
Java_com_example_voice_AecProcessor_processFrame(
JNIEnv* env,
jobject thiz,
jshortArray micData,
jshortArray speakerData) {
webrtc::EchoCancellation* aec = GetAecInstance();
jshort* mic = env->GetShortArrayElements(micData, 0);
jshort* speaker = env->GetShortArrayElements(speakerData, 0);
// 执行AEC处理
aec->ProcessRenderAudio(speaker, FRAME_SIZE);
aec->ProcessCaptureAudio(mic, FRAME_SIZE, 0);
env->ReleaseShortArrayElements(micData, mic, 0);
env->ReleaseShortArrayElements(speakerData, speaker, 0);
}算法流程：
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.Executors;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeUnit;
class BitrateController {
private int currentBitrate = 1000000; // 初始1Mbps
private final NetworkMonitor networkMonitor;
private final List<BitrateListener> listeners = new ArrayList<>();
private final ScheduledExecutorService executorService = Executors.newScheduledThreadPool(1);
public BitrateController(NetworkMonitor networkMonitor) {
this.networkMonitor = networkMonitor;
executorService.scheduleAtFixedRate(() -> {
int quality = calculateNetworkQuality();
adjustBitrate(quality);
}, 0, 2, TimeUnit.SECONDS);
}
private int calculateNetworkQuality() {
NetworkStatus status = networkMonitor.getLatestStatus();
if (status instanceof NetworkGood) {
return 90;
} else if (status instanceof NetworkFair) {
return 70;
} else if (status instanceof NetworkPoor) {
return 40;
}
return 50;
}
private void adjustBitrate(int quality) {
int newBitrate;
if (quality > 80) {
newBitrate = (int) (currentBitrate * 1.2);
} else if (quality < 40) {
newBitrate = (int) (currentBitrate * 0.7);
} else {
newBitrate = currentBitrate;
}
newBitrate = Math.max(100000, Math.min(2000000, newBitrate));
if (newBitrate != currentBitrate) {
currentBitrate = newBitrate;
for (BitrateListener listener : listeners) {
listener.onBitrateChanged(newBitrate);
}
}
}
public void addBitrateListener(BitrateListener listener) {
listeners.add(listener);
}
public void removeBitrateListener(BitrateListener listener) {
listeners.remove(listener);
}
}
interface BitrateListener {
void onBitrateChanged(int newBitrate);
}
class NetworkMonitor {
private int rtt = 100; // 毫秒
private float lossRate = 0f; // 丢包率
private int jitter = 50; // 抖动
public NetworkStatus getLatestStatus() {
if (lossRate > 0.2f) {
return new NetworkPoor();
} else if (rtt > 300) {
return new NetworkFair();
}
return new NetworkGood();
}
public void setRtt(int rtt) {
this.rtt = rtt;
}
public void setLossRate(float lossRate) {
this.lossRate = lossRate;
}
public void setJitter(int jitter) {
this.jitter = jitter;
}
}
class NetworkGood implements NetworkStatus {}
class NetworkFair implements NetworkStatus {}
class NetworkPoor implements NetworkStatus {}
interface NetworkStatus {}sequenceDiagram
participant A as 发送端
participant B as 网络
participant C as 接收端
A->>B: 发送数据包1（seq=1, ts=100）
A->>B: 发送数据包2（seq=2, ts=120）
B--xC: 包2丢失
A->>B: 发送数据包3（seq=3, ts=140）
C->>C: 检测到seq=2缺失
C->>B: 发送NACK重传请求
B->>C: 重传数据包2
C->>C: 按时间戳排序[1,3,2]
C->>C: 调整播放顺序为[1,2,3]我的主题貌似解析不了，请看下图
关键时序说明：
// 使用对象池减少GC
public class RtpPacketPool {
private static final int MAX_POOL_SIZE = 50;
private static final Queue<RtpPacket> pool = new ConcurrentLinkedQueue<>();
public static RtpPacket obtain() {
RtpPacket packet = pool.poll();
return packet != null ? packet : new RtpPacket();
}
public static void recycle(RtpPacket packet) {
if (pool.size() < MAX_POOL_SIZE) {
packet.reset();
pool.offer(packet);
}
}
}
// 使用示例
void processPacket(byte[] data) {
RtpPacket packet = RtpPacketPool.obtain();
packet.parse(data);
// ...处理逻辑...
RtpPacketPool.recycle(packet);
}// 设置实时音频线程优先级
private void setThreadPriority() {
Process.setThreadPriority(Process.THREAD_PRIORITY_URGENT_AUDIO);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
PerformanceHintManager perfHintManager =
(PerformanceHintManager) context.getSystemService(Context.PERFORMANCE_HINT_SERVICE);
SessionParams params = new SessionParams(
PerformanceHintManager.SESSION_TYPE_CPU_LOAD,
new CpuRange(70, 100));
PerformanceHintManager.Session session =
perfHintManager.createSession(params);
session.reportActualWorkDuration(500_000); // 500ms周期
}
}优化效果：
需要更深入某个技术点的实现细节可以随时告知！
今天打开github weekly榜单，清一色全是ai相关的内容…我想起来前几天刷producthunt，连续几天排行榜全是ai产品。过去 72 小时的新产品榜单上，42 款产品名称包含 “AI-powered”，7 款在描述中强调 “no AI involved” 以示清流，唯一敢用中性描述的，是某款 AI 检测工具。
这种似曾相识的狂热，让我想起 1975 年全美超市货架摆满宠物石（Pet Rock）的荒诞场景。当时广告商人加里・达尔把普通鹅卵石装进纸盒，附上 32 页《养护手册》宣称 “永不死亡、无需喂食”，三个月狂销 150 万颗石头。今天的 AI 创业公司们正在复刻这种黑色幽默：某团队融资 500 万美元开发的 “AI 日程管家”，实际功能是把谷歌日历事件转成 emoji 表情；估值 1.2 亿美元的 “智能邮件助手”，核心技术竟是定时发送邮件的 crontab 脚本。
资本市场的推波助澜让这场闹剧愈发魔幻。宠物石当年催生了镶水钻的豪华版和 “分离焦虑症治疗课程”，如今 VC 们正在批量制造 “AI + 区块链知识图谱”、”多模态元宇宙助理” 等缝合怪项目。Y Combinator 最新批次的初创公司中，83% 的商业计划书首页印着 “revolutionize XX industry with AI”，而实际产品往往只是给现有服务套了层 ChatGPT 的对话外壳。
更危险的趋势在于核心技术的空心化。宠物石热潮至少创造了纸盒包装和手册设计的就业机会，而今某些 “AI 原生应用” 连基本功能都漏洞百出：某明星项目标榜的 “自主任务分解” 实为固定流程模板，其开源代码库里 90% 的 commit 记录是在修改 README 文档；某融资千万的 AI 绘画工具，被开发者扒出底层调用的仍是 Stable Diffusion 1.5 接口。
历史总在提醒我们集体癔症的代价。1976 年宠物石滞销时，达尔将库存改造成镇纸才避免破产，今天那些 All in AI 的团队或许该提前准备 Plan B—— 当投资人说 “请讲个 AI 之外的故事” 时，至少能掏出块质感温润的石头。毕竟在 2025 年的科技丛林里，一块不会崩溃死机、无需云端订阅的实体鹅卵石，或许才是真正的颠覆式创新。
当 Humane 公司以 1.16 亿美元贱卖 AI 业务时，其联合创始人伊姆兰・乔杜里或许会想起三年前 TED 演讲台上那个意气风发的自己。彼时他描绘的无屏 AI 世界，如今只剩服务器关闭后用户设备里被清空的记忆，以及科技博主 MKBHD”史上最差产品” 的判词。这不仅是某个创业公司的滑铁卢，更是整个行业陷入 AI 异化的缩影。
在资本市场的狂欢中，科技公司正陷入集体癔症：某电动自行车将 ChatGPT 塞进控制系统，声称能生成 “诗意骑行路线”；某智能花瓶强行嫁接大模型，试图用 AI 生成的鸡汤文学替代真实的插花艺术；更有企业将语音助手植入旅行鞋，让鞋子在用户行走时朗诵历史故事。这些荒诞的 AI 嫁接，如同给蒸汽机车安装触摸屏般充满违和感，暴露出行业对技术本质的深刻误解。
这种技术滥用正在形成危险的恶性循环。某 “AI 私人助理” 软件收取 129 元会员费后，生成的视频素材仅能实现图片缩放特效；某笔记本电脑搭载的写作 AI 在付费后，产出内容质量反而断崖式下跌。当企业把 AI 视为融资密码而非解决方案时，产品就沦为资本市场的行为艺术 ——Rabbit R1 预售两日售罄的盛况，与后续曝光的系统漏洞形成黑色幽默，恰似给马车装上火箭引擎却忘记安装刹车。
更深层的危机在于，这种 AI 崇拜正在摧毁科技产品的完整性。微软 Copilot 被制药公司 CIO 怒斥为 “中学生水平的 PPT 生成器”，其图标在 1080P 显示器上都会产生视觉畸变；魅族 All in AI 的战略转型，本质是对智能手机基础体验丧失信心的逃亡。当科技巨头都沉迷于给计算器添加语音交互功能时，整个行业正在集体上演 “皇帝的新衣”。
回归理性或许需要一场行业层面的戒断治疗。惠普收购 Humane 团队后组建的 IQ 部门，选择将 AI 深度集成到打印机和会议系统，这种 “润物细无声” 的路径反而展现出生命力；影视行业用 AI 生成故宫场景取代实景拍摄的务实选择，证明技术赋能不应等同于颠覆重构。正如导演在航母拍摄现场领悟的：AI 可以生成舰载机，但驾驭战鹰的必须是活生生的飞行员。
科技史反复证明，任何脱离场景价值的技术炫技终将沦为电子坟场的展品。当我们在博物馆凝视上世纪 90 年代的语音控制微波炉时，不该让子孙后代以同样戏谑的目光打量这个时代的 AI 胸针和会朗诵诗歌的花瓶。停止这场荒诞的 AI 化竞赛，或许才是科技行业重拾尊严的开始。
作为一个前端新手，我决定用 Astro 框架重构个人博客。听说它的静态生成能力和 Partial Hydration 特性可以让网站又快又省资源，这对我这种追求极简的写作者来说简直完美。本地开发时一切顺利，热更新响应迅速，Markdown 渲染流畅。但当我部署到 Vercel 后，用户反馈点击文章链接需要等待 3-5 秒才能看到内容。整个跳转给我的感觉就是卡卡的 —— 明明用了静态站点生成，为什么会有这个诡异的延迟？
打开 Network 面板重新加载页面，发现：
HTML 文件加载仅需 100ms，但主内容渲染延迟了 2.3s；页面加载时触发了多个；Hydration 事件客户端 ；JS 体积达到 420KB…
然后我大概就知道问题在哪里了。
简单地说你可以理解为，本来一次点击，浏览器从A页面跳转到B页面，无论是A页面的消失还是B页面的逐步呈现，这个过程都没有被忽略。Astro的部分渲染，在B页面被完全加载出来之前都停留在A页面，他需要等待B页面的不同内容加载之后刷新视图，呈现B页面的内容。
另外我发现这个特行可以让你实现类似Android里的共享元素的炫酷效果。
我意识到问题可能与 Astro 的核心特性有关：
在文章页模板中，我为了实现 “阅读进度条” 功能，错误地使用了client:load指令：
<!-- 错误示范 --> <ReadingProgress client:load />这导致整个组件在页面加载时立即执行 Hydration，阻塞了主线程。
我的文章路由采用动态参数[slug].astro，默认配置下：
// astro.config.mjs（原配置） export default defineConfig({ experimental: { islands: false } });这导致 Astro 在客户端重新渲染整个页面，而非仅更新必要部分。
未压缩的图片平均大小 300KB;未启用 Gzip;第三方字体文件阻塞渲染。
这里图片我是引用的第三方图库，虽然没有加preload，但是速度其实还算可以。不过多张图片引用也会影响速度。
尤其要说一下这个字体，我最开始测试的，google fonts的访问速度怎么会比loli.net要快这么多？难道是国内也有服务器？
后来我发现了问题。
google fonts引用的css，是切割好的字体文件。也就是这个css可以理解为是一个目录，里面有分好包的实际字体文件（目前常用方法），然后这个css会分批引用实际字体文件。给👴🏻整无语了。一整个页面就在那里等它这个字体加载。
经过调试，我逐步实施了以下解决方案：
<!-- 正确写法：仅当滚动到可见区域时Hydrate --> <ReadingProgress client:visible /> <!-- 完全静态组件 --> <ArticleMeta server />使用astro-imagetools自动压缩图片。其实直接添加懒加载就可以了。
优化后数据
静态站点生成不等于自动高性能
前端性能优化需要系统性思维
Astro 的强大在于合理利用其特性，而非盲目使用
现在，我的博客不仅加载速度提升了，Lighthouse 98 XD。
更重要的是，我学会了如何通过 Chrome DevTools 和 Astro 内置工具进行性能分析。如果你也遇到类似问题，可以参考一下我上面的方案。（避雷Google fonts）
2025年3月14日更新：
没想到ruanyifeng这周和我写一个话题的内容。
https://www.ruanyifeng.com/blog/2025/03/weekly-issue-341.html
我不认为低代码平台+ai会变香
最近在 X 上又刷到有人吹低代码平台，说它“未来可期”。作为一个写了十几年代码的老程序员，我实在忍不住想吐槽。2025 年 3 月的今天，低代码仍然在炒，但我怎么看都觉得它像个老掉牙的故事——多年前就有人做过，有人退场，活下来的也没多风光。开发者真要为它担心失业？我看未必。
低代码并不新鲜。十年前就有一堆“零代码”“低代码”平台冒出来，喊着“拖拖拽拽就能做应用”。OutSystems、Mendix 这类老面孔仍在，国内也涌现了不少平台，但看看，有多少已经悄无声息地退出了市场？活下来的，像 Appian 或者钉钉宜搭，日子也不算滋润。我认识一哥们儿用低代码搭了个库存系统，业务一调整就改不动，最后还是找我重写。
根据Gartner 2024年报告，全球低代码市场规模增速已从2021年的23.6%下降至7.2%
Forrester 报告中的结论：低代码项目平均维护成本比传统开发高 2.3 倍。
最近，低代码平台开始加入 AI，宣传上功能似乎变强了，能自动生成 UI、调优逻辑等。听起来很吸引人，但我一想，这不扯吗？“好用”不是一开始就该有的吗？AI 是新添的没错，但作为一个开发工具，基础功能好用才是最基本的要求。加了 AI 就吹得天花乱坠，好像以前不好用是理所当然似的。更别提 AI 生成的内容，改起来还是老样子——要么直接用，要么手动调整，跟十年前改代码没啥两样。AI 救不了低代码的命，最多也就是个噱头。
有人说低代码抢初级开发者的饭碗。确实，简单的表单和内部工具能拖几下搞定，初级程序员可能有点压力。但对我这种习惯复杂逻辑的人来说，低代码根本动不了我。那些“80% 简单需求”它能凑合，剩下 20% 的高性能、高定制化活儿，还得靠我们。
低代码还老给我添乱。客户用它搞个半成品，跑来让我修 bug、调性能，比从头写还费劲。我见过公司拿低代码做了个原型，上线后卡得要死，最后还得重构。省了点时间，却留下一堆烂摊子，这算啥“革命”啊？
再说说低代码的收费模式，真是让人无语。免费版的基础功能弱得可怜，比如最多建几个表、连个像样的 API 都不行，想干点正事儿就得掏钱。收费功能层级森严，基本每个平台都有“基础版”“专业版”“企业版”之类的分级，价格一级比一级离谱。举个例子，我试过一个平台，免费版连导出数据都不行，想加个自定义插件，得升到每月几百块的专业版。更别提什么“无限用户”“高级支持”了，全锁在最贵的套餐里。这哪是工具啊，简直是圈钱的套路机器。
低代码的粉丝总爱说未来会更智能，靠 AI 翻身。我听了只想笑。AI 是牛，但低代码加了 AI 就能写分布式系统？能优化算法？我看悬。这么多年，低代码的套路我都看透了：炒一波概念，忽悠一波企业用户，然后慢慢淡出视线。活下来的，要么靠大厂撑腰（比如微软的 Power Apps），要么苟在小众市场，风光不到哪去。
什么“低代码 + 传统开发共存”的说法，我也懒得信。企业用低代码无非图快图便宜，可业务一复杂，它就成鸡肋，重写成本还更高。我宁可从头写个扎实的系统，省得回头返工。
在我眼里，低代码就是个“伪命题”。炒了这么多年，没真干掉谁，也没见哪个平台成了行业霸主。加个 AI 也救不了它，免费功能鸡肋，收费还一套一套的。开发者要失业？除非你只会写“Hello World”。对我来说，低代码顶多是个玩具，玩玩行，想靠它吃饭，我看悬。
所以，别被低代码的宣传唬住了。想在这行混好，还是老老实实练功——算法、架构、DevOps，这些真本事才是我们的护身符。低代码？让它继续炒吧，我码我的代码。
fk lol, fk riot, fk 🐧
LOL最近发布了《3月6日凌晨1点停机版本更新公告》，更新公告中写：
本次更新的核心调整在于削弱职业赛中前期换线战术的可行性。团队加入了一系列机制来遏制这一现象，如果在1:30 - 3:30之间派出两名非打野英雄进入上路或中路及其周边区域，该队伍将受到严厉惩罚。不过，如果己方没有打野，这些机制将不会生效(即五层2/1/2阵容不会受影响)，即将触发机制时，系统会发出警告。
最近的设计的英雄和玩法的改动，看得出这个年龄超过15岁的老游戏挣扎在规则与自由之间寻找平衡。
用户文章揭示的“换线战术使用率骤降”并非孤立现象，其背后是设计师对战术自由度的系统性收束。以2025年全局BP规则为例，职业战队在禁用阶段需遵循“蓝红交替禁用6英雄→选3英雄→再禁用4英雄”的复杂流程8，这使得战术博弈从“创新应对”退化为“规避惩罚”。LPL赛区NIP战队因在红色方放出100%被Ban率的蝎子导致惨败，正是这种规则压迫下的典型悲剧——与其冒险创新，不如遵从版本“标准答案”10。
更深远的影响体现在选手培养体系。正如Uzi感慨LCK选手职业寿命普遍长于LPL，根源在于LPL青训更倾向培养“数据适应型选手”：他们精于计算镀层经济、峡谷先锋刷新时间，却丧失了早期选手如Clearlove的野区路线创新力10。当职业赛场70%的训练时间用于解析版本机制而非战术开发，MOBA的“即时策略”本质已被异化为“数值模拟器”。
设计师的初衷或许是好的——提升比赛观赏性、降低新人门槛。但过度干预的代价正在显现：
如今，玩法框架一步一步缩减，游戏的乐趣或许正在成为比赛的牺牲品？
用户提到大乱斗“随机英雄机制意外创造战术创新温床”，这在实战中体现得淋漓尽致。以时光老头为例，其在大乱斗专属加强后衍生出“CD流无限控”与“AP自爆流”两种极端打法：前者通过堆叠技能急速实现每2.69秒一次群体控制，后者利用雪球突进+Q技能自爆制造混乱111。这种“非常规出装”的盛行，恰恰是对传统模式装备合成路径强制引导的反抗。
但大乱斗的生态裂痕同样触目惊心。30%胜率精粹号组成的“五黑车队”通过脚本送人头操控匹配机制，将普通玩家变成“菠菜筹码”；“红包局”更衍生出“一条命赌局”“212伤害比拼”等变异玩法，将竞技异化为赌博工具3。讽刺的是，玩家明知这些乱象存在，仍以68%的比率选择大乱斗，只因“失控的对抗”比“规则的牢笼”更具吸引力311。
值得玩味的是，在竞技模式日渐僵化的同时，极地大乱斗的玩家占比持续攀升。这一现象绝非偶然：
当召唤师峡谷变成“按规则填写的试卷”，大乱斗则成了玩家保留最后一丝创造力的“游乐场”。这种割裂折射出一个残酷现实：游戏正在分化成“职业赛场”与“娱乐模式”两个平行世界，而中间地带的策略深度逐渐消亡。
用户提及的“主播大乱斗直播占比飙升”现象，与职业赛场的“BP坐牢”形成残酷对照。T1战队虽凭借全局BP新规下的策略调整夺冠，但其依赖的“系列赛禁用重复英雄”机制，本质上仍是设计师对战术树的修剪——选手被迫在10个禁用英雄的限制中重复使用版本答案，而非开发新体系68。
这种割裂在玩家社区形成认知断层：当职业选手研究蝎子打野的100%胜率秘诀时12，普通玩家却在论坛热议“寒冰电刀回血流”“老鼠幕刃秒杀术”等大乱斗邪道玩法11。更致命的是，匹配模式中“标准化阵容选择率突破65%”的数据，暴露出设计师规则已渗透至玩家潜意识——当创新被视为风险，保守即是最优解。
用户提出的“加入随机元素”设想，已在部分模式中验证可行性。极地大乱斗的“骰子重roll机制”允许玩家通过交换英雄打破阵容僵局11，若将其引入排位赛，或可缓解BP阶段的套路固化。更激进的方案是借鉴《VALORANT》的“技能+枪械”双元设计：在保留MOBA核心机制的同时，通过随机技能组合激活战术可能性。
设计师需重新理解“平衡”的内涵——真正的平衡不是消除变量，而是构建动态博弈空间。例如将换线惩罚机制改为“换线方获得推塔速度加成但损失部分小兵经验”，既能抑制无脑换线，又保留战术选择权10。当玩家意识到“规则是沙盒而非牢笼”，MOBA才能重获生命力。
英雄联盟的困境，本质是工业化游戏设计对人性博弈本能的背离。当系统用镀层机制规定对线期、用野区计时器取代反野决策时，玩家只能通过大乱斗的“无序狂欢”找回原始乐趣。正如T1教练组在纪录片中所说：“最好的战术永远诞生于玩家的意外操作，而非设计师的Excel表格”。或许某天，当召唤师峡谷的防御塔不再秒杀换线英雄，而是记录下每个打破常规的精彩瞬间，这个游戏才能真正完成它的“范式革命”。
这个游戏技能是固定的，英雄是固定的，甚至胜利的方法都给你固定了。但是不同英雄不同的技能组合，配上不同的玩家，就有无限种可能和乐趣。与人斗其乐无穷。
而riot，或许正在一次次的更新中，杀死LOL的乐趣。
