越狱版的腾讯手机管家可以和360一样修改运营商名称么？_百度知道
越狱版的腾讯手机管家可以和360一样修改运营商名称么？
不可以的，腾讯手机管家没有这个功能。越狱后可以修改运营商图标的插件有很多，例如zeppelin、360，下面以Zeppelin为例介绍下使用方法：（其他软件同理）Zeppelin是一款非常强大的运营商Logo自定义修改插件，内置多套精致图案并且提供用户自制Logo导入替换功能。安装使用方法：第一步： 越狱后在Cydia检索安装Zeppelin（如果检索不到请自行百度Zeppelin源，添加源后重新检索下载）。第二步：如果想替换运营商文字，进入系统设置——Zeppelin，点击右上角【Carrier Text】进行修改替换。第三步：还可以替换各类运营商图标，点击【Theme】进入选择（该插件内置部分图标），立即生效；还可以自制或者论坛检索Zeppelin图标文件导入/Library/Zeppelin目录下，然后回到系统设置——Zeppelin进行选择。
其他类似问题
为您推荐：
提问者采纳
截个图我看看 谢谢
我卸载了，如果只是单纯想该运营商，推荐zeppelin，那才是神插件
Cydia里添加吗
提问者评价
太给力了，你的回答完美的解决了我的问题！
其他5条回答
您亲管家用户 管家暂支持功能谢您反馈意见我谨慎考虑谢您腾讯手机管家支持
貌似只有360可以，
一样可以修改
一样可以修改
腾讯手机的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁手机管家流畅度SM监控——卡顿数据收集篇-终端安全那些事儿-微转化
关注、分享终端安全.
【震撼视频】真实的朝鲜现状，美国记者冒死偷拍
●●●●●●●●●●●
热门公众号Accounts
精彩内容热门推荐
游侠旅行全国首创旅游分期付款,专注于马尔代夫、巴厘岛、帕劳等高端海岛度假旅游,自由行,国内旅游,旅游攻略.
gh_ef9a7edf42a0
不媚众, 不恶俗;纯精品,纯公益.读高品味文章,享高品质人生!
海峡都市报闽南版官方网站闽南网()闽南地区强势网络媒体
成年人的世界;男女那点事;两性关系、心理、姿势、姿式、技巧、提高;我们传递的不是色情和低俗;而是生活和艺术;你懂得!
terror-corner
搜罗各类恐怖故事、漫画、电影、谜题,如果你够胆,就来关注我吧!
cctvnewscenter
观察者网,智库与专业新闻媒体的完美结合.
参与、沟通、记录时代.
MinBingZhiKu
【民兵智库】由白益民(民)、宋鸿兵(兵)携手发起成立,旨在对&东西方战略&、&国家经济安全&、&社会和谐发展&提供前瞻性解读和智力支持.前者著有《三井帝国在行动》,揭秘日本产业战争的棋局,后者著有《...
gh_72cc9cd5c8da
本微信号为读者提供珠海本地居家、生活、娱乐、新闻等资讯,搭建珠海生活互动平台.
传递有价值的信息!
手机管家流畅度SM监控——卡顿数据收集篇
阅读&23598&发表& 16:10:31
一、管家流畅度现状 应用卡顿问题一直是手机App难以言明的痛，一来不能准确的说出到底是不是卡，卡顿多严重，无法对卡顿进行量化；二来就算知道卡顿，要找到为什么卡顿也是千难万难的问题。卡顿问题是业界共识的难以重现和监控、解决的一大难题。 在管家内，我们同样遇到了卡顿问题。每个版本都有用户反馈管家卡顿，根据5.6版本数据显示，因为管家让手机变卡而卸载管家的比例在所有原因中占27%，排名第一！ 以下为详细数据图：
管家让用户感知到卡顿，主要有两个方面表现： 1.安装管家导致手机变卡：管家的插件较多，占用内存也较大，在低内存的手机触发LowMemoryKill，会导致很多app频繁重启（包括管家在内），导致手机卡顿。管家已经建立起了一套完整的监控流程过海量机器进行监控，并在每个版本发布前对应有长板测试，对待机内存和功耗进行测试，并持续不断的进行插件加载优化，减少管家内存的使用。 2.管家内部UI上的卡顿: 管家内部UI卡顿，未建立起量化、监控体系，对卡顿问题无法有效进行解决。 如果我们能在管家内让用户保持流畅的体验，除了改善用户对管家的卡顿印象，同样也能提升管家的产品口碑，意义重大。既然如此，管家内就非常有必要建立起一套对于流畅度的量化，监控，改进体系。 在我司内部，浏览器、应用宝等App已经建立起了对于页面流畅度的自动化监控，但更为深入的原因分析和卡顿现场数据收集还没有建立起来。基于现状，我们只能自己动手来完成这还欠缺的一部分。 通过对可能造成卡顿原因的分析研究，并综合专项测试组对流畅度的量化成果，管家内制定了流畅度量化、流畅度自动化监控、卡顿现场数据自动收集、自动化结果输出，问题跟进处理、问题修复验证的一套流程基于专项测试组的流畅度量化成果，管家现已建立起流畅度量化标准，利用SMoothness来进行量化，SM值反映了每秒内App最高绘制能力以及当前App的流畅程度。由于本文的重点在于卡顿数据收集和分析，流畅度量化标准部分可详见sophiewu的大作《手机管家Android流畅度测试监控篇》，此处省略X万字。建立起卡顿数据收集系统，收集卡顿现场的各种数据，方便我们对于卡顿原因的定位和解决。要建立卡顿数据收集系统，我们需要弄清楚并解决以下问题：1. 造成卡顿的可能原因是什么？ 2. 怎么找到卡顿时的具体原因？ 3. 找到卡顿的具体原因要怎么解决？二、造成卡顿的原因 我们用一张图来说明一下这个问题：
先普及一个概念，按照Google官方的说明，一个程序标准的帧率为60FPS，意思就是1s之内屏幕需要刷新60次，而每帧的标准处理时间则为16.6ms，保证所有的动作能在16.6ms内完成，我们的应用就能保持流畅度体验。 在一个绘制周期中，即每一帧的刷新，需要通过CPU和GPU两个过程的处理，CPU主要负责程序内部逻辑处理，GPU则主要负责图形的渲染工作，经过这两个阶段的处理，最后画面会显示到硬件设备也就是屏幕上。 从图上可以看到，第一帧中CPU处理的时间是合理的，但是由于GPU的处理耗时过长，导致在第一帧的16.6ms内无法完成对B帧的渲染，那么屏幕只能保持A帧画面，如果此时是正在运行着动画，那么就会出现卡屏的情况。 同样，在第三帧的时候，画面B已经Ready，被显示到屏幕上，重新更新A画面时，由于CPU中发生了耗时过长的处理，导致无法在16.6ms内完成对A画面的渲染，第四帧只能仍然保持B画面，又发生了一次卡顿，直到第五帧时，A画面才得以显示。 卡顿常见原因主要有如下： 1. GPU耗时导致卡顿，造成GPU耗时原因与画面的绘制有关，比如界面存在严重的过度绘制，绘制高清大图等，与UI View的绘制方法如draw(),onDraw(),dispatchDraw()等关联。 2. CPU的耗时导致卡顿，主要是由于UI线程有耗时较久的操作，比如处理大图片、进行耗时的IPC通信等，自然会拖长UI线程处理的时间，导致无法在16.6ms内处理完相关逻辑，进而导致了界面刷新滞后，给人带来的直接感受就是连续的动画过程发生了卡屏的现象。 UI线程通常会运行以下方法：1) 绘制相关方法2) UI布局相关方法：onMeasure()，onLayout()3) Handler： handleMessage()；post(Runnable)；4) Activity相关方法：如onCreate()，onResume()，onStar()，onStop()等。 3. GC导致卡顿，如果发生内存抖动或短时间申请大内存等情况，会引发GC，导致主线程停滞，从而发生卡顿。 4. 并发线程数过多导致卡顿，如果不对线程进行限制，并发的线程过多时，会让CPU分配给UI线程的时间片缩短，导致UI线程不够时间处理界面的刷新，从而导致卡顿的发生。三、怎样找到卡顿的具体原因 上面说到，UI线程运行了耗时的方法会造成卡顿，那么卡顿数据的收集灵感就源自于这里，如果我们能对在UI线程运行的主要方法进行监控，自动收集处理时间过长的方法，同时捕捉卡顿现场的其他数据如当时所处页面、线程池等相关信息，那么就能为卡顿的解决提供有效的现场数据。 首先我们来看管家内大部分界面的UI结构，如下：
外层为一个BaseActivity，BaseActivity的contentView则为统一的PageView容器，装载了页面的真正View，基于这种结构，我们可以在UI库中对BaseActivity进行Activity相关方法的监控，在PageView中进行View的UI相关方法监控。监控的方式类似插桩，在方法开始和结尾分别记录时间，如果方法运行过长，则把耗时过长的方法记录到内存中，整个流程结束后，内存数据整理之后保存到SD卡中。于是，管家在如下几个方面建立了监控： (1) Activity方法监控。 管家现已在BaseActivity的包括以下方法在内实现了监控：onCreate(),onStart(), onNewIntent(), onKeyUp(),onDestroy(), onCreateView(),onKeyLongPress()等。 示例如下：
(2) PageView方法监控。 由于PageView属于所有界面的根容器，从这一层进行监控，可以监控到其下所有子View的情况，同时也可以在本层中利用自己作为根节点进行遍历，寻找最深层次和View总数，现在管家PageView中已实现对下列方法的监控：dispatchDraw(), onInterceptTouchEvent(), dispatchTouchEvent(),onMeasure(), onLayout(), onDraw()。 示例如下：
而在onMeasure时，会以PageView作为根节点，向下遍历，寻找最深层次和View总数，如下：
Activity和PageView监控到的耗时方法，会缓存在UI库的SMData中，PiSM可以直接访问到UI库，从而直接读取到SMData中的耗时方法数据。 (3) Handler监控。 管家使用BaseHandler作为Handler的包装，对handlerMessage进行监控，PiSM插件在初始化时会创建TaskInfoObserver实例设置BaseHandler中，handlerMessage()的过程会受到Observer的监控，超时的handlerMessage会自动被记录到内存中。
至此，管家内重要的主线程方法就已经列入了监控的范围，超时的方法会自动被记录到内存中，流畅度插件与业务插件的连接架构如下：
(4) 利用VSYNC收集现场数据。 首先我们简单了解一下VSYNC（垂直同步）机制，在Android 4.1中引入了VSYNC机制,是Vertical Synchronization的缩写,是一种在PC上已经很早就广泛使用的技术，可以简单的把它认为是一种定时中断，CPU在VSYNC信号到来时将控制权交回给主线程进行界面刷新，如图：
理想情况下，1s之内会发生60次VSYNC中断，VSYNC同时提供了Choreographer类，定义了一个FrameCallback回调，这意味着使用反射的方式，我们可以在每个VSYNC中断中收到回调，这个就是流畅度插件依赖的基础。 由于UI库作为工具库的特殊性，能监测到耗时方法，但并不能获得其他额外的信息，如当时所处的界面，线程池信息等，那么就需要流畅度插件与之相应配合。在流畅度插件中，每次VSYNC的回调，检测一下UI库中或BaseHandler是否记录到了超时方法，如果有，说明这个周期中已经发生了卡顿，那么流畅度插件立刻收集此次VSYNC中断所处的插件ID，ViewID，当时线程池等信息，第一时间保留下卡顿当时的现场数据，准确，高效。 收集的数据最终会整合起来生成一份文件保存在SD卡固定目录下。以下为收集的卡顿数据示例：
一清二楚有木有！那么如何根据这里面的信息来解决卡顿，不要急，后面会有详细说明。卡顿数据收集流程图如下：
(5) 未解决的部分。 上面说的都是管家已实现的部分，仍有未解决的部分需要去完善。a) 单次时间并不长，但调用频繁的方法暂时无法进行监控。 b) 监控点现在还只侧重在Activity回调以及Handler部分，主线程也会调用的BroadcastReceiver，Service等暂时还没加入监控。四、总结 1.布局。UI布局的不合理，过深的层次，过多的视图，导致界面过于复杂，占据无用的视图，除了会耗费UI线程更多的测量、布局、响应时间，也会引发过度绘制的问题，过度绘制指的是在同一个像素点中被进行多次的绘制，而最终起效的只是最后绘制的一次，如果大范围的发生，对于应用的渲染是无端的消耗，会导致GPU负担加重从而导致界面的卡顿。 要解决此类的问题，必须从UI的布局上去予以解决，进行布局优化，简化复杂的层次和视图，减少layout_weight的使用，让界面尽可能的简单。同时，要避免此类问题，在界面的设计阶段我们就应该予以重视，要避免设计层次结构过于复杂的效果，从根本上予以预防。 2. 耗时操作。对于主线程来说，它最主要的任务就是负责界面的更新，处理与UI相关的逻辑，如测量尺寸，布局，绘制等，如果我们能保证主线程做的事情都与UI相关，并且界面布局足够合理，那么界面将会很流畅。 但在管家内，这么做显然也是脱离现实的，我们无法完全分离业务逻辑与UI线程，一些不太耗时的业务逻辑应该容忍其运行在主线程上。但相对的，耗时的操作如IO操作，DB操作，IPC通信等，我们要严格和UI线程分离，放到异步线程中去进行，结果需要刷新界面的，利用Handler或postRunnable等方式通知主线程进行刷新。 所以，辛辛苦苦建立起了流畅度自动化监控系统，接下来的问题就是，监控到的问题要谁去跟进修改，修改之后怎么验证，这个闭环是怎样的？ 现在管家流畅度监控已经建立起了如下图的闭环流程，从”自动化监控→结果输出→问题跟进→问题修复验证“形成一个闭环，让“问题发现→问题修改→修改验证”按照规范的流程的进行。? 如果您想了解更多关于移动终端安全的内容，请收听我们的微信公众号(终端安全那些事儿)，我们将定期为您分享；? 如果您对移动终端安全有什么问题和建议，关注我们的公众账号后直接回复消息联系我们。终端安全那些事儿 汇聚最优影响力的安全技术文章▲长按二维码可识别关注
评论Comments
微信公众号