查看原文
其他

坚持不下去了...

闪客 低并发编程 2022-09-23
都说在公众号写系列文章会很惨,我一开始不信邪,也标榜自己不在乎阅读量,就是要把这个难啃的骨头拿下!

但是到目前为止已经出了十几篇篇系列文章了。

开篇词
第一部分 进入内核前的苦力活
第一回 | 最开始的两行代码
第二回 | 自己给自己挪个地儿
第三回 | 做好最最基础的准备工作‍
第四回 | 把自己在硬盘里的其他部分也放到内存来
第五回 | 进入保护模式前的最后一次折腾内存
第六回 | 先解决段寄存器的历史包袱问题
第七回 | 六行代码就进入了保护模式
第八回 | 烦死了又要重新设置一遍 idt 和 gdt
第九回 | Intel 内存管理两板斧:分段与分页
第十回 | 进入 main 函数前的最后一跃!
第一部分总结
第二部分 大战前期的初始化工作

第11回 | 整个操作系统就 20 几行代码

第12回 | 管理内存前先划分出三个边界值


刚开始还好,后面阅读是越来越惨。再不 care 阅读的我,这种连续且不回头的掉阅读趋势,也让我好抓狂啊!

还真想念我曾经的破玩意的热度了,人难免落入俗套呀,说明我内心还是挺在乎阅读量的,做不到心无旁骛只输出文章。


阅读量走低到还好,主要是这公众号机制已经改得面目全非了。原来公众号是个标准的关注流,就简简单单完全按照文章时间顺序排列,且没有什么其他的机制。

现在呢?乱序排列、推荐版块、文章折叠、常读用户等等乱七八糟的机制和产品设计加入进来,我发的文章能不能被你看到已经是个玄学问题了。

最让我心慌的是这个常读用户机制,号主视角叫常读用户,读者视角就是常读公众号,也就是你们订阅号消息的最上方一栏。


这机制让我心慌在哪里呢?就是如果你总是不看我的文章,那我发新文章的时候在你的手机上排列就会特别靠后,甚至可能直接被折叠了。


当然这不怪读者,我看到一个我喜欢的号,天天发一个我不咋关心的系列,我也会长时间不点开。但是无语的就是,这个不点开的动作会被记录成你的行为,被解读为你不喜欢我的号,或者我的文章不好看。


这上哪说理去 


还有最近加入的推荐机制,据说以后会占据更多的版块,那我这种系列文章,每一篇都依赖前后上下文,就很难当做一篇单独的文章被推荐出来,我以前写的那些破玩意系列的爽文倒是有可能。


我感觉这些机制真的是专门克我的新系列,随着系列的不断推进,阅读的人数会越来越少,而且后面几乎也是一批固定的人群在追更,那可能我辛辛苦苦积累的常读用户就全流失了,系列结束后再发啥文章大家都收不到了。

虽然说可以理解,毕竟不论什么系列肯定是越追人越少,而且也不应该纯以数据论成败,但在这样的机制下我不得不屈服呀,如果付出双倍的精力写出的文章,最后的效果是让我的粉丝全流失了,那这去哪说理呀(哭哭哭)。

所以,我苦思冥想了整整五分钟,决定...

哈哈哈,你是不是以为我要弃坑了?是不是以为我要被打脸了?

NO NO NO

你看,我的第二部分其实就是讲整个 main 方法里的初始化过程。
void main(void) {
    ...
    mem_init(main_memory_start,memory_end);
    trap_init();
    blk_dev_init();
    chr_dev_init();
    tty_init();
    time_init();
    sched_init();
    buffer_init(buffer_memory_end);
    hd_init();
    floppy_init();
    ...
}
这代码太规整了!

而且每个方法都是一个单独的故事,前后之间的关联较少。

所以,我想到了一个绝佳的办法,即不让我这个号毁于这个系列的更新,又可以让追更系列的读者可以持续追更,甚至还能有更好的体验。

那就是

把之后的文章,拆成一个个单独的文章发!

就是下图中第二部分的每一个 init。


简单说就三个变化:封面图变成蓝色第几回第几回这几个字去掉文章里的内容不再刻意强调这是个系列文章

这样的好处就是,不论是追更的读者,还是从未读过这个系列的其他读者,都可以不依赖上下文地从每一篇文章中学到一个系统的知识点。

妙不妙!

同时,由于前面的文章没有时间或者没有意愿读完的读者朋友,也可以没有心理负担地入坑啦~

公众号打开率越来越低,微信做这些机制调整肯定也是有自己的考虑,作为博主的我,也想在不断变化的环境中保持不变的姿态,但前提是要活下去,也希望大家理解我做出的调整。

真的怀念曾经那个没有任何平台干预,没有任何推荐算法介入的公众号平台,但时代在变,一起加油吧!

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存