一个包两种角色，还是两个包：员工端和管理端怎么分

先说一个几乎每个内部工具都会撞上的岔路口：这个应用有两类人要用，而他们要看到的东西不一样。——一线的人要快——打开就是今天要做的活儿，两下点完，最好能一只手操作。——管理的人要全——看统计、看异常、看谁没做完、导出报表。

而这两类人的界面，通常不该是同一个。——不是因为"权限"——权限是另一个层面的事——而是因为"任务不同"：一个人是来干活的，一个人是来看盘的，而"干活"和"看盘"需要的首页、按钮大小、信息密度，完全不同。

于是就出现一个很实际的抉择：做成"一个包里两套界面"，还是"两个包，各装各的"？——这两个答案都对，而选错的代价不一样——选"一个包"选错了，你会得到一个又大又难维护的包；选"两个包"选错了，你会得到两个必须永远同步的包。

「安卓修改大师智改工坊」在这件事上的位置很清楚：它不替你做这个决定，但它让两种选择的成本都变低。——你要一个包，就把"另一套界面"放进去、藏起来；你要两个包，就建两个项目、各改各的。——而"哪个更划算"，得看你的人怎么用手机。

只需说话，就能让应用变成你想要的样子。而在"两种角色"这个场景里，这句话最实际的用法是：把"管理员打开时看到什么、一线打开时看到什么"分别说清楚，让工具去改，而不是自己在一堆判断里绕。想先看看它怎么建项目、怎么用一句话描述需求，可以从 https://www.apkeditor.cn/ai-version.aspx 下载「安卓修改大师智改工坊」，拿一个自家的小应用试一遍——试完你会对"哪些差异适合放进一个包"有更具体的判断。

一、先问一件事：这两种人会出现在同一台手机上吗

这个问题听着像细节，其实是这个抉择的分水岭。——如果两种角色永远不会出现在同一台手机上——一线用一线的手，管理用管理的手——那两个包是天经地义的，而且几乎没有任何代价。——而如果一台手机上两种角色都要有——比如一个店长自己也要干活，他既看盘也接单——那问题就复杂了。

为什么"会不会同时出现"这么关键？——因为安卓不允许两个同包名的应用共存——你装第二个，会顶掉第一个。——所以如果一台手机上要有两种角色，而你又选了"两个包"，那这两个包的包名必须不同——而包名不同，它们在系统看来就是两个完全无关的应用。

这个后果比听起来严重。——包名不同的两个应用，不共享数据——一线在自己那个包里填的东西，管理那个包看不见，除非你们有服务端在中间传。——而如果你的应用本来就是"数据都在本地"的轻工具，那这个拆分等于把数据劈成两半。——所以"两个包"这个方案，隐含了一个前提：你们的数据是走服务端的。

如果数据不在服务端，那就只剩"一个包"这一条路——但"一个包"也有好几种做法。——最常见的是"登录之后按角色进不同的首页"。——而它的麻烦在于：角色的判断在哪一层、切换要不要重启、以及"一线能不能看到管理的入口"。

还有一种更土、但在小团队里很常见的做法：一个包，两套入口，靠"藏"来区分。——一线装的包，管理入口不显示；管理装的包，一线入口也在，但默认进的是看盘页。——这本质上还是"两个包"，只是包名相同、从同一个工程出——所以它们不能共存，但可以"发给不同的人"。

这个做法的好处很实在：工程只有一份，改动只做一次。——而它的坏处也很实在：一旦有人装错了包，他不会知道——因为两个包长得几乎一样，只有进去之后才看得出"我这个没有管理入口"。——而"装错了却不知道"，是内部工具里最常见的一类浪费。

所以这里有一个很值得采用的折中：包名相同、外观不同。——让管理版的应用名带上明确的后缀（比如"·管理"），图标换一个明显不同的样式，启动页上写清"管理端"。——这样两个包虽然不能共存，但任何一个人打开手机，都能一眼看出自己装的是哪个。

而包名不同还有一个连带好处，很多人没想到：它让"管"这件事变简单。——因为对系统来说，那是两个独立的应用——可以分别卸载、分别看占了多少空间、分别授权。——而"分别授权"在管理端上很实用：管理版需要定位和通知，一线版可能只需要通知——分开之后，权限清单更干净。

把这一节收成一句话：先回答"会不会同一台机器上都要有"，再回答"数据在不在服务端"，两个答案一组合，方案基本就定了。——而这两个问题都不需要技术背景——它们问的是"你们的人怎么用手机"和"你们的数据放在哪"。——而这两个问题答不清楚的时候，任何技术方案都是猜的。

二、三种做法摆在一起看，选哪个就清楚了

抛开"应该怎样"的讨论，能落地的做法其实只有三种。——而每一种都有自己的舒适区和自己的坑——把三种摆在一起，你多半会发现自己其实只有一个选项。

做法	适合什么情况	代价
一个包，登录后按角色进不同首页	同一个人会在两种身份间切换；数据在服务端	要做角色判断和切换，改包改不动这部分
一个包，两套外观，靠藏入口区分	角色固定、不会切换；只想少维护一份工程	包长得像，装错了不易发现；不能共存
两个包，包名不同，各自独立	一台机器上两种角色都要有；数据走服务端	两个包要同步升级；本地数据不互通

第一种做法最"正统"，也最像"一个正常的产品"。——登录、判角色、进对应首页——用户感觉不到"这是两个东西"，只感觉"我登录之后看到我的界面"。——而它的代价是：这部分逻辑是代码，不是资源——所以你没法靠"改包"把它改出来。

换句话说，如果你的应用从来没有"角色"这个概念，那第一种做法就不是"改包"能解决的——它要求你回去改代码。——而这一点必须提前说清楚，因为很多人会误以为"改包什么都能改"。——改包能改的是"长什么样、显示什么文字、开哪个入口"——它改不了"登录之后怎么判断你是谁"这种逻辑。

第二种做法是"改包"这条路最擅长的：一个工程，两套皮。——管理版把一线的入口也留着（万一要用），但默认进的是看盘页；一线版把管理入口藏掉，默认进任务页。——两个包都从同一个项目拷出来，只改那几处。——而它的坑就是前面说的"长得像"——所以在这一种做法里，"外观差异要做足"不是审美问题，是可用性问题。

第三种做法最"干净"，也最贵。——两个包名、两个项目、两份签名（也可以共用一份）、两条升级线。——而它最大的好处是：管理版可以真的只装给管理的人，一线版可以真的只装给一线的人——而两者在系统层面互不干扰。——而它最大的成本不在第一次，在"以后每一次"——每次改共同的功能，你都要在两个项目里各做一遍。

所以"两个包"这个选择，真正要算的账是"以后改多少次"。——如果这个应用已经稳定、一年改两次，那两个包的成本可以忽略。——如果它还在长、每个月都要加东西，那两个包会让你每个月都做两遍同样的活——而两遍里必有一遍会漏。

还有一个常被忽略的第四种：先做一个包，等真需要了再拆。——这是最稳的顺序——因为"要不要拆"这个问题，往往要等用起来才知道。——而拆的动作并不难：把现在的项目目录拷一份、改包名、改外观、把不该有的入口藏掉——半天的事。——难的是反过来——两个包合回一个，那才叫麻烦。

顺便澄清一个常被混在一起的问题：这是"按界面分"，还是"按权限分"？——按权限分，是"同一个人能看到什么"的问题，它属于服务端；按界面分，是"这种人平时干什么"的问题，它属于产品设计。——两者可以叠加，但不能互相替代——因为一个人可能有很高的权限，却还是个每天要跑现场的人。——所以别用"权限"去解释"界面为什么不一样"，那会把一个设计问题说成一个安全问题，然后谁也说服不了谁。

三、两个自家应用的实例：一次选了"一个包"，一次选了"两个包"

两个例子，正好落在两种选择上。——都是我们自家内部在用的应用，一个选了"一个工程两套外观"，一个选了"两个包各自独立"。——讲它们不是为了证明哪个对，而是让你看到"选的依据是什么"。

例一：自家的巡检应用。——一线的人拿着手机去现场，逐个设备打勾、拍照、写备注；管理的人坐在办公室里看"今天哪些点位没巡、哪些有异常"。——这个应用的数据全在服务端，所以两种做法都可行。

以前怎么做：——最初是一个包，谁装都是同一个界面，靠登录后的权限决定能看到什么。——问题是一线的人打开之后，第一屏是一堆统计卡片——他们要往下滑两屏才找到"开始巡检"。——于是每天都有人在群里问"那个开始按钮在哪"。

我们最后选的是"一个工程、两套外观"。——为什么不是两个包？因为一台手机上两种角色都会出现——组长自己也要去现场，他既是管理也是一线。——为什么不是改代码做角色首页？因为那需要改逻辑、重新发版、还要考虑切换——而这件事的收益只是"少滑两屏"，不值得动代码。

现在一句话怎么做：——建两个项目，从同一份工程出发。——一线版发一句："应用名改成『巡检 · 现场』，图标换成附件这个蓝色的，启动页标题写『现场巡检』，首页第一屏把『开始巡检』放到最上面，统计卡片挪到第二屏。"——管理版发一句："应用名改成『巡检 · 看板』，图标换成附件这个深色的，启动页标题写『巡检看板』，首页保持统计卡片在最上面。"——两句话，两个包，一个工程。

改完怎么验证：——这里的关键验证是"拿错包会不会发现"。——我们把两个包分别装在两台机器上，然后故意交换——让一线的人拿"看板"版去现场。——结果他打开第一眼就说"这不是我这个"——因为图标颜色和启动页文字都不同。——这个测试比任何说明文档都有效：它证明"外观差异做足了"。

例二：自家的排班应用。——普通员工看自己的班表、申请换班；组长编排班、审批换班。——这个应用的数据也走服务端，但它最后选了"两个包"。

为什么这次选两个包？因为"这个人是不是组长"在排班这件事上是很稳定的——组长就是组长，不会这一周是、下一周不是。——而更重要的是：组长用的那个包里，有"给全组排班"这种高风险操作——它不该出现在普通员工的手机上，哪怕藏起来也不该。——所以这次我们让包名都不同——两个包可以同时装在一台机器上，组长自己的手机上就有两个图标。

现在一句话怎么做：——员工版："应用名『排班』，包名换成 xxx.schedule.staff，启动页写『我的班表』，首页只留『我的班表』和『换班申请』两项。"——组长版："应用名『排班 · 组长』，包名换成 xxx.schedule.lead，启动页写『排班管理』，首页保留『全组班表』『换班审批』『人员』三项。"——包名这一句必须写在需求里——否则两个包会互相覆盖。

改完怎么验证：——这次验证的第一件事不是"看起来对不对"，是"能不能同时装"。——在一台手机上先装员工版、再装组长版，两个都在桌面上，才算包名真的改成了两个。——然后才是老规矩：看桌面名、看启动页、看首页那三项对不对。——而这一步的顺序不能颠倒——因为"装不上"比"长得不对"更根本。

四、角色型多版本，真正会变的六处

角色型的差异，和"多校区"、"一门课一个包"又不一样。——校区那种变的是"归属"，课程那种变的是"内容"，而角色变的是"任务"。——任务不同，落点就不同——它不在名字和封面上，而在"打开之后第一眼看到什么、第一个按钮是什么"。

一是应用名，带角色后缀。——这是最省事也最有效的一处——"巡检 · 现场"和"巡检 · 看板"，四个字就把区别说清了。——而它的长度要控制：加了后缀之后，桌面上的字更容易被截断——所以原来的名字最好短一点。——如果原名字本身就长，那后缀可以用更短的词——"现场"和"看板"比"一线执行端"和"管理查看端"更适合放桌面。

还有一件小事，但它会毁掉整个区分：图标的安全区。——如果你的图标是自适应图标，那不同厂商的桌面会把它裁成不同形状——圆形、方形、圆角方形。——所以"整体换个颜色"这件事，要在裁完之后还看得出来——也就是说，颜色要铺满整块，而不是只出现在角落的一条色带里。

二是图标。——角色之间最有效的区分不是"换一张图"，而是"换一个颜色"。——因为人在桌面上一眼扫过去，认出的是颜色和形状，不是图案细节——所以同款图形配不同底色，比两个完全不同的图形更容易区分。——而这也顺带解决了一个问题：配色统一，看起来还是同一个产品线。

三是启动页。——启动页在这一类需求里承担的是"确认身份"——所以它上面最该出现的是角色名，而不是一句空泛的标语。——"现场巡检"和"巡检看板"六个字，比一句"让巡检更简单"有用得多——因为前者帮人确认"我装对了"，后者只帮人放松。

四是首页的布局顺序。——这是角色型最核心的一处，也是最容易被"只改名字"糊过去的一处。——一线的首页，第一个能点的东西应该是"开始干活"；管理的首页，第一屏应该是"现在什么情况"。——而如果你只改了名字和图标，首页两块内容还是同样的顺序，那这个"两套界面"其实只做了一半。

五是入口的藏与显。——一线版不该出现的入口，要真的不显示，而不是"点了提示没有权限"。——因为"点了才知道没权限"是一种很消耗人的设计——它让人反复试、反复失败，最后形成"这个应用很多地方不能用"的印象。——而不显示，是干净的：我不需要，它就不在。

六是默认值。——这一处很少有人想到，但它每天都在影响效率。——一线的列表默认应该是"我的"——我的点位、我的任务、我的班表；管理的列表默认应该是"全部"——全组的、全站的。——而这一个默认值的差别，一天能省下几十次点击——它比换一个图标实在得多。

六处之外，如果选了"两个包"，还要多改一处：包名。——而包名这一处有个特点：它决定了"这两个包在系统里是不是两个东西"。——包名相同，它们是同一个应用的两个版本，不能共存；包名不同，它们是两个应用，可以共存、也可以各自升级。

把这七处连起来看，会发现一个规律：前五处是"让人分清"，后两处是"让系统分清"。——而这两件事都得做——只做前五处，人会拿错；只做后两处，人会拿错了还不知道。——而如果只能做一处，先做第一处（应用名带后缀）——它成本最低、见效最快。

五、最容易出的错：管理入口留在了员工包里

这一节要说的错，不属于"不好看"，属于"不该发生"。——而它偏偏最常见：一线版的包里，管理入口还在——只是没显示在首页上。——而"没显示"和"不能用"，是两件完全不同的事。

先把原理说清楚，因为它决定了你能做什么、不能做什么。——改包改的是"界面和资源"——它能让一个入口不显示、一段文字变掉、一张图换掉。——但一个功能"在不在"，是由代码和服务端决定的——你把入口藏起来，功能本身还在，只是没有按钮能点到它。

所以第一条结论很硬：改包不能替代权限。——真正的安全边界在服务端——谁能不能看、能不能改，应该由服务端在每次请求时判断。——而包里的"藏"，只是"减少误触"和"让界面干净"，它不承担安全职责。——把这两件事分清，你就不会问出"我把入口藏了是不是就安全了"这种问题。

第二条结论更实际：如果服务端没有做校验，那就别只靠藏。——因为藏起来的入口，可能通过别的路径到达——一个深链接、一个历史记录、一个别人发来的跳转。——而这些路径你未必想得到。——所以正确的顺序是：先在服务端把权限做对，再用包把界面收拾干净——反过来做，就是把门锁在画上。

还有一个很常见的误会：以为"两个包"就等于"两类人各装各的"。——而实际上，包是谁做的、能不能发给谁，靠的是发放环节的把关——你手里六个包，谁拿到哪个，全看你发的时候有没有看错行。——所以在"两个包"的方案里，装机表比什么都重要——它记的是"哪台机器、装的哪个包"，而不是"我以为他应该装哪个"。

第三条是关于"两个包"的：包名不同，不代表数据隔离。——两个包如果连的是同一个服务端、用的是同一套账号体系，那它们看到的数据是一样的。——"分成两个包"带来的隔离感，是心理上的——真正的隔离，还是得靠服务端的权限。——这一点在评审的时候最容易被误解：有人说"我们分两个包了，安全了"——而实际上只是"分了两个图标"。

那么"改包"在这个环节里到底该做什么？三件事，都很实在。——第一，把不该出现的入口真的不显示——让一线的人不用在一堆用不上的东西里找自己要的那个。——第二，把角色名写在名字、图标、启动页上——让人不会拿错。——第三，在管理版里把"这是管理端"说明白——因为管理端的操作影响面大，多一句提示，少一次误操作。

再说一个反例，因为它太典型。——有人做了员工版，把"后台管理"的入口从首页去掉了，但那个页面本身还在包里。——后来有人从聊天记录里点开了一个旧链接，直接进了那个页面——而服务端没校验，于是他看到了全部人员名单。——这个事故的根因不在"包没改干净"，在"服务端以为前端会挡住"。

所以这一节的结论可以写成三句话：包负责"好用"，服务端负责"安全"；藏入口是体验优化，不是权限控制；分两个包是管理手段，不是隔离手段。——三句话都记住，你就不会在评审会上被"我们藏起来了"这句话说服。

最后还有一个容易被忽略的点：员工离职之后，他手机上那个包怎么办。——包还在，账号可能已经停了——而"停账号"和"包不能用"是两件事。——如果应用里有本地缓存的数据（今天的任务、拍的照片、填的记录），那这些数据还在那台手机上。——所以"两个包"的方案里，还要加一条管理动作：人走了，包要卸载，而不只是停账号。

顺着这个思路，还有一件和"人"有关的事：培训的时候，别拿管理版去演示一线怎么用。——这是内部推广里最常见的一个"无意错误"——培训的人手上只有管理版（因为他权限高），于是拿它讲一线操作，讲完大家都以为"我手机上也会长这样"。——而真正发下去的是一线版，界面完全不同——于是第一批用户的第一反应是"跟我看到的不一样"。——所以培训要用"受众真正会拿到的那一个包"，这条比什么物料都重要。

六、验证：两种角色一起测，才能测出问题

角色型的验证有个特点：只测一个包，是测不出问题的。——因为角色型的错误几乎都发生在"两个包之间"——拿错了、装错了、串了、退不出去。——所以验证的方式不是"一个一个测"，是"放在一起测"。

第一件事：能不能共存。——如果方案是"两个包名"，那必须验证"两个包能同时装在一台手机上"——先装一线版、再装管理版，两个图标都在桌面上，才算真的分开了。——而如果它们互相覆盖，说明包名没改成两个——这时候不要继续往下测，因为后面所有结论都不可靠。

而"能不能共存"这件事，还有一个反向的验证：如果方案是"一个包名两个外观"，那必须验证"后装的能覆盖前装的"。——这两个方向正好相反——一个要求"互不干扰"，一个要求"能顶掉"。——所以验证的第一步不是动手，是确认"我到底选的是哪种方案"——方案说错了，验证就会得出相反的结论。

第二件事：会不会拿错。——做法很土：故意交换——把管理版给一线的人，把一线版给管理的人，看他们能不能在第一时间发现。——如果两个人都说"这不对"，说明外观差异做够了；如果有人没发现，甚至照着用了一天，那说明这两个包在他们眼里是一样的。

这个测试的价值在于它"不礼貌"。——真实场景里，人会因为"不想麻烦别人"而将就着用——拿着错的包干了一天，晚上才说"今天这个好像不太对"。——而这个测试把这个"将就"提前了——提前到还没发下去的时候。——而发现得越早，改的成本越低：改一个名字、换一个图标，五分钟。

第三件事：退不退得出去。——这一件事最容易被忘，而它偏偏在出问题的时候最重要。——假如某个一线的人装错了管理版，他要退回一线版——这时候他会遇到什么？——如果两个包名相同，那他会遇到"版本号不降就装不上"的问题——因为管理版的版本号可能更高；如果两个包名不同，那直接卸载再装就行。

所以"退路"这条要在发下去之前想清楚，而它的处理方法很简单：两个字——版本号。——如果是"同包名两个外观"，那两边的版本号都要往上走，不要一个高一个低——否则"退回"这件事会变成"卸载重装"，而卸载会清掉数据。——如果是"两个包名"，那各自升级各自的，互不影响——这也是两个包名方案的一个隐性好处。

还有一件事，不属于"验证包"，但属于"验证方案"：找一个真的会两种角色都用的人，让他用一天。——比如那个既要去现场、又要看盘的组长。——他会告诉你一些你想不到的事——比如"我现场干完活，要回到看板，得退两次"。——而这类"要退两次"的问题，只有真的用一天才会发现。

把这三件事加一个人，凑成一套验证：能不能共存、会不会拿错、退不退得出去，再加一个"真的两种角色都用的人"。——这套验证大概花半天——而它能挡掉的，是"发下去之后一个月都在解释哪个是哪个"。——而这类解释的成本，从来不体现在工时表上，只体现在"这个工具没人愿意用"上。

再补一个很实际的验证动作：把两个包都装在一台机器上，然后看"电量"和"后台"。——因为两个包如果各自都有定位、推送、后台同步，那这台机器的负担是双份的。——而这个负担，组长的手机上最明显——他两个包都装着。——所以"两个包"这个方案，最好顺带确认一件事：其中至少一个，在不需要的时候能把后台关掉。

七、什么时候该把两个包合回一个

前面花了很多篇幅讲"怎么分"，因为分是常态。——但分久了会有人提一个问题："这两个包能不能合成一个？"——而这个问题通常在三种情况下出现。

第一种情况：装的人越来越少。——管理版当初做出来，是因为"有一批人需要看盘"。——而一年之后，真正每天用管理版的人可能只有两个——而为了这两个人，你要维护一条独立的升级线。——这时候更划算的做法是：把管理功能做成登录后的一个入口，回到一个包。

第二种情况：两边的内容开始趋同。——一开始一线版只有三个入口、管理版有八个。——而半年之后，一线版加了五个（因为现场也要看统计、也要申请人），管理版减了两个（因为有些功能挪到了网页端）。——当两个包的入口列表重合到八成，那"分"的意义就没了——因为差异已经小到"藏"就够了。

第三种情况：两个包的版本开始不一致。——这是"分"这件事最典型的病——一线版更新到第八版，管理版还在第六版；而某一处数据格式变了，两个包开始互相看不懂。——而当"同步"这件事变成每个月的固定动作，你就该回头看：这两个包到底是不是该分开。

而"合"这件事，比"分"难——这是必须提前说的实话。——因为分是"从一份拷两份"，每份都完整；而合是"把两份不同的东西变成一个"——你必须决定每一个差异留哪个。——而"每个差异留哪个"这个问题，往往没人能立刻答——因为两边都有人用惯了。

所以"合"的动作最好分两步走，别一步到位。——第一步只做"入口合并"——把两边的入口都放进同一个包里，靠藏来区分，先让所有人装同一个包。——第二步才是"删掉多余的那一套"——等大家都用了一个月，再回头看哪些入口从来没人点。——而这一步之所以能等，是因为入口多几个并不碍事；而"一步删干净"如果删错了，人是要抱怨的。

所以合的做法，一般不是"真的合"，而是"以一边为基准，另一边慢慢被吸收"。——具体来说：选那个用的人多的、或者更新更勤的版本作为基准，然后把另一边的独有内容搬过来。——搬完之后，另一边的包停止更新，但先别删——让它活一两个月，看还有没有人要。

八、五个最常被问到的问题

问一：能不能只做一个包，靠登录后的权限控制界面？——能，而且这是最"正统"的做法。——但要注意：它属于改代码，不属于改包——因为"按角色显示不同界面"这件事在逻辑里，不在资源里。——如果你没有改代码的条件，那就选"两个外观"或者"两个包"。

问二：两个包能不能共用一份签名？——能，而且建议共用。——共用一份签名，意味着这两个包"出自同一个开发者"，在需要互相唤起、或者未来合并的时候，少一层麻烦。——而"共用签名"和"包名不同"并不冲突——签名回答"谁做的"，包名回答"是哪个应用"。

问三：一线版里的管理入口藏掉了，是不是就安全了？——不是。藏只是"看不见"，不是"用不了"。——真正的安全在服务端——每一次请求都要判断"这个人有没有权限"。——把这句话写进评审纪要，能省掉以后很多争论。

问四：管理版能不能只装在平板上？——能，而且很多团队就是这么做的——平板屏幕大，看盘舒服。——但要注意一件事：平板的屏幕尺寸和手机差很多，同一个界面在两边的留白、字号、一屏能放几行，都不一样。——所以"只装平板"这个决定，最好在验机的时候就把平板拿出来试，别等到发下去才发现排版挤在一起。

问五：两个包的图标能不能只差一个角标？——技术上能，但效果很差。——因为桌面图标很小，角标更小——人在扫一眼的时候，看不出那两个像素的差别。——有效的差异是"整体颜色不同"——蓝色和深灰，一眼就能分；而"右下角多一个小圆点"，几乎等于没有差异。

九、三个问题定方案，一张表做完交付

把前面所有内容压缩成三个问题，答案一填，方案就出来了。——而这三个问题都不需要技术背景——它们问的是"人怎么用""数据在哪""以后改多少次"。

问题	如果你的答案是	那就选
一台手机上会不会两种角色都要有	会	两个包名；或者干脆一个包两套外观
一台手机上会不会两种角色都要有	不会	两个包，包名可以相同
数据在不在服务端	不在（本地为主）	一个包，别拆——拆了数据就断了
数据在不在服务端	在	三种都可行，看下面那一行
一年还要改几次	经常改	尽量少拆——拆一次，以后每次都要做两遍
一年还要改几次	基本不动	随便拆——维护成本可以忽略

这张表最好用的地方，是它会把"想不清楚"的地方逼出来。——很多人卡在"要不要拆"，其实是因为没回答"数据在不在服务端"——而这个答案往往要找技术同事确认一次。——确认完之后，"要不要拆"这个问题会突然变简单。

而如果三个问题问完，你发现答案自相矛盾——比如"一台手机上两种角色都要有"和"数据不在服务端"同时成立——那就别急着做，先解决那个矛盾。——因为这两个条件同时成立的时候，任何方案都会留下一个洞：拆了数据断，不拆界面挤。——而这时候最该做的是回去补服务端——那不是打包能绕过去的事。

方案定了之后，交付之前还有一张短表要勾。——这张表不长，八项，但每一项都是"漏了会返工"的。

序号	交付前要确认的事
1	方案定了，而且写下来了（不是口头说的）
2	应用名带上了角色后缀，长度还能在桌面显示完整
3	两个图标是"整体颜色不同"，不是"多一个小角标"
4	启动页上写清了角色名
5	首页第一屏放的是这个角色最常做的事
6	两个包的包名和版本号都核对过，共存的能共存、覆盖的能覆盖
7	故意交换装过一次，两个人都能第一眼发现不对
8	服务端的权限校验确认过，不靠"藏入口"兜底

八项里，第 7 项和第 8 项最容易被跳过，而它们恰好是两种不同性质的保险。——第 7 项防的是"人拿错包"，第 8 项防的是"人看到不该看的"。——前六项做不好，是效率问题；后两项做不好，是事故问题。

最后补一句关于"记录"的话：把这个方案写进一句话里，放在项目目录旁边。——比如"一个工程两个外观，包名相同，版本号同步，一线版藏管理入口，管理版留全部入口"。——这句话看着简单，而它能省掉半年后"我们当初为什么这么定"的整场会议。——而写这句话的成本，是三十秒。

十、用过的人怎么说

五条里，两条讲"分得清"，两条讲"踩过的坑"，一条讲"平板上没试"。——而"分得清"那两条说的都不是技术——说的是"人和人的差别"：一线的人要快，管理的人要全。——而"快"和"全"这两个字，是没法用一个界面同时满足的。

那句"藏起来不等于关掉"，是这五条里最该被记住的一句。——因为它把"改包"这件事的边界划得很清楚——改包能改界面，改不了权限。——而很多事故不是因为"改错了"，是因为"以为改够了"。

还有一条值得多说一句：平板和手机要分开看。——因为"屏幕大一点"这件事，对界面的影响不是等比例的——有的布局在小屏上是"挤"，在大屏上是"空"；有的在小屏上正常，在大屏上会把一行拉得特别长。——而这两种问题，你在电脑上看预览都看不出来——只有那台真机摆在你面前，才会露出来。

最后回到那个最初的问题：一个包还是两个包。——五条反馈里没有一条说"选错了"，说的都是"选完之后没做够"——图标不够分、包名忘了改、本该在服务端做的校验偷懒没做。——所以这个决定本身没有想象中那么关键；关键是决定之后，把那几件"让人分得清、让系统分得清"的事做到位。

---

只需说话，就能让应用变成你想要的样子。——而"变成一线要的快、管理要的全"，靠的是把两套任务说清楚，剩下的交给安卓修改大师智改工坊——它不替你决定要不要拆，但它让拆和不拆都变得便宜。