全村人的悄悄话

Since the release of Graphics-Shape library in April 2023^[1], there are still few related materials. Recently, I read this article Fun with shapes in Compose^[2], and I found that I can use shape to achieve many functions. What is ShapeIn simple terms, with Compose, you can create shapes Composable for polygons^[3]. This may not be very intuitive, so let’s take a look at what kind of content Shape can create: Although it can’t directly handle the transformation problem between any 2 shapes(Of ...

虽然2023年4月Graphics-Shapes库就已经被发布^[1], 但是相关的资料仍寥寥无几, 近日浏览 Fun with shapes in Compose ^[2]这篇文章的时候, 才发觉已经可以用shape来实现很多的功能了. Shape是什么?简单来说, 借助Compose, 您可以创建由多边形组成的形状^[3]. 这么说可能不太直观, 那么我们可以下Shape都可以创建出什么样的内容: 虽然不能直接处理任意两个形状之间的变换问题,(当然, 这个问题是设计时的问题.) 但是对于多边形结构之间的变化来说, 却能帮助我们简化大量的操作. Shape能做到什么?正如前文中所说, Shape可以帮助我们完成多边形之间的变化. 我们先看一下, 首先展示的的6种预设的情况. 然后是作为clip裁剪显示图片的效果, 这里添加了缩放和选择的效果, 如果有需要的话可以根据实际情况添加需要的效果. 下面就是对开始和结束多边形的设置了.需要注意的是, 部分预设的情况是可以自定义形状的.^[4] 下面我们依次显示不同预设效果都可以如何进行条件. 需要注意的是, 在实际使用的过程中, 如果直 ...

Think of current Android Architecture from UseCase “No silver bullet.” I think everyone has heard this sentence more or less. It tells us “We can’t find an universal method to solve all problems.”As wo all know, we have many architecture designs, but we can’t use one of them and use it to design all of our projects.As new architecture designs are constantly emerging, from chaos to MVC, MVP, MVVM and MVI.Architecture design is also evolving in continuous integration. We are also trying to find a ...

从UseCase的理念看Android当前的应用架构设计指南 No silver bullet.(没有银弹) 相信这句话大家都或多或少的听到过. 它告诉我们, 我们无法找到一个通用的方法来解决所有的问题.就和我们常常遇到的各种架构方式一样, 我们无法使用同一种架构方式来完成所有的架构设计.就如不断有着新的架构理念出现一样, 从杂乱无序到MVC, MVP, MVVM和MVI. 架构设计是在不断的融合发展的. 我们也在不断的发展和思考过程中尝试出一条适合解决我们现阶段的问题的道路. 架构是对客观不足的妥协, 规范是对主观不足的妥协. 我的设计架构认知史在实际的开发过程中, 大家或多或少的遇到了各种各样的架构设计. 也在不断的学习和成长过程中形成了自己的理解.而我对来说, 我理解中的架构设计, 大概是如下几个阶段. 混沌初开, 啥也不是.这个阶段大致出现在从小学接触编程(说你呢, 小乌龟)直到大学初期的阶段.在这个阶段下是完全没有任何架构设计认知的.秉承的理念就是, 能用就行.现在想想那时候确实也是不需要这些架构设计, 完完全全的实用主义. 倒也符合事务的发展, 类似前几年的摩尔定律 ...

“寒塘数树梅，常近腊前开。” 好吧, 开摆了是, 本来打算仿仿这个动画, 但是一场无情的流感打败了我,一直都不是很有精神, 只能先写点简单的来找找状态了. 同样的原版效果如下, 代码可以访问codeopen.io来查看. 这个是实现的效果, 虽然有时候长出来的树显得不拘一格, 但是最终的效果还是差强人意的. 虽然看起来简单, 但是写起来却一点也不难. 刚好结合着Compose一块来复习复习单纯的”树”. 本来是打算这么写的, 但是写完后发现没啥内容啊, 最难的事情可能就是如何生成一颗看的过去的腊梅树了吧. 所以最后添加了一个四季的情况, 春天的雨, 夏天的夜, 秋天的光, 冬天的雪. 每个季节还留了一个小彩蛋动画, 也算是把compose中对canvas的使用情况的一个大复习吧. Spring Summer Autumn Winter canvas 是我个人认为传统Java View和Kotlin Compose中最为接近的一部分了先说说为什么会有这样的结论. 诚然, Compose对Canvas也进行了底层设计和架构的重写, 但是当我们在K ...

休了一个长假, 换了换脑子, 敲起键盘来突然不知道写的什么内容笔记好. 刚好最近搞了个整活的网站, 记录一下整个整活的过程. (虽然整活, 但是Vercel是真好用啊.) 作为一位多年的整活偷懒白嫖达人, 我也开发过不少有用的没用的应用和网站, 这次的网站上线的出奇的顺利. 甚至分文没花守住了三天将近30k的访问量.(域名的钱不是钱, 是投资.) 大家或多或少的都尝试过部署一些自己的小功能, 可能是个网站, 可能是个服务器或者数据库. 但是这个功能都需要大家拥有一个个人独立服务器和公网ip. 而现在的各种云服务的供应商, 大的老用户不如狗, 小的就是买彩票. 三个九的保障率都快达不到(是吧, 某鸟)(我就偷个懒懒写了几天, 你真就三个九都达不到了?). 如果想租个能用的服务器, 一个月也得五六十. 开个会员十五都犹豫半天的我们, 还能开这个? 而且大家的普遍的需求就是构建一个自己的小工具, 分享一下自己使用的小网站. 不想太多的费心和费力, 能自动部署和提供各样实用的小功能更好了就. 重要的是免费. Vercel这个网站就是Vercel, 相信不少的朋友们都或多或少的听过或使用过 ...

最近由于没有了工作所以突然有了一个很长的假期, 就出去散了散心, (签证还没下来的时候就把票买了, 算是一场说走就走的旅行吧) 在日本一共待了十三天(毕竟签证只有十五天), 也就在东京和附近转了一圈, 还遇到了一次台风, 不过台风, 八级? 还没我家的风大. 想记录的东西不少, 有时间慢慢来吧, 不过最想记录的的是富士山西边身延线的乡下玩的一天. 大概路线如下, 早上从富士吉的河口湖附近出发(公交车, 一个多小时一辆, 全车都是小学生? 不是 你们早上6点多坐公交一个小时去上学?) 好吧这一路是看了摇曳露营来的… 本栖湖前一天从富士吉骑车去过了…. 来回五十公里. 不愧是我 时间上因为定了甲府的酒店, 顺着身延线就主要去了 内船, 身延和甲婓常叶三个位置, 其实每个地方浏览的位置大概也就一个小时左右, 身延线确实给我上了一课, 中午的时候甚至两个小时才有一班的车. 第一站, 内船. 十分符合我的刻板印象的乡下车站, 这个车站甚至没有工作人员, 下来了的第一件事情我是在想我怎么回去? 问了之后才发现, 原来来的时候补票的人和我说的车上买票还有只收现金在这等我啊. 没错, ...

Become with our business and function iteration, the size of App is alse iteration. It is not obvious in the early stage or special App, but if you want you App get more better user experience, you have to consider the size of App. The size of App directly or indirectly affects the important indicators such as download conversion rate, installation time, disk space and etc. According to the internal data of Google, when the App size reduce 10M, the average download conversion rate can increase ...

随着业务和功能的不断迭代更新, App的安装包大小也在不断的增加. 初期或者特定功能的App或许不明显, 但是如果你想要你的App获得更好的用户体验, 那么缩减App安装包的体积是你不得不考虑的一部分. App安装包的大小直接或间接地影响着下载转化率,安装时间,磁盘空间等重要指标. 根据谷歌商店的内部数据,APK体积每减少10M,平均可增加1.6%的下载转化率. 换句话说, 你的App安装包每多6Mb, 你的用户增长就会减少1%. 而这个比例, 或者说App安装包的大小, 在新兴市场中受到的影响更大. ^1 当然, 即使没有详尽的数据说明, 我们也能明确的感受到App安装包的大小对我们应用的影响. 那么, 我们又改如何缩减我们的App安装包大小呢? 我们先来看一下Google官方推荐的方法: Reduce your app size 首推的方法就是使用App Bundles, 而App Bundles的主要功能就是在应用安装时自动选择对应分辨率下资源文件, 来达到最低成本减少应用大小的目的. 而关于减少App安装包大小的部分,我们可以看到大部分的篇幅都是关于如何通过处理资源 ...

虽然我使用Compose已经有了一段时间的, 但我还是觉得使用起来束手束脚的. 究其原因, 大概是coding时的思路还没有完全转换过来, 还没有沉浸在”Compose is Function”之中. 和我们熟悉的View不同, 当我们调用Compose之后, 我们就失去了它的修改器, 而Compose也只能按照我们之前设计好的功能去响应我们的操作. 除此之外阶段(Phases), 也是一个可以使得你的Compose变的得心应手的入口, 虽然这篇文章不会进行相关介绍, 但我也会在后续的文章中进行介绍. 在了解Side Effects之前, 我们需要先简单了解一下Lifecycle of composables Lifecycle of composables相信大家对Lifecycle都十分的熟悉, 在我们的Android项目开发时, Activity及Fragment的Lifecycle对我们的功能实现提供了极大的帮助. 通过Lifecyle我们可以很便捷的处理页面不同时期的状态. 想象一下, 如果将Compose变为一个Activity, 那么许多的功能我们都可以通过Lifec ...