![](https://img-blog.csdnimg.cn/20201014180756928.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
开发随笔
zerolook
"A"和"Z"的距离可能是最远的,但也可能是最近的!
展开
-
让Android 5.0 也能运行 MAUI Blazor App
让android 5 也能运行MAUI Blazor App原创 2022-08-18 09:20:30 · 1071 阅读 · 0 评论 -
缩减string在内存中的占用
方案一下全部都不好实现,但确实是有效,或许要极限控制内存的时候才会用到。编译器把重复的字符串合并。字符串不应该在代码段中出现,全部动态加载,减少在内存中驻留。由开发语言设计者提供一种不保存key原值只有key的hash值的hashmap。...原创 2021-12-28 16:50:03 · 284 阅读 · 0 评论 -
typescript的Hashmap的简单实现
export class Hashmap<V>{ public map: { [index: string]: V } = {}; public put(key: string, value: V) { this.map[key] = value; } public get(key: string): V { return this.map[key]; } public remove(key: string) { delete this.map[key]; }原创 2021-11-29 11:39:42 · 336 阅读 · 0 评论 -
提升web app性能的一种方法
原理常规的web app 都会在android壳里创建web server 用于本地html等文件获取。这个web server 不是必要的,那些http请求也是不必要的,可以拦截浏览器的get请求代替。然后就没有web server的开销,没有了真实的http请求创建及解析开销。因为是拦截,所以可以把原来的域名(localhost)改成api的域名,然后跨域问题也没有了。操作过程浏览器拦截get请求,原启动路径假设为http://localhost/index.html 改成https://api原创 2021-11-18 10:21:35 · 1438 阅读 · 0 评论 -
关于既省内存而又快速比较string的一种思路
思路:目前我所知的开发语言中对string处理都是独立的、不唯一,如果每个string对象都是唯一的,不管从哪里加载只要内容一样,引用就是相同的,那么做区分大小写的字符串比较的时候就可以只比较他们的引用是否相同就可以了。试想一下,这样做的话,字符串比较速度极快,内存占用也会减少(但需要额外的引用管理和同步)。题外:为什么大脑可以记忆那么多事情,容量很大?为什么相似的东西容易混淆、覆盖?可能是因为大脑是使用唯一存储策略:因为唯一存储所以减少冗余,可以存更多。记忆事件时候,人被抽象为某个唯一个体,所以不需要像原创 2021-09-03 10:13:21 · 86 阅读 · 0 评论 -
C# 字节数组 byte[] 快速比较算法
注:代码原创转载或使用请标明出处。目前C#最高版本net6 preview 7,我没有找到快速比较两个字节数组 byte[]的api,如若谁知道请在下方留言,谢谢。在没有使用某些cpu特有的比较指令实现的纯C#的快速比较byte[]的思路:把byte[]转成byte*,然后利用64位cpu一次可比较64位数据的特点把byte强制转换成long进行比较理论上速度可以快一倍。原本32位程序应该使用int比较,但经测试发现在64系统上32位程序使用long会比使用int*快一点。代码如下://需要在项原创 2021-09-02 11:20:56 · 4458 阅读 · 1 评论 -
优化html app(带浏览器壳)的图片获取显示
问题描述:很多封浏览器壳的html app保存显示图片都是使用“data:image/png;base64,……”格式存储或放到img标签的src里面显示。在小图片少数量的情况没有问题,但一多起来就容易引发mobile端的OOM,甚至直接闪退。原因:src里面放的字符串是base64,是整个图片的blob 占的空间的1.5倍的字符串,而img 显示的时候要解析src为图片对象,这个占空间更大。src的值不会因为解析完就会释放,有可能会一直存在,依赖浏览器引擎和src的值是否在其他地方存在(一般在数据源的地原创 2021-08-04 15:58:57 · 177 阅读 · 1 评论 -
关于android屏幕适配的多套图片合理处理方式
关于android图片大小合理处理方式现况解决现况传统图片处理都是制作多套图片大小已适应各种屏幕尺寸,但这样并不能涵括所有的屏幕设备,这样做也是不优雅的。虽然有工具帮忙缩放,但这些图片在安装包里面都是多余的。解决一个合理的优雅的处理方式:安装包里只保留最清晰版本的图片,其他图片根据控件显示大小需求加载缓存缩放后的图片(不能使用图片决定控件大小,因为这是不合理的)。...原创 2021-07-22 09:26:10 · 197 阅读 · 1 评论