你可以选择停用微信支付的消息服务,GPU 频率等来提升 APP 性能

摘要2019年9 月 17 日,期待已久的微信 7.0.7 for iOS
正式版上线了。1、概述与一周前更新的微信 7.0.7 for Android
内测版相似,此次更新并没有新功能上线,更多是一些细节上的改变。或许是为了与
Android 版本号同步,iOS 版微信的更新跳过了 7.0.6 版本号,从 7.0.5
直接来到了 7.0.7。为了帮助大家更好地了解此次更新情况,我们将微信 7.0.7
for iOS 的新能力,与微信 7.0.5 for iOS
版本进行了对比。目录如下:一、小程序「回到首页」功能强化,权限管理页上线;二、订阅号消息页面中的「未完成的功能」彩蛋下线;三、表情包选择栏改版;四、选择「照片」时的多选图片页与图片编辑页面改版;五、支持停用「微信支付」消息服务。2、小程序「回到首页」功能强化,权限管理页上线本次更新最大的亮点在小程序。点击小程序胶囊按钮中的「…」,你会发现所有功能被分为了三栏:第一栏为小程序的头像、名称,点进去后会跳转到「关于」页面;第二栏为针对小程序本身的操作,包括原本就有的「发送给朋友」、「添加到我的小程序」,以及一个新增的「回到首页」常驻按钮;第三栏为「浮窗」、「设置」、「反馈与投诉」,相当于把「关于」页面中的部分内容一并列在了底部菜单中。过去,只有用户收到朋友转发过来的小程序卡片时,按「…」按钮才会有「返回首页」的功能;本次的改版中,「回到首页」成为一个标配功能,这也让小程序更像是独立的
app,而不仅仅是方便分享和动态更新的「高级 H5 页面」。▲ 小程序菜单栏对比.
左为 7.0.5,右为
7.0.7值得一提的是,在小游戏内,没有「回到首页选项」,第三栏却新增了「成长守护」选项,在点击后将跳转到「未成年人成长守护」页面,家长可以为孩子设置「时间管‌理」、「消‌费管理」、「一键禁玩」等。▲
小游戏「…」中的「成长守护」从这些更新中,我们可以看到一个新的趋势:小程序正在「app
化」,它有了更明确的首页、更独立的权限管理。3、「未完成的功能」彩蛋下线还记得在「订阅号消息」页面,长按订阅号消息会出现「未完成的功能」彩蛋时,我们曾邀请过阿禅、keso
等人猜测一下微信的「彩蛋功能」可能是什么样的。我们把微信的心思猜了个遍,却怎么也没想到这个彩蛋在微信
7.0.7 for iOS
中说下线就下线了,只能说「未完成的功能」是真的完成不了了。▲
订阅号消息页对比. 左为 7.0.5,右为 7.0.74、表情包选择栏改版微信 7.0.7
for iOS 正式版中,表情包选择栏变得更高了,表情包缩略图也加大了。▲
表情包选择栏对比. 左为 7.0.5,右为
7.0.7原本的左右滑动选择同类表情包,变为了上下滑动,左右滑动则成了表情包类型的切换。5、多选图片页与图片编辑页面改版在与好友聊天时选择发送「照片」,或是发布朋友圈时点击「从手机相册选择」,即可进入多选图片页,此次更新中该页也有变化。相比微信
7.0.5 for iOS
版本,整个页面由浅色加深,页面顶部中间新增了一个相册选择按钮,替代了原本左上角的返回键。▲
多选图片页对比. 左为 7.0.5,右为
7.0.7而在选择图片后,依次点击「预览」-「编辑」,也能看到一些小变化:底部图标改变,表情包选择页面变化等。▲
图片编辑页面对比. 左为 7.0.5,中、右为
7.0.76、支持停用「微信支付」消息服务微信支付通知页面右上角原先的「…」变为了代表「设置」的齿轮符号。▲
微信支付页对比. 左为 7.0.5,右为
7.0.7点击齿轮,你可以选择停用微信支付的消息服务,停用该功能的同时会清空历史数据。不过,停用后并不会影响微信支付的日常使用,只是查询账单、联系客服、接收通知等功能就不能再微信支付消息通知中查看了。▲
点击微信支付右上角按钮后的对比. 左为 7.0.5,右为
7.0.7过去,微信支付的通知消息不能关闭,用户每次使用微信支付都会弹出通知。如果用户同时关注了所绑定的银行卡的公众号,还会遇到每一次消费两个公众号同时弹出通知的体验。微信支付推出早期,这样的设定可以让用户更清楚资金流向,减少用户的迷惑和焦虑,但是,当微信支付的应用场景和频次越来越多时,过多的通知也可能是用户的烦恼。这一次,微信把选择的权力交给了用户。除了上述明显的更新,「订阅号消息」页面中的「搜索公众号和工具」也进行了小调整,在微信
7.0.5 for iOS
中,这个搜索框需要下拉页面才会出现,且几个字居中显示;而在微信 7.0.7 for
iOS 中,搜索框固定在了标题栏下方,文字居左。▲ 订阅号消息对比. 左为
7.0.5,右为 7.0.7当然,并不只是在微信 7.0.7 for Android
内测版上做功能的增加,微信 7.0.7 for iOS 仍保留了一些「顽固特色」,比如
Android 上已有多时的小程序评分就还是没有出现。

摘要2019年9月24日Kik宣布关闭旗下聊天应用Kik Messenger。1、概述9 月 24
日, Kik Interactive 宣布公司将关闭旗下聊天应用 Kik
Messenger,并将员工人数削减至 19 人,聚焦加密货币业务
Kin。这家加拿大互联网公司对微信的启发不止是简洁高效的聊天形式,它扫描通讯录添加好友的功能也为微信借鉴。但赶上移动互联网早班车的Kik却没利用起流量红利,面对财大气粗的Facebook
Messenger和WhatsApp,始终难以盈利。「如果不是快死了已经没人记得的应用」名单上今天又多了一个名字:Kik
Messenger。微信诞生之初与米聊的战争,想必很多人都听说过,但事实上,微信的出现与远在大洋彼岸的
Kik 不无关系,不仅如此,后来腾讯还成了 Kik
的股东,实力上演青出于蓝胜于蓝。从「微信鼻祖」到难以为继,Kik
是怎么走到这一步的?2、惊艳亮相:被黑莓封杀、启发微信、米聊在互联网世界,Kik
是一个另类,这家位于加拿大的公司由一群滑铁卢大学的学生于 2009
年创办。Kik Messenger 于次年 10
月问世,主打跨平台消息传输。用现在的眼光来看,Kik
似乎无过人之处,但别忘了那是在 2010
年,彼时智能手机尚未大规模普及,微信、Line
等现在主流的通讯应用也还没问世,Kik 的出现可以说是革命性的,仅用了 15
天,其用户量便达到 100
万,其火爆程度甚至让当时拥有最受欢迎的加密聊天工具 BBM
的黑莓感受到了威胁,一个月后就将 Kik 紧急下架。Kik
的走红也引起了国内至少两家公司的注意:小米和腾讯。2010 年 12
月,小米的米聊率先上线,两个月后,腾讯也推出了微信。Kik
对微信的启发不止是简洁高效的聊天形式,它的扫描通讯录添加好友的功能后来也为微信借鉴,匹配通讯录功能的推出被视为微信用户量得以爆发的关键。3、难以盈利,先驱变镰刀但赶上移动互联网早班车的
Kik 却没充分利用起早期的流量红利,或许是偏安加拿大远离科技中心硅谷导致
Kik 少了些侵略性,还可能与缺少资源有关,总之,相比后来者,Kik
的成长步伐算不上快,直到 2013 年 12 月,其注册用户数才达到 1
亿,而比它诞生早一年的 WhatsApp 同期月活已有 4
亿,它的「学生」微信也早在 11 个月以前就宣布用户数突破 3
亿。即便如此,Kik 仍深受年轻人喜爱。2014 年 Kik 声称自己拥有 1.85
亿年轻用户,同期的数据也显示 14 – 25 岁年轻人在 Kik 所花的时间高于
Snapchat,仅次于 Facebook。此时的 Kik
虽然增长不够快,但依然受到资本追捧。2015 年 8 月,Kik 宣布获得腾讯 5000
万美元融资,其估值也达到了 10 亿美元的巅峰。Kik
寄托着微信国际化的希望,创始人泰德‧利文斯顿(Ted
Livingston)也毫不讳言想成为「西方的微信」的野心。然而,面对财大气粗且体量更大的
Facebook Messenger 和 WhatsApp 的竞争,Kik 始终难以盈利。2017
年,昔日的对手 Snapchat 母公司 Snap 已成功登陆纽交所,面临经营压力的 Kik
则把目光转向了风口渐起加的区块链,推出加密数字货币
Kin,允许用户用它购买一系列数字服务,Kik 通过那次 ICO 筹集了近 1
亿美元,也是主流科技公司中最早进行 ICO 的公司之一。不料这次 ICO 却让 Kik
惹上了与美国证券交易委员会(SEC)的官司,该机构指控 Kik
面向美国公民进行的 ICO
是「非法证券发行」,并且未向投资者如实披露财务状况,Kik 其实在 ICO
前已花光融资。起诉书中还披露该公司的成本远超收入、私募市场无人问津、用户流失严重等问题。争议的核心在于
Kin 是否为证券,SEC 坚称 Kin 属于证券并且违反了证券法,Kik
自然坚决予以否认。可以说,与 SEC 的法律纠纷成了压垮 Kik
最后一根稻草,「与 SEC 合作 18 个月后,他们给我们的唯一选择是给 Kin
贴上证券标签或与他们对簿公堂。成为证券将杀死任何加密货币的可用性并为该行业树立危险先例,」利文斯顿在博客中解释道,「因此,由于
SEC
努力在将几乎所有加密货币定性为证券,我们决定采取进一步行动。」总之,眼下
Kik 的心思全在与 SEC 的抗争和 Kin 的推广上,自然也就没精力再管赔钱的 Kik
Messenger。老用户或许有印象,2010 年评选的年度最佳应用正是 Kik
Messenger,大概也算是喂了一口「毒奶」吧。

摘要微信自用的安卓APP与系统间通信解决方案——Hardcoder已开源,该方案能让微信的整体性能提升10%-30%。1、Hardcoder
的诞生随着微信越来越复杂,性能优化变得越来越难做,优化所带来的效果提升也越来越不明显。所以我们⼀直在思考,该如何突破这个优化的极限?直到有一次与厂商的交流我们了解到,部分厂商会针对微信做一些小改动,其中比较典型的就是“暴力提频”。系统在识别到微信启动,页面切换等场景时,会粗暴地提高
CPU 频率,从而提升 APP
运行的性能。但由于厂商无法准确判断微信场景,暴力提频效果并不理想;而如果过多地提高
CPU
频率,又对手机的功耗有影响。这一方案启发了我们,我们何不跳出软件的范畴,在手机硬件的层面上挖掘更多的性能优化空间呢?于是
Hardcoder 框架应运而生。2、Hardcoder
是什么厂商暴力提频效果不理想是由于在目前 Android
框架下,手机没有办法准确获知 APP
需要资源的时机。如果我们需要挖掘手机硬件层面的性能优化,就需要跳过
Android
操作系统的应用框架,在应用开发者和硬件之间打开一个通道,让硬件可以直接根据应用开发者的需要进行资源的调度。Hardcoder
构建了 APP 与系统(ROM)之间可靠的通信框架,突破了 APP 只能调用系统标准
API,无法直接调用系统底层硬件资源的问题,让 Android APP
和系统能实时通信。利用 Hardcoder,APP 能充分调度系统资源如 CPU
频率,大小核,GPU 频率等来提升 APP 性能,系统能够从 APP
侧获取更多信息以便更合理提供各项系统资源。同时,对于 Android
缺乏标准接口实现的功能,APP
和系统间也可以通过该框架实现机型适配和功能拓展。3、Hardcoder
框架通信流程Hardcoder 框架分为 Server 端和 Client 端。其中 Server
端在厂商系统侧实现,Client 端以 aar 形式合入到 APP中。APP
在需要资源的时候,向 Hardcoder 的 Client 端发出请求。Hardcoder Client
端接收到请求后向 Hardcoder Server 端发出请求。Server
端接受到请求后会根据请求参数向硬件申请不同的资源,比如调整 CPU
频率,把线程绑定到大核运行等,实现了 APP
到系统的通信。同时系统也可把当前系统的状态通过 Hardcoder Client 在
Server 端注册的接口回调通知到 Client 端,从而 APP
可以获取到系统状态,实现系统到 APP 的通信。Hardcoder Client 端与 Server
端采用的是 LocalSocket 的通信方式,由于 Hardcoder 采用 Native
实现,因而在 C 层使用 Linux 的 socket 接口实现了一套 LocalSocket
机制作为 Client 端与 Server 端之间的通信方式。Hardcoder
通信框架有以下特点:1)系统服务为
optional,实现上可以完全支持或者部分支持;2)框架实现不依赖于特定
Android 系统,如 API level 限制;3)APP
的功能和业务特性不依赖于该框架。4、Hardcoder 适用场景和效果Hardcoder
框架有效提升了微信启动、发送视频、小程序启动等重度场景的速度,朋友圈的滑动流畅性也明显提升,平均优化效果达
10%-30%。此外,由于微信作为主动请求方可以在场景资源把控上做得更精细和准确,Hardcoder
在性能得到提升的同时仅增加了 2% 的电量消耗,相当于用 2% 的功耗换取平均
20% 的性能提升。Hardcoder 框架目前已接入
OPPO、vivo、华为、小米、三星、魅族等主流手机厂商,覆盖 4.6 亿+
设备量。5、Hardcoder
开源从微信技术开放共享的理念出发,我们在腾讯内部进行了 Hardcoder
框架的宣传和推广,包括手机
QQ、企业微信、天天快报等多个应用团队接入。其中手机 QQ 接入 Hardcoder
后,在启动、打开聊天界面、发送图片等场景的平均优化效果达
10%-50%。我们现将 Hardcoder 框架开源,让更多 Android 开发者享受到
Hardcoder 框架的价值,解决大家在性能优化和机型适配上的烦恼。欢迎大家查阅
github 网址:
Hardcoder一、通过 Hardcoder 技术方案介绍,了解 Hardcoder
实现原理以及框架;二、使用工程自带 testapp 快速使用 Hardcoder
并验证效果,具体请见 Hardcoder Testapp 测试指南;三、APP 接入
Hardcoder,具体请参见 Hardcoder 接入指南:1)下载 Hardcoder 工程编译
aar;2)项目 build.gradle 引入 Hardcoder aar;3)进程启动时调用
initHardCoder 建立 socket
连接(一般进程启动时需要请求资源,因而推荐在进程启动时调用)。每个进程都是独立的,都需要调用
initHardCoder 建立 socket 连接,建立连接后每个进程维持一个
socket,进程退出时 socket 也会断开;4)initHardCoder 回调成功后调用
checkPermission,传入 APP
已申请的各个厂商鉴权值;5)在需要请求资源的场景调用
startPerformance,传入请求资源的参数。若场景位于进程启动阶段,比如 APP
启动,需要在 initHardCoder 的回调成功以后再调用
startPerformance,确保连接已成功建立,或者判断 HardCoderJNI 的
isConnect() 检查 socket 是否已连接。6)场景结束时主动调用
stopPerformance,传入对应场景 startPerformance 时的返回值 hashCode
作为参数,停止本次请求。7)测试性能,APP 可对打开/关闭 Hardcoder
的情况做对比实验,测试性能是否有提升。四、向厂商申请线上权限,具体请见常见问题;五、发布带
Hardcoder 功能的 APP。附录: github的wiki
文档链接Hardcoder产品方案介绍:
技术方案介绍:
testapp
测试指南:
接入指南:

相关文章