Android Webview 加载额外 CSS

这个需求也是挺好玩的。主要是因为女朋友用的一个 APP,是城市里面的一个实时公交的 APP。但是作为一个会点代码的人,一看到这么一个 APP,第一反应是,为什么这种粗制滥造的 APP 可以存活于世,而且还是政府单位发布的。 本着,吐槽一个东西,就要拿出一个比他更好的解决方案的思路,所以我就花了将近一个下午的时间。重新做了一个 APP 送给她。 其实,APP 的难度很低,主要是实现思路比较好玩。熟悉 Firefox 的同学应该知道 stylish 这个插件,他可以进行一些 CSS 的重写工作,同时覆盖到页面上。这样的效果就是可以完成去广告和简化页面的效果。 所以这边,我也准备使用这个思路。当然,我先看看网上有没有对应的资源。避免重复劳动。 然后就搜到了这么一个问题 关于Android中WebView在加载网页的时候,怎样应用本地的CSS效果?就是说... [阅读全文]

一场叫做研究生的游戏开始

9.1, 传统意义上,应该是开学的日子,因为是研究生,所以写一下期待下吧。确切的说,应该是 9.7 开学。 自从 4 月份辞职以来,一直是以自由身的身份在生活。一开始准备托福,但是,中期遇到了可能会相伴一生的人。所以在对之后的规划上出现了点变动。所以之后的日子都是更多的在训练自己的一些解决问题的思维能力。 不过这段时间的训练下来,总的来说还算是比较满意的。Codeforce 因为才打了两场,第一场因为不熟悉套路,rank 了1500,有点郁闷,第二场 372 的 rank 还是比较满意(A 题看错题目 WA 3 次。。),目前稳定在了蓝名,6000 名,LeetCode 目前是 2000 名,HackerRank 目前是 4000 名。 接下来的目的就是将 CF 达到紫名,然后 LC 刷进 1000,HR 就打进 2000 吧。过段时间找到合适的网... [阅读全文]

吐槽 Markdown 的设计

之前一开始还是很喜欢 Markdown 的,相对来说比较的简单,从 office word 转到 mardown 的一段时间,适应了之后,写文章的速度就有了很大的提升。 但是,自从开始了编写 markdown-parser,一个 markdown 的解释器,就发现,markdown 的规范都是扯淡,并没有一个很好的官方规范性的文档和转义规范。 比如无顺序的列表,-,+,* 都可以作为前置表达符。但是有的解释器,对*号并不支持。关于引用部分就更加的随机了。如下的一段文章 > Hello World \``` Hello World \``` 有将代码块放入上述引用块的,也有分开的。对于这种有歧义的语义,似乎作者并没有给出一个正确的渲染结果。其次,对于列表嵌套引用块,很多解释器都选择了无视。而对于 html 标签的支持,有的解释器支持,... [阅读全文]

快速求出某数的所有约数

故事是这样的,有一场比赛题,本来应该是考察 DP 的,但是算法写出来之后,一值暴 TLE,我一开始以为是 C++ 的 map 是 log(n) 的复杂度,于是改成了 unorder_map 试了下,结果还是 TLE。最后花了很久定位到求约数的算法超时。 按照人惯性的思维,求一个数的约数,直接使用一个 for 就可以了。而且算法的复杂度是 O(n) 具体一点可以说是 O(sqrt(n)) 也是可以接受的。 但是,还是有另一个更加快速的方法。 using namespace std; int prime[100000]; bool isPrime[1000005]; void getPrime(int x){ for (int i = 1; i < x; i += 2) { isPrime[i] = 1; ... [阅读全文]

字符串纠错

故这样的,之前在 Leetcode 遇到一道题:『Edit Distance』, 当时做的时候并没有太多的思考,原因也很简单,不知道这道题的算法什么时候可以用得到。 直到,最近在看搜索引擎部分的算法,在处理用户的拼写异常的时候,比如,当用户搜索 『苏州大雪』的时候,怎么能进行纠错为『苏州大学』。 亦或者,在进行爬虫数据筛选的时候,比如在 B 站进行动漫数据抓取的时候,有很多的 UP 主会对动漫的名字做一定的修改,比如『(xx 字幕组)小林家的龙女仆』或者『小林家的龙女仆(高清)』。按照我之前的处理方式,还是很简单的 KV 存储,所以在计算弹幕和播放量的时候,并没有统计合并这样的数据。而从实际情况上来看的话,这两个的数据是应该统计在一起的。 所以,发现这个算法也是可以用的。而且,这个算法确实挺有意思。 using namespace std; ... [阅读全文]

搜索最近的店铺 or 找最多店铺的点

这两个问题,应该是电商网站或者说 O2O 业务中最常用的功能。在之前,我也想过该题的解决方法。 第一个问题最简单的方法就是,一个 for 遍历周围所有的数据。通过欧式距离的判断,进行从小打大的排序判断,然后推送结果给用户。但是,当商铺基数足够大的时候,似乎,每次的 O(N) 操作,都是一个不小的时间开销。于是,可以通过进行地区的划分进行优化。 比如在二维坐标系中,划分为 N * N 的正方形区域。进行距离判断的时候,只需要查询用户当前区域和周围 8 个区域的店铺,然后进行搜索,然后排序。同时,也可以针对每个区域进行 cache,因为某个区域间的商铺的排序顺序基本不会有太大变化,而且即使是不同的距离,基本也就是 50 ~ 100 米的误差,某种程度上,用户也能接受这样的误差。 所以,这个角度看,似乎是个不错的解决方案,毕竟通过后台的距离判断可以进行离... [阅读全文]